Bugzilla – Bug 4222
Menu limits displayed entries beginning with 'Z'
Last modified: 2008-12-18 11:11:58 UTC
Further to my attempts to implement a workaround for the issues discussed in Bug 4020 (sorting of '[' character), I tried retagging a large number of items in my library by prepending "ZZ_" onto the artist, title, and album, in order to sort them to the end of the list(s). When I list the artists at the end of the alphabet now, I get this: 1538 albums with 31723 songs by 778 artists. Items 523 to 572 of 778 1 A B C D E F G H I J K L M N O P Q R S T U V W Y Z (Y and Z boldfaced) All Albums Yartist1 Yartist2 Yartist3 Yartist4 Yartist5 Yartist6 Zartist1 Zartist2 Zartist3 Zartist4 ZZ_segregatedartist01 ZZ_segregatedartist02 ... (segregated artists 3..39) ZZ_segregatedartist40 Possibly the display on the final page is limited to 50 entries no matter how many entries are actually present? That certainly is not a limit on the other pages in the menus; I have one that shows 200 entries. In this case, as far as I can tell there is no way to see items 573 of 778. The same things seems to happen for albums. Although my particular case is pathological, I believe this is a legit bug. The system should not artificially limit the number of Y and/or Z entries. Unfortunately, for me personally, this means that the workaround that was suggested to me for the other bug, to put something on the front of the tags to get everything to sort together, is not working. Possibly it would have worked if I had used 00 or AA, but I really prefer this stuff to come at the end.
I can reproduce this. Dan, please let me know if you want the test files I created to repro. I created a large number of files with different title, artist, and album tags. When you go to the last page of artists listed, there are still many after that with no way to get to them. A kludgy workaround is to set the Server Settings -> Interface -> Items Per Page to a value larger than the number of artists that you have in your collection. Then all artists will appear on the same page.
I should specify that, as Matt did, I set the artist tags to all begin with "ZZ_"
>>A kludgy workaround is to set the Server Settings -> Interface -> Items Per Page to a value larger than the number of artists that you have in your collection. Then all artists will appear on the same page.<< Kludgy, but it does help, thanks. I settled on setting the items per page to somewhat more than half the total number of artists, so that the first page gives a good chunk of them and the second page gives all the rest, and avoids the bug. Setting the items value to a big enough number to bring them all up in one go caused a fairly long delay for the page to come up, which I didn't like, so I cut it to something more than half.
As an additional note, having rolled back to 6.3 to test another bug, I note that this problem does not exist in 6.3. It appears that the Z choice can have as many entries as it needs. I set the number of items displayed back to 50 (having had it at 425 to work around this bug), and the menu for "Z" displays something over 200 items.
possible fix: Index: Slim/Web/Pages.pm =================================================================== --- Slim/Web/Pages.pm (revision 11761) +++ Slim/Web/Pages.pm (working copy) @@ -509,6 +512,10 @@ unshift @pagestarts, $nextend; } } + + if ($newend == $end && $itemCount > $end) { + $newend = $itemCount -1; + } $pageinfo{'enditem'} = $newend; $pageinfo{'totalalphapages'} = scalar(@pagestarts);
Hm. KDF, in Dan's absence, should I try to get Dean to review your changes? I'll try it and see what happens.
Someone who is more readily able to reproduce the problem should give it a run and let me know. I happened to have a set with 3 V artists at index 50, 51 and 52, which showed the problem on a 50-per page setting. It worked for my case, but at least one other confirmation would be good. Dan used to confirm based on his ability to just know what works. Until there is someone else as "lead" then I'll be happy with any one confirming.
I just tested the patch and it works for me.
Thanks Jim, assigning to me so that I remember to take care of this tonight. As this is targetted for 7.0, I'll only commit to trunk, unless Chris feels it's worth moving to 6.5.2 as well given the second report (bug 4969), which I'll mark off as a dupe
*** Bug 4969 has been marked as a duplicate of this bug. ***
re-targetting for tonight's build.
fixed in 6.5.2 at change 11947 and trunk at change 11948. please reopen if there are any problems.
This now works properly for me. Thank you.
Fixed in 6.5.2, which is now released and available for download at http://www.slimdevices.com/su_downloads.html If you're still experiencing this bug, please re-open it!