Bugzilla – Bug 241
sorting by "sort order" tag fails after restart, works after rescan
Last modified: 2008-10-02 14:57:07 UTC
start slimserver and point it to a music library that makes use of "sort order" tags (TSOP in the case of id3v2.4 artist sorting). select "Browse by Artist" in the web interface, and notice that everything is sorted as you'd expect (according to "sort order"). stop and restart slimserver. select "Browse by Artist" in the web interface, and notice that everything is now sorted by "Artist" tag and not "sort order". go into server settings, and select "wipe cache". select "Browse by Artist" in the web interface, and notice that everything is sorted according to "sort order" once again. (until the next restart at least.)
what about when not using the mp3 tag cache?
if mp3 tag cache is turned off and the server is restarted, things come up sorted correctly (according to the "sort order" tag). Not too surprising, since this effectively forces a rescan, and the sorting is correct after initiating a rescan. so it seems the tag cache isn't correctly handling sort order tags?
The sorting information is cached as well, so a reascan is really necessary. We could trigger this automatically when you change that setting.
Isn't the whole point of the tag cache, that you don't have to do a full rescan on startup?
That's right, but if you change a setting that affects data in the cache, we generally rescan the cache.
the cache setting was only changed to answer the question posed in comment #1 above. the core issue here is that the server behaves differently after a restart than it did before the restart.
This coudl be an issue IF the cache was created at some point before you set up your sort order tags. What you might want to try, is enable the cache, then press WIPE CACHE from the server settings, at the bottom, below the Cache setting. This way you can make sure the DB cache information has nothing to do with it. If this fixes the issue, then it might indicate that the cache algorithm might be missing sort order info, OR not have realised its been added since the DB file was created.
ok, here's what I just tried... installed slimserver 5.1.1 on a new machine that never had slimserver on it before, and which nfs mounts a pre-existing music collection with lots of sort order tags (id3v2.4 TSOP in particular). start slimserver.pl, point it at the music directory, and configure it with "mp3 tag database" set to "cache". wait for scanning to finish. select "Browse Artists" and note that listing is sorted "correctly" (acording to sort order tags). restart slimserver select "Browse Artists" and note that sorting is by artist name and not sort order tag (referred to as "incorrectly" for the sake of breviety in the remainder of this ticket). hit "wipe cache" in server settings. select "Browse Artists" and note it's sorting "correctly". wait for it to finish the rescan. (and note that it's still sorting "correctly"). restart slimserver select "Browse Artists" and note that it's once again sorting "incorrectly". hit "rescan" in server settings. wait for it to finish, and note with some mild surprise that it's still sorting "incorrectly". hit "wipe cache" and verify that it is once againg sorting "correctly". restart slimserver again once again note "Browse Artists" is sorting "incorrectly" hit "wipe cache" and notice it's again sorting "correctly" wait for it to finnish rescanning while mumbling somethnig about how long it takes to scan through 17,376 files and my hopes that tag cache can be made to work correctly. stop slimserver change to a new directory and check out the latest slimserver from cvs (as of 2:14 pm pst April 8) start slimserver (cvs version) and point it at the same music directory and ensure that "mp3 tag database" is set to "cache". notice that "Browse Artists" is sorted "incorrectly" (probably reading the cache db from the 5.1.1 install, but that's ok because I'm about to...) hit "wipe cache" notice that it's now sorting "correctly". wait for the rescan to finnish. (noticed a few other problems, but not ones directly related to this issue.) restart slimserver verified that it is again sorting "incorrectly" (i.e. latest cvs doesn't fix the problem). hit "wipe cache" again and see it sorting "correctly" yet again. This seems to be very reproducable, and as near as I can tell, it certainly looks to be related to the tag cache.
erm...thanks. once was enough tho :) my guess is that the MP3 Tag cache is either not saving or not restoring the sort order information. I had hoped that wiping the DB might help, but clearly not.
This seems to be fixed in slimserver 5.1.5 Thanks!
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.