Bugzilla – Bug 10180
Add "index" and "sorted_element" to "albums" and "artists" queries on CLI
Last modified: 2009-10-05 14:34:35 UTC
It would be very useful to be able to get an index element and/or the element by which the table was sorted with queries. Currently, in iPeng I have to re-sort any tables, because I don't have any information, where the A,B, C, etc. categories start and I would need that information to build the quick-access index. The information returned by the queries currently is NOT sorted. I do already subtract the content of the "ignoredarticles" field, but there are cases, where a table is being sorted, e.g. by another artist than the one delivered. For example: I have an Album that returns "Beginner" as the Artist but is being sorted under "A" for "Absolute Beginner", or another one returning "Neneh Cherry" but showing up under "Y" for "Youssun N'Dour". So currently there is no way I get around sorting, which is not a good situation since it will result in different sort oders on iPeng and the WebUI and also SC has more information to do a sorting and may thus do it better... What I would like to see is at least one of two additional parameters: "index" adding one of "A-Z", "#" to each item "sorted_element" containing the actual field (content) used for sorting
Andy/Brandon: How feasible is this for 7.3[.1] for iPeng?
Dean - I think that's a pretty simple change. As we're already returning the first character of the sort value in menu mode responses (they're used to display the large background character when scrolling on Jive), the code is mostly there. Just not in the right place. Eg. in artistsQuery we're using the following line: 'textkey' => substr($obj->namesort, 0, 1), 'textkey' is what should be the requested index, $obj->namesort the sorted_element. Right?
Created attachment 4365 [details] sample patch for the artists query Pippin - would this about do what you want?
Michael, if this works as I think it does, it's exactly what I want.
Michael, I finally found time to test this. It's pretty much exactly what I want. Now it needs to be extended to the other queries, at least "Albums", that's where I need it most. Also, inventing parameter tags to select these options would be nice to get the table size low (I will only need one of "sortkey" or "textkey" at a time, others might not use it at all).
Jörg - how important/urgent is this for you? I'm punting it post 7.3.x, as it requires a bit more code for the other cases where we support the textkey.
Well, I have zero chance to use the lists as they are without it, I understand the Menu Mode queries also only support this for Artflow? Or do they have a complete set? I don't like those queries for the big tables since they are pretty verbose and take up a lot of memory and slow things down. I also have some trouble sorting very long lists (just stumbled over a guy with 14.000+ albums) but I MIGHT get that solved without the index, it would just make things a lot easier.
Would it be possible to at least add this for "albums" and "artists" for 7.3.2? I'm having trouble with some people having REALLY large databases (as in 14.000+ albums) and I don't see a way to make iPeng work with that size of a database with sorting - iPhone sorting simply takes up too much memory.
change 24540 - add support for textkeys in raw CLI queries for albums, artists, genres and musicfolder. Use new 's' tag to get additional sortvalue and textkey. Please test _soon_ - thanks!
Would it be possible to select just ONE of the values (textkey OR sortvalue)? The sortvalue can take up quite a bit of space and I'm trying to build indexes for the albums list. Or are all alphabet characters already used up?
Do you need the sortvalue at all? I'd be happy to remove it.
That's fine. I just use the textkey.
change 24554 - remove the sortvalue, it's not needed. I consider this done. Thanks!
Isn't this in 7.3.2 anymore?
textkey should still be there. Doesn't it work for you?
works fine. Just got a mail that the bug was moved to 7.4
I'm sorry for the confusion. Some bugs got accidentally changed during a mass change.
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.