by rvonder » Fri Aug 03, 2018 12:30 am
I hate to reopen an ancient thread, but I found this one in a search just prior to submitting the same bug: Any changes during retagging that would affect the media tree list itself often cause the album to totally disappear from the displayed list, under either the original or new name. For me, this happens with about 80% of 'auto-organize files' operations. The bug doesn't occur every time, and seems to be totally random - I've never found a consistent pattern to predict or reproduce it.
There is no error message or log entry, so hoping a little more info might help: I have a fairly large library (15k artists, 8200 albums, 146k tracks). Most of it is organized into a 3-level disk folder hierarchy: by first letter of the album artist (A-Z, or #), then by full album artist name, and finally by album name/year. Most auto-organize operations only affect the third (lowest) level, due to a tag change in the album name/year, and that's when the problem seems to appear. (Changes to filenames of individual tracks within a lowest-level folder work fine.)
Might this have something to do with caching of a large media tree list (mine would be almost 170k entries if fully expanded), and the appropriate branch of the cache not being automatically refreshed when relevant changes require it? I say this because the workaround is to close the list hierarchy until only top level entries (i.e., 27 letters) are shown, and click on a different letter to open a different branch of the hierarchy. I then close that branch, and click back down to the original third level of the hierarchy where the album(s) had disappeared. This always makes everything reappear. It doesn't seem to be enough to merely close and then reopen the same branch values; only jumping to a different branch of the tree and then reopening the original branch seems to force a refresh of the list cache/contents that makes the missing items reappear. (I've also tried to do a re-scan on a "missing" album - it always shows up in the selection list, but re-scanning does nothing. No files are added, and the missing album still doesn't appear in the media list.)
Finally, I have 'scan continuously' turned on, so newly-added folders usually appear in the MM media tree immediately. But sometimes the same workaround above is needed to make them actually show up in the media list even though they have, in fact, been added to MM.
This bug was added to Mantis back in Jan. 2012, and still shows 'open' after 6 1/2 years. It's been a major irritation to me for most of that period, so I'd sure be very grateful if you could maybe find time to track it down!
I hate to reopen an ancient thread, but I found this one in a search just prior to submitting the same bug: Any changes during retagging that would affect the media tree list itself often cause the album to totally disappear from the displayed list, under either the original or new name. For me, this happens with about 80% of 'auto-organize files' operations. The bug doesn't occur [i]every [/i]time, and seems to be totally random - I've never found a consistent pattern to predict or reproduce it.
There is no error message or log entry, so hoping a little more info might help: I have a fairly large library (15k artists, 8200 albums, 146k tracks). Most of it is organized into a 3-level disk folder hierarchy: by first letter of the album artist (A-Z, or #), then by full album artist name, and finally by album name/year. Most auto-organize operations only affect the third (lowest) level, due to a tag change in the album name/year, and that's when the problem seems to appear. (Changes to filenames of individual tracks within a lowest-level folder work fine.)
Might this have something to do with caching of a large media tree list (mine would be almost 170k entries if fully expanded), and the appropriate branch of the cache not being automatically refreshed when relevant changes require it? I say this because the workaround is to close the list hierarchy until only top level entries (i.e., 27 letters) are shown, and click on a different letter to open a different branch of the hierarchy. I then close that branch, and click back down to the original third level of the hierarchy where the album(s) had disappeared. This always makes everything reappear. It doesn't seem to be enough to merely close and then reopen the [i]same [/i]branch values; only jumping to a [i]different[/i] branch of the tree and then reopening the original branch seems to force a refresh of the list cache/contents that makes the missing items reappear. (I've also tried to do a re-scan on a "missing" album - it always shows up in the selection list, but re-scanning does nothing. No files are added, and the missing album still doesn't appear in the media list.)
Finally, I have 'scan continuously' turned on, so newly-added folders usually appear in the MM media tree immediately. But sometimes the same workaround above is needed to make them actually show up in the media list even though they have, in fact, been added to MM.
This bug was added to Mantis back in Jan. 2012, and still shows 'open' after 6 1/2 years. It's been a major irritation to me for most of that period, so I'd sure be [i]very [/i]grateful if you could maybe find time to track it down!
