Bugzilla – Bug 11722
Random Mix on Web UI presents list of Genres in wrong order
Last modified: 2009-10-05 14:33:54 UTC
The list of genres presented on the Random Mix page in the web UI appears to be a sorted by the NAME field in GENRES. Since the GENRES table in the db contains a NAMESORT column, shouldn't the list of genre names be sorted by the NAMESORT value? Isn't that what it's there for?
Would the following work? Index: D:/eclipse/7.4/server/Slim/Plugin/RandomPlay/Plugin.pm =================================================================== --- D:/eclipse/7.4/server/Slim/Plugin/RandomPlay/Plugin.pm (revision 25881) +++ D:/eclipse/7.4/server/Slim/Plugin/RandomPlay/Plugin.pm (working copy) @@ -531,8 +531,8 @@ - my $rs = Slim::Schema->search('Genre'); + my $rs = Slim::Schema->search('Genre', undef, { 'order_by' => 'me.namesort' });
Sorry, that didn't work for me in either the 7.3.3 or 7.4 svn code. I also tried changing the similar line at 1111...to no effect. Genres still appear alphabetically sorted by NAME on the web page, not by NAMESORT.
Maybe if you could explain how you could end up with a NAMESORT which is different from NAME, this might help reproducing this issue...
Ah, I see. It's sorted in the web page template again, using TT's sort function (http://template-toolkit.org/docs/manual/VMethods.html#section_sort_nsort). This means we'd have to introdue a helper variable with the NAMESORT sorted items. Requires a bit more work.
Is is possible / easier to simply turn off sorting of this data by the TT? When I fetch my list of genres via the CLI (with no sorting as far as I'm aware) it returns them in the correct order.
Sure, it's no complicated fix, but it needs more than a one line change.
Re NAMESORT != NAME: I tag all my music such that GENRE == music history period of composition. And I want the genre names listed in historical / chronological order, E.G.: a_Medieval b_Renaissance c_Early_Baroque ..etc. I've modified /usr/share/squeezecenter/server/SQL/mysql/schema_optimize.sql, adding a post-scan update query to fix up the genre names to remove the alpha ordering prefix: UPDATE genres set name = CASE when name = 'A_Medieval' then 'Medieval' when name = 'B_Renaissance' then 'Renaissance' when name = 'C_Early_Baroque' then 'Early Baroque' ..etc. This, of course, leaves the NAMESORT column alone so that the NAMESORT data remains: A_MEDIEVAL B_RENAISSANCE C_EARLY_BAROQUE ..etc. Thus, I get the best of both worlds: on the web UI, on the SB displays and on the SBC, I get my "pretty" genre names, but the list still obeys the NAMESORT order. E.G.: Medieval Renaissance Early Baroque ..etc. It's my intention to someday write a 'PostScan' plugin that would allow folks to run such "pretty-up" update queries automatically after scans without having to hack on schema_optimize.sql. So yes, I'm a big fan of the fact that SC's db contains NAMESORT columns in many of the tables. I'm assuming that Dan originally added NAMESORTs to the data definitions for exactly this sort of reason. =================================================================== Anyway: as I indicated when I flagged this "bug" as trivial, this is really, really trivial. If it requires a more-than-one-line change or actual thought on your part, please back-burner this. I may be the only user affected by this.
change 26417 - please test The sort order was broken on all interfaces, not only the web UI.
This fix works perfectly for me. Thanks! I tested using the web UI (via Chrome) and with iPeng. Didn't test with SBC as I don't want to update my SBC firmware to 7.4 yet.
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.