Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[akhunaton]

this is second time this happened. the last time I simply restored to a previous backup. Files are stored on a network drive. what do I do to keep this from happening? this never happened with version 19 and previous version.  ?

[mwillems]

Go to Options-->Library & Folders --> Configure Auto-Import, then change the setting for "Fix broken links" to "No" or "Off."  The setting to protect files on missing drives does not work 100%, which leads to the files disappearing and then being reimported.  Disabling it should fix your problem.

[glynor]

The setting to protect files on missing drives does not work 100%, which leads to the files disappearing and then being reimported.

Just to clarify.  It works 100% according to its logic, but its logic may not always protect missing drives, depending on how your file storage is set up.

If you use external storage that disconnects a lot, caution around that option is warranted.  The biggest case where it "fails" is if a drive may be connected and get the same drive letter or mount point.  So, if your media drive is drive E: but it is on an external disk that you disconnect sometimes, and you plug in other drives that might, even for a moment, show up as drive E, then it'll remove everything on that disk.

I agree that this is the likely cause, assuming you aren't having delayed write failures that are causing data corruption, or something similar.

[glynor]

By the way, this should be relatively painless to recover from... Media Center makes Library Backups automatically, roughly every two days. If you restore from one of these automatic backups, it'll put you back to exactly where you were when the backup was made.

More info:
http://wiki.jriver.com/index.php/Library_Backup

[mwillems]

Just to clarify.  It works 100% according to its logic, but its logic may not always protect missing drives, depending on how your file storage is set up.

If you use external storage that disconnects a lot, caution around that option is warranted.  The biggest case where it "fails" is if a drive may be connected and get the same drive letter or mount point.  So, if your media drive is drive E: but it is on an external disk that you disconnect sometimes, and you plug in other drives that might, even for a moment, show up as drive E, then it'll remove everything on that disk.

I agree that this is the likely cause, assuming you aren't having delayed write failures that are causing data corruption, or something similar.

Glynor, all my drives are mapped to a unique drive letter persistently (drives U: through Z:), and I still see this issue whenever fix broken links is set to anything but "off," so I don't think the "imposter" problem is the only case where this happens.  I haven't even observed this to happen when my drives actually disconnect, which they very rarely do (primarily at startup and shutdown, my server doesn't sleep and neither do the drives).  It always seems to happen at random times when the drives appear connected.  When testing to try and see what causes the issue, I've even seen fix broken links occasionally remove items on local drives that went to sleep.  

It doesn't even necessarily remove everything on a given disk.  It seems to begin removing items when it momentarily can't reach the disk and stop a little while later when it reappears.  For example, all my music is currently on one networked drive, and I've had anywhere from a few albums to all of my albums removed from the library and get reimported before I disabled this feature.  

I can't comment on the program logic, but this is the fifth or sixth thread where someone has asked this exact question, and in the previous threads turning off fix broken links resolved their issue.  So while it might be something else in this case, I think the protect network drives feature does not work consistently right now and so is a likely suspect.

[glynor]

Glynor, all my drives are mapped to a unique drive letter persistently (drives U: through Z:), and I still see this issue whenever fix broken links is set to anything but "off," so I don't think the "imposter" problem is the only case where this happens.

I wasn't suggesting it was the only case. I think the logic can be troublesome with network drives and sleeping local disks under certain conditions as well.  I strongly suspect that it isn't when it can't see the drive (I know this to be the case from their repeated descriptions of the option). It is when it can see the drive, but can't see any of the files on the drive (the same thing as with the external drive issue).  So, I imagine this could happen in some circumstances with a very-slow-to-wake NAS volume, and other similar cases where a disk is mounted, but is very slow to respond.

I'd recommend you keep it off, and if you do need files automatically removed, use the little utility I made to remove them:
http://blog.glynor.com/mcfileremover/

If they do decide to try to fix the option, I made what I thought was a reasonable recommendation in the past. Change the logic as follows:

* If MC can see a matching drive letter or volume mount point, and...
* If MC can see a matching root parent folder (meaning, the top-level folder one level down from the drive root), and...
* MC cannot see matching files using the full path...
* Then remove the files, otherwise protect them

That would be relatively safe. The only way to delete them then would be if a drive is there, and responding, and it can see some part of the original file "tree".  The only cases where it would "fail" (meaning, not remove things it "should" have removed) is if the user intentionally deleted an entire directory tree, all the way down to the root of the drive. This seems to be enough of a huge edge-case that substantial caution is warranted anyway.  When in doubt, it should protect the files.

You could also add, if the database allows it (which could be an issue keeping the speed up in Auto-Import):
* If more than NN% of the files on a particular volume are impacted, protect all files on that volume (say 30%)

But, I don't know if that is practical for the way MC's Auto-Import system works.  Either way, the first thing would be enough, I think.  As it is, I don't think the option is "protective" enough. The alternative is to add timeouts (which I imagine they've already done) but this leaves it up to finely balancing the timeouts, and you're at the mercy of a million hardware makers doing weird stuff with sleeping disks (a 18-disk array will wake much more slowly than a single-disk consumer NAS box).

On the other hand, Auto-Import should re-detect any removed files and "un-remove" them without any ill effects, aside from skewed [Date Imported] statistics (which is enough reason for me not to risk it, but for lots of people it probably isn't a big deal).  I'm not sure why that isn't happening in this case, though, and ordered playlists are being destroyed.  I think that warrants investigation as well.  I wonder if it is interacting somehow with the borked Playlist sync with a Client connected?

Not sure.  In any case, you can turn it off, and the problem goes away. If you need to auto-remove files, you can use my little utility, and you should be all set.