Bugzilla – Bug 2977
Browse Artists - shows blank entry if only one album with no name
Last modified: 2008-09-15 14:38:10 UTC
I have various tracks which don't have an album name. If I click on Browse Artists and choose the artist, I get a blank entry See example one here: http://www.jimwillsher.eclipse.co.uk/Noname1.jpg If I then find the music by title instead, the entry shows with a blank album instead of "No album". See example two here: http://www.jimwillsher.eclipse.co.uk/Noname2.jpg Shouldn't these tracks get assigned the "no album" text? Without the "no album" text you can't click the track to display info for it. Only if you search by track name (not artist) can you see this.
Created attachment 1135 [details] Image 1
Created attachment 1136 [details] Image 2
bugzilla home pages does say to at least try 6.2.2 before reporting bugs, so please confirm with that.
another thing to check, that the album tag in question is actually no album tag vs an album tag of "" (empty string)
Sorry, it was the 20th January nightly, e.g. 6.2.1++++ How can I check if it's "" versus "no album" ? I use a Windows utility to set tags (JJ Renamer), and it looks like an empty string. Slimserver shouldn't make any differentiation between null versus "", as the typical "end user" won't know any difference (and cannot see any difference).
I understand that. However, there is a difference in handling empty versus not there. Undefined tags are set as "no Album" and the ui does skip them. however, the song info page should only show the album tag if it exists. This would seem to indicate that in your case it is simply empty. This changes what needs to be done to get the end result. If the developers do not understand the exact conditions of your case, then the problem will likely not get a correct fix.
Yep, I agree. But how can I help the developers if even I can't tell if it's empty of null? I've done a full CLEAR and RESCAN, and the problem seems to have resolved itself. This is with me making no changes to the MP3 file itself. Here's the subsequence SQL dump: INSERT INTO `tracks` VALUES (197, 'file:///slim/music/Toto/Africa.mp3', 'Africa', 'AFRICA', 'AFRICA', 39, 3, 'mp3', 1, 1112227200, 11832093, 11830608, 313, 1997, 295, NULL, NULL, NULL, NULL, NULL, 320000, 44100, NULL, NULL, 1, NULL, NULL, 'ID3v1 / ID3v2.3.0', NULL, NULL, NULL, NULL, NULL, NULL, 1, 0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, ' NO ALBUM 003 AFRICA'); INSERT INTO `albums` VALUES (39, 'No Album', 'NO ALBUM', 'NO ALBUM', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); However I've seen this go wrong (and right) in the past, so I think it's definitely some fault in the scanning process. Next time I encounter this issue I'll get the SQL Dump again and report it here - as the Rescan has corrected all the entries.
Seems to be resolved in the latest nightly, I'll monitor it.
In 6.2.2, there have been no changes to resolve this. This would suggest that it is something post-scan that is getting in the way. If this occurs again, please try to recall that last time you noticed that the tag was correct, and what you were doing around the time that it changed. thanks.
Jim - sounds like this is fixed. Please reopen if you can reproduce again. Thanks.
Excellent! Well done guys! What's the timescale for a formal 6.2.2 release? It seems to contain dozens of fixes that I could use, but as I'm running slim on Debian with MySql it's not a quick job to upgrade - hence I only do it once in a while. Is it due soon?
Jim - we're trying to get 6.2.2 out today, actually.