Bugzilla – Bug 1443
Jumpy display (only on browse albums)
Last modified: 2008-01-15 17:05:03 UTC
Nice feature having the artist next to the album in the browse album section. However it seems to have introduced a bug. The display seems to jump as it scrolls if there is a title that doesnt fit on one line. This only occurs in the 'browse album' view and not for example the 'browse artist' or 'now playing'. The CPU usage (when playing an mp3) is 5% and scroll 'browse artists', but when 'browse album' the cpu useage is 20%. I ahve my scroll rate and scroll pixels set to a high rate (0.04 and 2 respectively). The jumpiness does dissapear if I rest to default values - but I cant live with the default values as it just looks awful! This definetly seems like a bug in the browse album code rather than due to high quality scrolling setting on my underpowered system (honestly!) Is the server accessing the artist information repeatedly when scrolling the abum-artist combination? SB1G via wireless bridge (11g) Mandrake Linux 10 Slimserver 6.1nightly 26/4 Celeron 633 (was previously using 12/4/5 6.1 nightly wihtout this problem).
Could be that the suggested fix for bug 1442 might resolve this bug too by reducing the overhead of retrieving artist info.
triode: does your new patch address this?
This is due to the cost of running the lines function when the artist is included - I don't think it is cached in the cache held by the browse/database code and so causes a database access every second. Scrolling is interrupted simply due to the time taken to do the database access. [Michael H added the preference to disable the artist display based on my observation of this.] The solution would be to ensure the artist name is cached as well as the album name so that repeated call of lines don't hit the database. As this is in the browse/database code, could Dan/Vidur look at it?
couldn't Info::setCurrentTitle and Info::getCurrentTitle be used here? it would mean needing a reference to some custom URL to indicate that its an album instead of a track. It should get all the same benefits that the track title caching grants on the now playing display.
Is this still an issue?
I'd be willing to bet it is, depending on the speed of the server and possibly the size of the database. Browsing albums in the web interface when 'Show Artist with Albums' is enabled can be extremely CPU intensive and is in need of some sort of optimization. When enabled, SlimServer typically executes _hundreds_ of queries generating a single web page in browse Albums. See: http://forums.slimdevices.com/showthread.php?t=32527 How about a change of title to something like 'Optimize Show Artist with Albums'? And maybe set a target?
QA to reproduce.
Hardware requirements for SqueezeCenter / SlimServer has changed, does that effect the validity of this bug? How do I enable "Show Artist with Albums"?
settings->my music, I think, for Default skin.
Thanks KDF but I could use another nudge, is that a server setting, or player setting? I'm not seeing my music within SS/SC settings.
It's a server setting, as I believe it only affects what is displayed in the web interface. In 6.5 it's at Server Settings > Formatting. In 7.0 it's at Server Settings > Interface.
Thank you KDF and Mr. Zolx. I've tried reproducing this with my 433 Mhz Celeron with Ubuntu 7.10 and I'm not seeing any issues with the web interface. I have several tracks with very long album and artist names and they're displayed properly. Is this an issue with the web interface, or the player screen? Isn't scroll rate specifically for the player display? Has anyone else reproduced this?
If anyone is still seeing this please feel free to reopen.