Bugzilla – Bug 5159
Album thumbnail lost when music file mtime changes
Last modified: 2008-12-18 11:12:53 UTC
To recreate: Browse to a web page where an album thumbnail is visible (browse Albums or Artist in gallery mode). Then modify the _music_ files in the album so that the mtime (date modified) is changed. Then browse to the same page in the web ui. Refresh the browser's cache if necessary. You should now see a 'missing artwork' image. Examining the database, there could be several problems. First, it seems that when the updated album is browsed in the web interface, SlimServer deletes the original track record containing the artwork reference, then creates a new record. Why doesn't it just update the existing record? None of the other track recods from the same album get deleted and recreated, only the one with the artwork data. Second, the album record's 'artwork' column remains pointing at the deleted track record. Third, the artwork image reference in the new record is only set in the 'thumb' column, not the 'cover' column.
*** Bug 5187 has been marked as a duplicate of this bug. ***
I'll see if I can get someone to give us an indication about whether this is sane to fix for 6.5.4. Steven, in the mean time, could you see if this also happens under 7.0? Thanks!
You may not want to get into something like this for just 6.5.4. A changed track is currently deleted when the change is detected. This makes sure that all of the former relationships for contributor, genres, etc are cleared completely because we cannot assume any of that still exists (ie hasn't been changed as part of the file modification). The "new" track is then created fresh but without the post-processing. Ideally, updating would be nice, but we'd need to make sure any changed relationships are cleared and re-done. Alternatively, we need a way to do the post-processing when a file change is detected. I can verify that this problem happens in 7.0 as well.
When the cover art is requested, the track used for art is checked for changes, while the rest are left alone. A check for artwork only results in an update if the album shows as not having artwork. A simple fix is to quickly delete the album artwork reference before deleting the track, but then each track on the album causes the same delete and recreate cycle on refresh until the album tracks are all updated. Another option is to update the album artwork id with the new track id if the track id deleted is a match for the album artwork id.
Created attachment 2104 [details] update artwork id on track id change If a track is found to have changed, and is also the track used for the artwork id then this patch (for trunk) will update the artwork id after the track id is updated. This may be simple enough to be safe for 6.5.4 as well, with the obvious required change in the debug message call.
committed at change 12841. reopen if there are issues. this is for 7.0a only.
Is there _any_ way to accomplish this without deleting the track record and then readding it to the database? I know it would be a lot more work to update the relationships correctly, but I'm fairly certain that it can be done. This delete/add stuff can cause all kinds of problems.
I just thought of something. How about deleting the track (to handle the relationships) and then adding it back into the database with the same track id? In MySQL I know that you can insert into a table and designate a value for the PK column even if the column is designated auto_increment.
MySQL may be able, but SC uses DBIx to talk to MySQL, so it matters more what DBI can do. patches welcome, as it's more trouble than I'd like to dive into. If possible, bit's an interesting idea.
Created attachment 2377 [details] Preserve track on update This seemed pretty simple. DBIx treats the id field the same as any other when creating the new record. This also eliminates the need to update the album's artwork id.
Created attachment 2378 [details] Preserve track on update whitespace fix
in that case, I'll try to give it a test today and merge it in. thanks.
Looks good here. merged in at change 14469 for some bake time. please reopen if thee are any issues. thanks Jim!
This bug is being closed since it was resolved for a version which is now released! Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html If you are still seeing this bug, please re-open it and we will consider it for a future release.