Added another watched directory and did a lot of duplicate analysis and book-keeping to clean up my library
Deleted the Roonserver database and copied the previous snapshot back
Copied a few files to the watched library
A few of these caused some dupes anyway, so I deleted a few of those
The result is that some albums (the new ones) have scrambled images. And when I go in to edit the album data fields, it shows a complete mess: the album shows one image in the main page, and in the editor it offers two other ones among the known images, the one in the main page is not even known in the database.
And this is fairly common among the recently added albums, not only the ones that participated in the dupe cleanup. Look at the fourth album in the third row, Modern Times by Bob Dylan: the image is a Gaby Moreno album. Lots of errors in this page, and when I open any album it shows that same behavior in the editor.
Look carefully here: the Gaby Moreno cover that was used in the browser is listed, and another unrelated cover is listed, but the main album page shows the correct cover.
Update: I tried a variety of cleanup options, like deleting the newly added albums (55), doing a library cleanup, and adding them back to the storage. Didn’t help. I wondered if one of the albums had some characteristic that caused the problem, but no, I repeated the delete/clean/copy back for each artist, and each was messed up.
So I finally removed the messed up database (I saved it for future reference) and copied back the one that had the large messy collection with lots of duplicates, removed the extra library so the dupes disappeared, but I left the database as it is. I then copied the new 55 files in. They were recognized, because they had been part of that big dupe situation (that’s why I did it), so they showed up in the library with the Added date of last week. But now the images are correct!
I have not cleaned up the database. I probably should, but I don’t want to mess things up, everything is good now.
Very strange. @Mike, let me know if you want to look at the bad database.
Back then, we didn’t include “database id” as part of the key, so merely switching between cores was enough to cause this symptom. Now it requires a much less likely series of events.
There was a second bug related to wrong image display floating around at that time, too. This was the result of database corruption. This was fixed with 1.1. I was never 100% sure which bug that ticket really went with, since we never reproduced it. @VirusKiller definitely experienced the corruption bug. I think you experienced the caching issue.
I know of two “fool-proof” solutions to this class of problem, but both would harm performance. Our image loading infrastructure is wound pretty tight from a performance standpoint.
I think I’m OK with “if you fork the databases and fool around with both branches of the fork, you might need to clear some caches”–for now. I wonder if the upcoming backup feature will expose more issues like this–restoring a backup is an awful lot like what Anders did.
If this becomes a more common issue, there are things we can do.
