Bugzilla – Bug 6073
Cover Art lost when playing a track
Last modified: 2007-11-08 17:04:10 UTC
I have a Beta version of 7.0 - 14351. When I use the Fishbone skin, the cover art does not work correctly. If I enter an album into the playlist, the cover art and the artist name show correctly at the top of the playlist frame for the first track. All tracks in the playlist display the Artist and Album correctly. When the second track starts playing, no cover art is displayed and no Artist name appears, but the artist name is still listed in the playlist. When the third track starts playing, there is still no cover art nor artist name displayed, and in the playlist itself the artist name is no longer displayed for track 2. This behavior continues for all tracks. If I put a new album into the playlist, the first track of that album displays cover art and artist correctly, but subsequent tracks fail. IF i click the first track of an album, the song displays correctly in the left pane. If I click on a track other than the first one of an album (either before or after the currently playing track), nothing is displayed in the left hand pane except the "Play this song" and "Add this song" symbols. Note that the "first track" does not have to be track 1 - it is simply the first track in the album. If I switch to the Default skin, where I can display cover art in the playlist, I see cover art for all first tracks, and cover art for all tracks which have not been played yet. There is no cover art shown for any tracks other than the first one which have already been played. If I had previously clicked on a track while in Fishbone, its cover art is lost even if it hasn't been played yet. Clicking on a first track shows the correct song display, but clicking on any other track shows only the two symbols just as in Fishbone, although the cover art still shows in the playlist display. Even if the cover art shows in the playlist, however, it is not shown at the top when the track is playing (neither is the artist name). The song clicking behavior is the same in the Classic skin as in the Default skin, so this problem seems to be pretty independent of the skin other than what happens when clicking a song in Fishbone. The previous version I had was 7.0 - 14001. In that version I could definitely look at all of the songs correctly in the Default skin, so this seems like at least partially a new problem. I have often seen the artist name be lost in the playlist after a song is played, even in 6.5.x with the Classic skin.
I noticed one other odd thing. If I refresh the browser, the artist name (but not the artwork) appears briefly in the panel at the top of the playlist, and then immediately goes away.
I do not see this with the current builds. Track 2 updates status pane correctly, clicking on tracks 2-10 of a 10 track album shows the songinfo on left side with artwork. Please update and check again. Also make sure that EACH track has valid artwork. The right side status, and song info show only artwork related to the TRACK. Thumbnails may work because they are linked with the ALBUM, which is filled using the first valid track art found for that album. I believe I have posted this before on one of your bugs. Please make sure you have the latest builds before filing. With progress on 7.0 moving as rapidly as it is and with the contest causing a much higher volume of bugs reports, it is even more important than usual. 14351 is nearly 100 revisions old, and there are 3 more recent nightly builds. The main page of bugzilla states: Before you file a new bug, please do the following: 1. Try the latest stable nightly build of SlimServer and see if the bug is still there. 2. Search existing bugs that are open OR resolved to see if your issue has already been noticed. Feel free to update bugs you find with additional information you think may be important. 3. If you do file a bug, please include information from the Event Viewer or log files related to the issue so we can find and fix the problem quickly. Ignoring these shows a level of disrespect for the people already give up a lot of time on this open source project. Please help to keep bugzilla useful as an open access bug tracker.
Deane - sorry. I am trying to track down what looks like a memory leak, and it is difficult to keep updating the software every day. I just got the latest nightly version which is 14406, and I no longer see this problem. By the way - what is the "contest"?
Thanks for updating. If you think the memory leak is SC, then you should focus on that....but you may find that keeping up to date may also eliminate the leak. If it's source is something else, uninstalling stuff temporarily in order to track it would help. Note that as I say this, the nightly build for tomorrow has a caution for updates on windows, preferences may be wiped due to being relocated to the application data folder for the user, or "All Users". the "contest" is also noted on the bugs main page: https://bugs-archive.lyrion.org marking this as invalid, as this is already fixed. If you do see it again, however, please reopen.
I spoke too quickly - the bug is still in 14406. I was trying to fast forward tracks to verify the fix, and the system didn't work as I expected. Note that I can look at the track information for tracks which have NOT yet been played and that works fine, so I know the track data is right. Once a track (not the first one in an album) is played (and shows no artwork or artist), then selecting it produces the blank track panel. The behavior is the same even if I move the first track so it isn't actually the first one played. Since there are lots of changes since 14406, I will get the latest version tomorrow and reverify all of this. I'm being very cautious about reporting a memory leak, since they are very difficult to find unless you really have good data. This one is really strange since it seems to occur on the client machine where I run IE to look at SqueezeCenter rather than on the server where SqueezeCenter actually runs. Is this even remotely possible?
this stinks of something external doing things to the tracks. do you have any plugins, or itunes updating play counts or some such? This is most certainly NOT happening on both of my setups. the only way that you would completely lose the track info display was if the track were to be removed from the db. currently, if a track is detected as changed, then we have to remove and recreate by necessity. thus, my suspicion that you have a third party application or plugin at play. In the absence of any real debug data or replicated case, I can't offer much else. I don't have the kind of time to go through support steps. I'll have to leave that to the support group. You may also want to try taking your issues to the forum for discussion first, as you can end up with more users who either have tripped over or worked around the same problems. IMO, filing bug reports should be a last step, when an issue is truly confirmed, or when all other avenues of understanding have simply failed to clear anything up.
(In reply to comment #6) > this stinks of something external doing things to the tracks. I think this is the same issue from bug 4474. When a track is played, the artwork is lost. I can't tell exactly what's happening, maybe the artwork isn't being found for tracks where cover is NULL. It looks like these tracks are always being detected as "hasChanged" and they get rescanned and updated in the database. This is happening in the new Default skin and in Fishbone when the cover art is displayed in the status pane. Actually, now that I look in my logs, I see a lot of "Re-reading tags" entries, even for tracks that I haven't played. Something screwy is going on and I know for certain that nothing is modifying either the tracks or the covers. [04:03:58.5073] Slim::Schema::_checkValidity (1480) Re-reading tags from file:///F:/flac%20O-Z/Rush/2112/01%202112.flac as it has changed.
I don't have any plug-ins that I know of, and iTunes isn't running. If I have a played track that has lost its track information, I can reinsert it into the playlist. The unplayed version shows all track information correctly, and the played version song panel is still blank. I believe this proves that the database itself isn't changed, and that this is really a bug and not something I am somehow doing. This does sound somewhat like bug 4474, but the fact that the same track gives two different results at the same time seems to make it unlikely that the database itself is being affected. SC must be holding some information about the track which is getting corrupted when it is played. SqueezeCenter runs on a 64-bit version of XP Pro in my system, which seems to be somewhat unusual. I will try the same version of SqueezeCenter on a 32-bit version and see if the problem is the same. Are there some things I can log which will help identify what is going on here? I realize that there isn't anything you can do about this if you can't get it to fail. One question - Deane, you make a comment that there is a "caution" for the 11/7 nightly build. Where would I look to see this - I don't see any readme type files in the nightly download area? I don't want to install a version with a potential issue like this, so how can I tell when there is a version without it?
I added a couple of debugging statements to _hasChanged() and I'm finding that _hasChanged() thinks the timestamps on these files have changed. [06:36:48.9541] Slim::Schema::_hasChanged (1519) Checking for [E:\flac A-N\King Sunny Ade\Juju Music\04 Sunny Ti De Ariya.flac] - size & timestamp. [06:36:48.9557] Slim::Schema::_hasChanged (1563) File has changed. Reason: timestamp is different. Database: [1188863626] File: [1188860026] Off by 3600. This the old Windows daylight savings time quirk. When a DST time change happens, all file date/times reported by the OS are shifted by one hour. I just ran a full clear/rescan. No more incorrect _hasChanged() are being logged, so no tracks being updated. Apparently the previous scan was done prior to the time change on Sunday. So the workaround is to run a clear/rescan following a time change if the server is running Windows. Is there a programming fix? The only thing I can think of would be to record the date and time when a scan runs and then SC could see whether a time change occured and either add or subtract one hour from all track timestamps in the database. I'm not sure that's really workable.
Steve, when was the last time you did a full clear/rescan? Try running a clear/rescan to update all of the timestamps in the database and see if the problem goes away. If SqueezeCenter doesn't think the files have changed then they won't get updated in the database when they're played.
I haven't rescanned for several days. I will do that now, and see if perhaps the Daylight Savings Time change is causing this.
Steve: The "caution" comes from checkin comments. If you watch the checkins mailing list, you'll see these. This is the main caveat when you use beta versions of the software (more to the point, the "trunk" version). It seems to have cleared up now after further rework on the installer. Tomorrow should be safe again for most cases. also, It's Kevin. Deane is part of my surname :)
QA to try to reproduce
I did a "Clear Library and Rescan" and now things seem to be working correctly, so I suspect that Jim's idea that this was caused by the time mismatch due to the Daylight Savings Time change on Sunday may be correct. Kevin - I can't find mailing lists anywhere on your site. If I look under Community/Resources, there is a "Mailing Lists and Forums" selection, but choosing that only gets me to Forums (none of which is named "checkins"). Where should I look for this?
Chris do you still want us to take a look at this?
This is starting to sound like it's a dupe of bug 5941 Steve - it's not MY site. I'm a volunteer, not an SD or Logitech employee. Slim Devices lists (via google) http://www.google.com/search?hl=en&q=slim+devices+list+checkins&btnG=Search Third result gives you all available mailing lists for SD.
(In reply to comment #16) > This is starting to sound like it's a dupe of bug 5941 Yep. Same issue. Believe it or not, change 14469 from bug 5159 actually fixes this. The DST weirdness with file timestamps was just what was triggering it for Steve and I. To duplicate this bug: - Stop the server. - Update SC7 to revision 14468. - Modify the mtime on one album's worth of files. - Restart the server. - Navigate to the album and play 'All Songs'. At this point, SC7 will see that all the files have changed timestamps and will (one by one) delete the files, rescan them, then add them back to the database with new track id. If you closely watching the playlist in the new Default skin with artwork enabled you can probably see that at first they have artwork, but then the artwork disappears. To see the fix, perform the same steps above with SC7 at revision 14469 or higher. SC7 still sees all the files as having changed, so it deletes, rescans, and then adds them back into the database, but with the original track ids it now finds the artwork.
Are you saying this bug no longer exists? Can I close it then, or is there something left that needs work? Thanks!
I was able to make this bug recur with version 14406, by changing the artwork in an album already in the playlist. Thus I suspect that the error was caused when the date on the file changed. Today I downloaded version 7.0 - 14500, and I could not recreate the problem, so it appears to be fixed.
Thanks for checking, Steve! If anyone's still seeing this in the 7.0 nightlies please re-open!