Bugzilla – Bug 16089
If I have Touch or Radio as player, the playlist handling in server gets very sluggish
Last modified: 2011-05-06 15:07:11 UTC
Created attachment 6791 [details] server.log during stutter If I have Touch or Radio as player, the playlist handling in server gets very sluggish and shuffle is even more sluggish. Se tread here:http://forums.slimdevices.com/showthread.php?t=77488 In short handling playlists <500 tracks tried with 150 to 403 track lists. Works perfect with my SB3 or boom. The playlist loads swiftly and starts to play shuffling 403 tracks is almost instant ok. Toggling through the different shuffle alternatives goes fast no problems. If I however choose my Touch (or radio) as player then: 1. My 403 track playlist stutters during the first track. 2. If shuffle once it takes 10s before anything happens then it stutters and missbehaves for circa 2 minutes,then it's shuffled. 3. If I press shuffle 3 times quickly any bets are of 5 minutes of silence or I manually kill the service During this cpu is pegged at 100% doing.. something
Definitely seeing the same thing with Boom, Radio and desktop SP. It's also very slow from the SP interface. See the forum discussion for more.
I got it in such a bad shape that even if I restart the server it comes back with 100% cpu Damn I'm might be in a catch here. Tried to remove all "clientplaylists" did not help ? Server is now completely hung up, as soon as i start sbs it goes to 100% cpu Just because i pressed shuffle 5 times in a playlist, no more music this weekend ? Tried with Touch and Controller off that worked but as son Touch came online again CPU was 100% Fascinating 4 restarts later , I found 0.02% cpu to erase Touch playlist via the controller, I saw that it had shuffled to "song" then ? Ok once you pressed shuffle sbs will continue untill it's done, whatever you do it can not be interupted ? Luckily i did not press shuffle 100 times out of frustration sbs will probably cue up these requests and do them eventually.
After more organized testing (not so much vine) I have to correct my findings. The only good situations (regarding this bug): controlling an ip3k player with it's own UI or the web-UI The most troubled cases: The Touch is player and controlled by itself or controller or web-UI Less trouble but still stuttering, but eventually recovers: Controlling ip3k player with Touch or Controller Note that during the worst of it ip3k player menu freeze and controller is showing blue wifi, Touch "can not connect". Server, it's only cpu that is 100% it only uses 10% ram Some server stat if forgot: Version: 7.6.0 - r30653 @ Fri Apr 16 02:04:58 MDT 2010 Hostname: hal.home.lan Server IP Address: 192.168.1.5 Server HTTP Port Number: 9000 Operating system: Red Hat - EN - utf8 Platform Architecture: i686-linux Perl Version: 5.8.8 - i686-linux-thread-multi Database Version: DBD::SQLite 1.29 (sqlite 3.6.22) Total Players Recognized: 4 Hardware is an 1.2gHz via epis C7 1gB of RAM
Ok did some more testing on ip3k only scenario Boom as player, web-UI or boom as UI. My server can effortlessly drive playlist of 2000-4000 tracks 2000 feels the same as 100 4000 takes 5-6 sec to cue up then handles like normal. So this is very asymmetrical ? If I have a Squeezeplay player and controller involved 170 songs bring the whole system down. So I think this bug is important even if it have only 2 votes
Note that this is a 7.6 bug. That is very much at alpha-release level at this stage. Pity really, as 7.6 has some specific performance enhancements in this area (taken from 7.5e) but I guess that there is more to work out. You could try running with --perfmon to see if you can get some statistic of exactly which requests are especially slow, but I expect that more-detailed profiling will be necessary.
Created attachment 6795 [details] perfmon log Here's a performance monitor log that I posted in the forum thread referenced above. This is while controlling a Touch and browsing in the web ui. The 11+ second entry at the beginning is the first time I enter New Music through the web browser. I then played all the tracks in one genre, about 360 total. The 7+ and 9+ second times are the result of pressing the shuffle button in the web ui. statusQuery??
Happy to to do do some --perfmon, if somebody kindly tell me how to do that on my OS CC4.2 (rhel based rpm install). regards Mikael
Nobody want's wants perfmon logs from me ?
QA to have a look, probably assign to Alan.
This bug has also regressed , if have a 250 song pl on my boom open the web UI and starts to delete songs fairly often try first 5 then some more, you get 5 minutes of 100% cpu
(In reply to comment #10) > This bug has also regressed , if have a 250 song pl on my boom open the web UI > and starts to delete songs fairly often try first 5 then some more, you get 5 > minutes of 100% cpu I was wrong it looks at 100% cpu for ever have to kill the server Cpu(s):100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 970288k total, 582124k used, 388164k free, 14052k buffers Swap: 1966072k total, 0k used, 1966072k free, 306240k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2237 squeezeb 25 0 214m 206m 4156 R 99.4 21.8 18:32.69 squeezeboxserve 2383 root 18 0 10196 6420 1452 S 0.3 0.7 0:00.29 syswatch 3919 root 15 0 2036 1004 788 R 0.3 0.1 0:05.63 top 1 root 15 0 1716 592 512 S 0.0 0.1 0:00.95 init 2 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
Andy/Alan - is this the issue where an analyze would improve things? I'm seeing badly reduced performance too. I did an analyze a few weeks back, and without new music added a 50 track playlist would time out again on Controller.
Mikael - if you feel confident connecting to thrpe db, you could try the following: - shut down SBS - use the sqlite client to open squeezebox.db - run the analyze command (http://www.sqlite.org/lang_analyze.html) This will rebuild indexes etc., which might improve the situation (though only temporarily)
Mikael, yes, it would be very helpful if you could try this. So far, I have been unable to reproduce this, or bug 15361. SbS is supposed to run ANALYSE automatically when necessary, but maybe there are some cases where it is missed.
(In reply to comment #14) > Mikael, yes, it would be very helpful if you could try this. > > So far, I have been unable to reproduce this, or bug 15361. > > SbS is supposed to run ANALYSE automatically when necessary, but maybe there > are some cases where it is missed. Found some precompiled binaries Now i have "sqlit3" and "sqlite3_analyser" in /bin on my server ? They start up if I try to use them . Now how do I do this ANALYZE thing , I will try.. ?
Is this the correct way to do it ? [root@hal /]# sqlite3 /var/lib/squeezeboxserver/cache/squeezebox.db SQLite version 3.7.4 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> analyze; sqlite>
It must have been the right command :-) I assume it was the right command :-) I cued up all my 1472 hirez 24/96 tracks I even dared to shuffle them. Starting a new album now gives 10% cpu spike instead off 100% !! I did it rigth after a clear and rescan everything
Weird I have not been able to shuffle such large pl for 5 moths even after several clear and rescan everything ? So my dB's are borked immediately after a scan ? I also analyzed my artwork cache and persistent dB :-)
== Auto-comment from SVN commit #31775 to the slim repo by ayoung == == http://svn.slimdevices.com/slim?view=revision&revision=31775 == bug 16089: If I have Touch or Radio as player, the playlist handling in server gets very sluggish Make sure ANALYZE (and OPTIMIZE, for MySQL) will actually get called.
== Auto-comment from SVN commit #31776 to the slim repo by ayoung == == http://svn.slimdevices.com/slim?view=revision&revision=31776 == bug 16089: If I have Touch or Radio as player, the playlist handling in server gets very sluggish Delete contents of scanned_files table for wipeDB()
Now that an ANALYSE is being done properly, I think this issue is probably resolved in respect to specific 7.6 changes that were causing problems. It was probably masked for many developers, who might have run ANALYZE by hand once, because the underlying DB is copied as part of a wipe-rescan. This meant that the statistics from the old DB would be carried over to the newly scanned one and often they would be good enough to guide the query optimizer properly, even if the data was not up-to-date.
== Auto-comment from SVN commit #31777 to the slim repo by ayoung == == http://svn.slimdevices.com/slim?view=revision&revision=31777 == bug 16089: Make sure ANALYZE (and OPTIMIZE, for MySQL) will actually get called.
== Auto-comment from SVN commit #31778 to the slim repo by ayoung == == http://svn.slimdevices.com/slim?view=revision&revision=31778 == bug 16089: typo with previous checkin
Yep tested with a 2968 track PL took 15-20 sec to load ,but played and shuffled just fine, if you shuffle around a while the small artwork in controller might get lost for a while, but it is working :-) I used my controller controlling the Touch, shifted shuffle mode with the Ir while watching the pl regruop on the controller np playlist. Can still explain performance issues on TinySC too , for example the 100 track pl limit ?
Used the TOuch as player for >500 track PL amd it shuffled and loaded without problems 7.6.0.r32390