Bugzilla – Bug 2322
VA Album is split when tracks of the album are saved in a playlist
Last modified: 2008-09-15 14:39:24 UTC
Since at least subversion 4566 (maybe earlier) the following bug occurs: I have some saved playlists (only in the database, not on disk) comprising single tracks of different VA albums. All these VA albums are shown twice in the browse albums list. One entry comprises all tracks of the original albums starting with the track which is in a saved playlist and the other entry comprises the remaining tracks of this album. For example, if the original album comprises 10 tracks and I add track no. 7 to a saved playlist than after a full rescan (wipe and scan) the album is listed twice in the browse album list, one comprising tracks 1-6 and the other tracks 7-10. All tags are set correctly. I can reproduce this error by simply placing a track from an album, which was correctly shown only once in the browse albums list, in an existing playlist. After a full rescan the album is splitted as mention above. As soon as I delete the track from the saved playlist and make a full rescan the album is again shown correctly as ONE album comprising all tracks in the browse albums list. All albums from which no track is saved in a playlist are correctly listed only once. This problem only happens with VA albums.
Do these albums have a Compilation tag?
Yes, in track info compilation is set to "Yes". I don't have set it manually but it seems to be set automatically by Slimserver.
By "Full Rescan" - do you mean wipe & rescan? Also, fyi - once you save a playlist in the database, SlimServer also writes it out to disk as a backup.
Yes, I mean wipe and rescan. Beside my regular system (with about 6000 songs) I have a test system on a different computer with only a sample of songs. I had the bug on both systems. On the test system I playes aroung with the saved playlist, added some songs to and deleted songs from the playlist created new playlists and all of a sudden after a wipe and rescan all album entries were correctly shown although still songs are stored in a playlist. But on my regular system I still have this problem (and it is not so easy to make all these amendements since wipe and rescan takes always about 15 minutes). I have already tried to copy the saved playlist from disk to another place, delete all playlist in slimserver, copy the saved playlists back and wipe and rescan to recreate the playlist in the database. But the bug still appeared again. At the moment when I want to wipe and resacn as a workaround I copy the playlists from disk to another directory, delete all playlists, wipe and rescan, copy the saved playlists back to the playlist directory and rescan only playlists. This does not split the albums (but is a pain).
I have found some hints what could cause the problems. In fact there seem to be (at least) two different problems involved. First, there seems to be a problem with accented characters in file names (not in tags). As soon as I add a song with an accented character in the filename to a playlist the problem appeared. The album was split and in some cases the song with the accented character in the filename was not included in any of the two album entries but suddenly under "No Album". As soon as I deleted the song from the playlist and made wipe and rescan everything was fine again. Second, I found that the server setting "Specifiy a list of Common Album Titles" also has an influence. Until now I did not set this option. I read in the forum that someone else had the problem that all tracks of his VA albums produces separate entries in the album list and the setting the option "Specifiy a list of Common Album Titles" solved the problem. Thus, I set also this optin and suddenly the album was no longer split but the "no albums" entry was still there (and the song with accented character was not included in the album but only in "no album"). Note that the concerned albums did not contain any string like "Greatest hits" which are defined under "Specifiy a list of Common Album Titles". But there are songs of such albums included in the playlist (could this cause the problem?). I have for each album a separate directory on disk, so I thought the option "Specifiy a list of Common Album Titles" should not change anything. I tried now the present official 6.2 version and found that with this version there are also problems with accented characters in file names which are part of a saved playlist. First when I tried to add such a song to the playlist and saved this playlist the song was not included when I browse to this playlist again. After a next wipe and rescan there was suddenly an additional playlist "Undefined" which was not there before and which contained one song of the original saved playlist (but not the song with the accented character). I am quite sure that all these problems are related to accented characters in track file names and if such a song is part of a stored playlist. Maybe this is a starting point to begin with?
Created attachment 939 [details] Testfiles for reproducing this bug I have created a zip file containing some test songs (only 2 seconds samples), a playlist, my slimserver database and my slimserver.pref file. With these songs and this playlist and version 6.2b2 subversion 4753 the described problems can be reproduced. The Albums "NDW" is splitted and in addition two tracks of this album (the tracks of artists "Abwärts" and "DÖF" are found under "no album" although they are tagged correctly. This is when "Specifiy a list of Common Album Titles" is NOT checked. If it is checked after wipe and rescan there is only one album entry of "NDW" but there is still the incorrect "no album" entry. It seems that with the official 6.2 version there are some changes as described in my previous post. Do you need anything else to test? Can you reproduce the problem with these files?
While the described problem with accented characters seems to be always reproducable, the first mentioned problem of splitting albums at tracks which are stored in a playlist (and have no accented character in the file name) does only appear for certain VA albums.
The problems with accented characters in file name which are stored in playlists do still exist with 6.2.1 of 2005/10/30. As soon as I amend the file names to have no accented characters the problems are gone (after wipe and rescan and creating new playlists). It seems that accented characters in the tags do not cause any problems only in file names. Could you verify the problems with the uploaded attachment?
I further just recognized the following: Immediately after adding a track, having an accented character in the file name, to a saved playlist and saving the modified playlist (but before wiping and rescanning the library) the albums are still shown correctly but when listing the tracks of the saved playlist not the track name but the file name is used in the track listing of this playlist. After a wipe and rescan, in the listing of the playlist the track names from the tags are correctly used (and no longer the file names) but now the albums are messed up and the concerned tracks are listed under "no album".
Dan, do you need some more information regarding this bug or are the attached testfiles sufficient? Dieter
Dieter - this is too complex and confusing. Pushing off of 6.2.1
With the nightly of 2005/10/17 of 6.2.1 (subversion 5210) I just saw the following behavior: When you try to add a /single/ track having an accented character in the file name to the end of an existing playlist, after clicking on save, checking the "confirm overwrite" box and finally clicking on rename, this song is /not/ added to the playlist. Before clicking on rename it was still shown on the left side window showing all tracks of the playlist to be saved. But after clicking on rename it dissapears from this left side window. On the right side of the window where the now playing playlist is shown the track is still shown (together with all other tracks of this playlist). The behavior seems thus to be different dependig on if you want to save only one or several tracks with accented characters to a playlist. Another point: Should the title of this bug be changed? At the moment I have only the described problems relating to accented characters in file names (creating no album entries in the browse album list and not storing tracks to a playlist). The originally mentioned additional problem, that an album is split even if there is no accented character in the file name does no longer appear on my system (at least since I checked the "common album titles" option.
Dieter - is this still happenning in 6.2.2 or the 6.5 nightlies? Thanks
After a quick test with version 6.2.2 - 6891 (on Windows XP) it seems that there is only one problem left. I can no longer reproduce the "split" problem of VA albums and also no longer the "no album" problem. But there is still a problem with accented characters in file names when including these files to a playlist. Such files can still not be added to a playlist. In comment 12 I have written that a song having an accented character in its file name dissapears after clicking on "rename". This has changed. Now the song is still visible after clicking on rename but when I restart browsing playlists and enter into the playlist all files having an accented character in their file names are no longer included in the playlist. If I make then a wipe and rescan nothing changes, the songs are still not shown in the playlist. But if I look in the playlist file which is stored on disk the songs are still listed there. As soon as I change the accented character in the file name and create a new playlist comprising this song everything is fine although the title tag still contains the accented character. So it is still only a problem with file names not with tags.
Ok - I think I see what's going on here. How are you creating the playlist? In SlimServer? Or using an external program? Thanks
Fixed in change 7131
(In reply to comment #15) > Ok - I think I see what's going on here. > > How are you creating the playlist? In SlimServer? Or using an external program? > > Thanks > I created the playlist in SlimServer. I will test the fixed version as soon as the Windows installation file is available.
Please download our 6.2.2 Release Canidate - http://www.slimdevices.com/downloads/SlimServer_v6.2.2/
(In reply to comment #18) > Please download our 6.2.2 Release Canidate - > http://www.slimdevices.com/downloads/SlimServer_v6.2.2/ > Great, it seems to work now perfectly! I created several new playlists with different files having accented characters and all were fine. Thanks a lot.
This bug seems to be back in Version 6.3.0 - 8118 - Linux - DE - utf8 (I switched from the Windows version to Suse Linux 10.0 recently). I have now again a lot of different problems when I try to add a song having an accented character in its filename to a playlist (in the web server interface). Most of the time the song cannot be added, it simply does not appear in the left pane (saved playlist window) when I click on "save" in the right pane showing the now playing list which was created by adding all songs of the saved playlist to Now Playing and adding one song having an accentec character in the filename. Sometimes the song can be saved but after a wipe and rescan there is an empty line when I list the contents of the saved playlist. Somtimes the song is still listed in the playlist but when I click on the song in the playlist to show the song info, the song info page is empty. As soon as I change the filename (or directory name) to comprise no accented character and make a wipe and rescan everything is fine. Please try to find this for the release version of 6.3 since I have a lot of songs with accented characters in the filename.
Dieter - nothing has changed in this section of the code. Are you sure nothing has changed on your end? We're down to the wire on 6.3, I highly doubt this is a show stopper. Are your test files still valid?
On my end has changed that I switched from Windows to Linux. Could it be dependent on the OS (version, language...)? I need some time to test it in more detail. In my present working system it takes too much time to wipe and rescan for testing. I just tried to make a test system with only few songs but there were additional problems. For example, in the test system the saved playlists were not automatically saved to disk (in the playlist directory). In my working system they are, I don't know why this is different. And in the test system the bug only appeared after I forced saving the playlist to disk (by using the "download" button in the web interface). As long as the playlist was not saved to disk the entries with accented characters were ok. But after a wipe and rescan the playlist was completely dissapeared. When I saved the playlist to disk (using the download button) the described problems appeared. So can it seems really to be a file/directory specific bug and not a tagging problem (a utf-8 problem?). And I had also the effect that a wipe and rescan was not the same as deleting the file .slimserversql.db manually from disk. Once when I made only a wipe and rescan I had suddenly for one of the artists having accented characters in its name (and thus in the directory and song name, I have an "musikfolder/artist/album/tracknumber-artist - title.mp3" structure) two identical artist name entries (with all identical albums below) in the browse artist list. Only after manually deleting the .slimserversql.db file the second entry dissappeared.
Ok - you just opened a whole 'nother can of worms. Make sure your LC_CTYPE is set correctly, and your filenames have that same encoding.
ping
Sorry Dan, I had a very busy week. I will try to reproduce the bug on my test system this weekend. Since I only recently switched from the Windows version to Linux I am not very familiar with Linux. Where do I set my LC_CTYPE and how do I check that my filenames have the same encoding. Usually I do not have a keyboard and a monitor connected to my linux server but use vnc from my windows machine to connect? From there all German umlauts look correctly. Is that sufficient?
I just found (with printenv) that LC_CTYPE is set to de_DE.UTF-8 but where do I find the encoding of the filenames?
Subject: Re: VA Album is split when tracks of the album are saved in a playlist >I just found (with printenv) that LC_CTYPE is set to de_DE.UTF-8 but where do I >find the encoding of the filenames? You don't really.. if they were copied over from a Windows system, they might be encoded as ISO-8859-1. It depends on how they were copied. If they were ripped on the Linux box, they should be UTF-8 encoded. Would it be possible for me to get a ssh login to your machine? Send me an email - dan | at | slimdevices.com Thanks
There were a bunch of Various Artists related changes that went in yesterday, please try with the latest nightly.
Are the changes only in the 6.5b or also in 6.3.1. I recently tried to install 6.5b but didn't get it to work. At the end I was very happy when I got 6.3.1 running again. It seemed that the installation of 6.5b messed something up that even after an uninstall 6.3.1 was no longer running. In the nightlies I found only the 6.5b version. Will there not be nightlies for 6.3.1 in parallel (like it was with 6.1, 6.2 and 6.3)?
Subject: Re: VA Album is split when tracks of the album are saved in a playlist We are only working on 6.5 at this point. There will not be a 6.3.2 or any nightlies for 6.3 I'd like to verify if this is fixed for you in 6.5
Dieter - any update here?
Sorry Dan, I missed your last post. I still use 6.3.1 but I will test 6.5 during the next days (hoping that I won't have all the problems I had the last time).
I don't get 6.5 to run on my Suse Linux 10.1 system. I installed the rpm package, made the changes on the slimserver /etc/init.d and /etc/sysconfig script described in the wiki and start slimserver. It runs very shortly and then crashes. In /tmp/slimserver.log the following errors are shown: 2006-08-24 01:56:12.2962 Use of uninitialized value in pattern match (m//) at /usr/local/slimserver/Slim/Utils/Prefs.pm line 1077. 2006-08-24 01:56:12.3351 Use of uninitialized value in join or string at /usr/lib/perl5/5.8.8/File/Spec/Unix.pm line 81. 2006-08-24 01:56:12.3354 Use of uninitialized value in join or string at /usr/lib/perl5/5.8.8/File/Spec/Unix.pm line 81. 2006-08-24 01:56:12.3362 Use of inherited AUTOLOAD for non-method YAML::Syck::Dump() is deprecated at /usr/local/slimserver/Slim/Utils/Prefs.pm line 975. Can't locate auto/YAML/Syck/Dump.al in @INC (@INC contains: /usr/local/slimserver /usr/local/slimserver/CPAN/arch/5.8.8/i586-linux-thread-multi /usr/local/slimserver/CPAN/arch/5.8.8/i586-linux-thread-multi/auto /usr/local/slimserver/CPAN/arch/5.8/i586-linux-thread-multi /usr/local/slimserver/CPAN/arch/5.8/i586-linux-thread-multi/auto /usr/local/slimserver/CPAN/arch/i586-linux-thread-multi /usr/local/slimserver/lib /usr/local/slimserver/CPAN /usr/local/slimserver /usr/local/slimserver /usr/lib/perl5/5.8.8/i586-linux-thread-multi /usr/lib/perl5/5.8.8 /usr/lib/perl5/site_perl/5.8.8/i586-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/i586-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl .) at /usr/local/slimserver/Slim/Utils/Prefs.pm line 975 I have version 0.53 of YAML installed.In an previous post Andy recommended to update to the latest YAML::Syck version by using "sudo cpan YAML::Syck". I tried this but at the end make test has some errors and does not install. After 3 hours I will now try to go back to 6.3.1. I hope it will work again. Do you have any ideas what I can try to get 6.5 running? Dieter
Since I got 6.5 not running under Suse Linux 10.1 I switched back my music server to run under Windows XP. I installed 6.5 and in the Windows version the problems with accented characters in file names which are part of a playlist do no longer exist. Either 6.5 solved the problems or the problems exist only in the Linux version (which I can no longer test).
Ok.