I've seen very similar behavior to what you're describing and here's how it works: you turn off your NAS, and autoimport (sooner or later) notices there's been a "change" to the source. It attempts to scan the (now missing) NAS drive, finds no files, and proceeds to remove some (or all) of the broken links depending on how much time it has to work. When the NAS is turned back on, autoimport detects new files in the watched location (because the old ones have been removed) and reimports them looking for new cover art online(replacing the old cover art).
This is subtly incorrect, and while the net effect is the same, I thought it was worth explaining.
If you have
Fix Broken Links set to
Yes (the vanilla, non-protecting version) then what mwillems described is absolutely correct.
However, if you have it set to
Yes (protect Network Drives) then it is subtly different, but with some NAS devices (and some computer setups) the net effect is identical.
With the protect network drives option enabled, then MC won't "fix" broken links that are missing because the entire volume is missing. That's what it does to protect network drives! The rule is, essentially:
* If MC cannot "see" the volume the media files are stored on
at all, the files are protected.
* If MC can see the root of the volume the media files are stored on, and the files still don't exist, then they are determined to be "broken" and so are removed.
That sounds brilliant, and should protect most network drives. Unfortunately, with some NAS devices, they're... Slow, and act funny when they're booting up (or "un-sleeping" themselves). Often on these devices, what happens when they're booting up is that the
shares become available before the
filesystem that backs them is available (the disks haven't spun up or been mounted yet, probably). So, from MC's perspective, this falls into case #2 described above. The share is there, the OS has mounted the volume, but it is empty. It only stays empty for a short while, but that doesn't matter... MC can remove broken links extremely quickly (10s of thousands in fractions of a second). With some tagging changes, MC has to write changes to the disk (to the files) and that's slower. But when it is operating only on the Library (which is loaded in RAM)? Yeah, removing records from the Library is fast. I mean, really, really, really fast.
It could be improved in a few ways, I think, but it also only impacts some people some of the time with some NAS devices (or storage schemes)... And, there is a solution. The recommendation is if you have a troublesome NAS, to disable Fix Broken Links. Done.
This won't help you on OSX, but if you do have to disable Fix Broken Links, but you need the feature (or fancier options), I wrote a command line tool called MCFileRemover which can automatically remove broken links, and even delete files from disk, based on a Playlist in MC (which can be a Smartlist and so automatically generated). Unfortunately, it is Windows only.
I'd love to, at some point, make cross platform versions of my tools. They're written in C# which can be compiled on OSX but... They're currently all written against MC's COM interface and not MCWS. Only Windows has COM. So, I'd have to convert my entire underlying MC-connecting-framework over to MCWS. I've started this project but... Wow. Its a pile of work.
JRiver has a C# MCWS library. I've bugged them a few times that they should clean it up and open source it, so that others can more easily write cross-platform plugins using a nice, modern programming language. But, they're C++ nerds (and would probably say to my suggestion that C# is "nice" that I don't know what I'm missing) and so... low priority.
There's just so much to do. Progress, however, comes incrementally, but
relentlessly with these guys. All things in good time.