Bugzilla – Bug 1436
Page breaks in Browse Artwork
Last modified: 2008-12-15 13:06:32 UTC
Browse Artwork appears to show thumbnails in pages of 50. However, thumbnails are displayed according to the size of the browser window and the size of the thumbnail. As a result, thumbnails get pushed onto the next page for no logical reason: eg. if you have 51 albums, and thumbnails are displayed 7 across, you finish up with 7 rows of 7, plus 1 on the bottom line, with the last thumbnail pushed onto the next page. Solution: ditch pages in Browse thumbnails and let the browser scrolling do the work.
it should be using the same "items per page" setting as all the other browse modes. I believe the default is now 50. Do you have your interface setting to include, or delete placeholders?
Browse by Artist reports 80+ artists but does not split pages - so doesn't appear to be the same as other modes. In this case page break on number of items would be inappropriate anyway - it should page break on rows (or not at all)! Placeholders are included. FC3 /I believe this is the same for 6.01-branch and 6.10-branch of yesterday.
well, the items per page is more to save rendering effort and not kill audio. calculating x by y for a given thumbnail size would probably be just as taxing. I have my setup with placeholders removed, and that still displays 600 covers if it wasn't paged. setting items per page to something like 1000 guarantees that the squeezebox reports loss of contact with the server. however, the paging should be more consistent that what you are reporting, especially if you still have the placeholders in since that should bascially be the same as browse by album
it seems that current playlist, browse by artwork, browse new music are the only ones that adhere to the itemsPerPage setting. The rest seem to adjust from it slightly. I cannot explain why, but THAT would appear to be the bug to me. I am unaware of any design to ignore that.
I don't see how this is a bug, or even an enhancement request. If you divide pages into groups of 50 and you have 51, then logically you can expect to have 1 item on the last page. Moving to _not_ divide Browse Artwork into pages certainly can't be an option, since someone with hundreds or thousands of albums wouldn't want those served on a single page. In fact, this would be the worst browse mode to not break into pages, since the server is also dishing out all those images. If a user really wants this behavior, then he just sets the items per page to a very large number. Note that with the use of the alphapagebar in Browse Artwork (v6.2+) the division is now on a letter boundary, so the strict items-per-page isn't adhered to. The only enhancement I could think of to the (alphapagebar) paging would be to use an approach where if you're computing the items to place on a page, look ahead to see how many items would be on the next page #N. If it's less than some number (maybe itemsperpage/10 ?) then add the 'leftover' items to this page.
good point. marking fixed as per alphapagebar design
Hey, wait a minute! The point is that browse by artwork puts 'n' items per line, rather than the single item per line of the other modes. Since the number of items per line depends on: the size of the artwork (user configurable), and the size of the browser window, if you use a fixed number of items per page then the page boundary often occurs at an inappropriate point. To use the example of '51' items, if your browser is displaying 7 items per row, browse artwork will display 7 rows of 7 items, with a trailing row of just 1 item; you will then have to go to page 2 to see another single row of 1 item. Under that circumstance (7 items per row) It would be far neater if browse artwork was intelligent enough to end the page of a full line of items ie in our example 7 x 7 = 49 on page 1, and 2 x 1 on page 2. I've been setting the number of items per page to 60, since it's divisible by more small intergers than 50, and therefore generally gives neater results. So browse artwork would be better page breaking on multiples of the number of items per row, rather than an arbitary fixed number or even a letter of the alphabet. Hope I've explained that better!
But with the use of the alphapagebar in v6.2 the division of these pages is now on letter boundaries, so even if you could strictly define number of items per row, you're going to have an unpredictable number of items on the page and therefore in the last row. I was doing _exactly_ what you do with respect to items per page. My browser window and my designated thumbnail size always gives me either 3 or 4 across, so I defined my items per page to be divisible by either. It's a moot point now. One tip: I use a customized fishbone skin. If you most often use browse artwork, as I do, in the index.html file set the size of the left hand frame to a fixed pixel size (with something like cols="555,*"). Then, whenever you open your browser, the browse pane on the left will alway have a set number of items per row, no matter what the window size is.
The alphapagebar will obviously change things, and is definitely better than the previous 'arbitary' split - so I'll give it a go and see how it looks in practise. It's a pretty small thing anyhow - in the scheme of things! Thanks for the tip.
This bug appears to have been fixed in the latest release! If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look. Make sure to include the version number of the software you are seeing the error with.