Bugzilla – Bug 12682
Random 100% cpu utilization makes 7.4 difficult-impossible to use on Boom & other SB3 based devices.
Last modified: 2011-05-09 09:07:33 UTC
The latest 7.4 software on OSX periodically goes to 100% cpu utilization. The behavior seems to be sort of random, but happens frequently. Often when I want to scroll through a big list it happens, or even just adjusting volume. The SB UI locks up and prevents any use. There's nothing happening in server.log or scanner.log at that time, and perl is taking 100% CPU. This is a critical issue for me. Don't know if others are seeing it. Could this be because of my large music collection? 100k tracks? This was never a problem with 7.3. Could this be due to a bad MAC address on one my booms? I just noticed I have a bad one. Squeezebox Server Status Version: 7.4 - r27417 @ Sat Jul 4 04:01:43 PDT 2009 Hostname: macmini-5.local IP: 192.168.1.55 HTTP Port: 9000 OS: Mac OS X 10.5.7 (9J61) - EN - utf8 Platform: x86 Perl Version: 5.8.8 - darwin-thread-multi-2level Total Players Recognized: 6 Library Statistics Total Tracks: 105,547 Total Albums: 8,606 Total Artists: 7,946 Total Genres: 291 Total Playing Time: 7689:17:47 Player Information Information on all identified devices connected to Squeezebox Server Henrys Player Model: boom Firmware: 47 Player IP Address: 192.168.1.121 Player MAC Address: 00:04:20:ff:ff:01 Wireless Signal Strength: 73% Kitchen Player Model: boom Firmware: 47 Player IP Address: 192.168.1.120 Player MAC Address: 00:04:20:1e:xx:xx Wireless Signal Strength: 68% Sadies Player Model: boom Firmware: 47 Player IP Address: 192.168.1.122 Player MAC Address: 00:04:20:1e:xx:xx Wireless Signal Strength: 88% Sewing Player Model: boom Firmware: 47 Player IP Address: 192.168.1.127 Player MAC Address: 00:04:20:1e:xx:xx Wireless Signal Strength: 88% Squeezebox BB1 Player Model: bb Firmware: 7.4-r6320 Player IP Address: 192.168.1.125 Player MAC Address: 00:04:20:26:xx:xx Squeezebox TT1 Player Model: tt Firmware: 7.4-r6269 Player IP Address: 192.168.1.129 Player MAC Address: 00:04:20:22:01:7d Cache Folder /Users/crome/Library/Caches/Squeezebox Server Preferences Folder /Users/crome/Library/Application Support/Squeezebox Server Plugin Folders /Users/crome/Library/Caches/Squeezebox Server/InstalledPlugins/Plugins, /Users/crome/Library/Application Support/Squeezebox Server/Plugins, /Library/Application Support/Squeezebox Server/Plugins, /Library/PreferencePanes/Squeezebox Server.prefPane/Contents/server/Plugins Squeezebox Server Log File /Users/crome/Library/Logs/Squeezebox Server/server.log Scanner Log File /Users/crome/Library/Logs/Squeezebox Server/scanner.log
Caleb: does this happen when the scanner starts?
Enable scan.scanner and scan.auto.
Thought I'd jump in here, though not sure how helpful my comments will be. I thought I'd audition 7.4 last night (OS X 10.5.7, Boom, ~11k tracks). Scanning is generally quite quick on my MacBook Pro, but I figured I'd let it alone and let it scan while I slept. Woke up this morning, and the scanner had frozen. Like OP, my CPU utilization was 100%. CPU temperature, alarmingly, was 185 degrees Fahrenheit (with my machine, normal is anywhere from 120 to 160). This did not happen immediately when the scanner started, since I monitored it for a few minutes. If you need any more information from me, let me know and I'll be happy to provide it. Thanks.
This does not seem to be the scanner. Ienabld the log options you asked for,and there is no correlation between freezes and log entries. Anything else to try? Bumping severity as this makes my classic based devices perform unacceptably.
I'm experiencing very similar issues with Squeezecenter 7.3.4~27825 on a 32 bit Debian machine. Symptoms are ~100% CPU utilization and nothing out of the ordinary in the logs. Haven't found a good way of reproducing the issue, except for using the devices for some time (happens at least once a day). From looking at the strace output it seems like the main loop is running wild. The majority of the system calls logged are gettimeofday and select calls. The select calls all have a timeout of 0.0.
One thing I forgot to mention in my previous comment: I didn't notice this bug until maybe a week ago. Nothing has changed in my setup except for one thing, I've started to use the line in on my Squeezebox Boom. Don't know if this is related at all or just a coincidence.
Moving all SQLite-related bugs to 8.0.
I'm seeing the same problem since I installed 7.4 on a x86 Fedora Core 5 server with dual 2.4 GHz Athlons. The squeezeboxserver process will get pin one CPU at 100% for minutes at a time when some interaction is attempted on the Boom. My two Duet controllers continue to work fine and don't seem to pin CPU utilization. For example, pulling up the artist list from 'My Music' take 1-2 seconds on the Duets, but upwards of a minute or two on all the Booms in the house. This is not a SQLlite issue as I'm running MySQL as the backend. Please re-target this bug to the 7.4.x series as it does compromise the usage of the Booms. Version: 7.4.1 - r28948 @ Wed Oct 21 04:01:50 PDT 2009 Hostname: server.bitlathe.com IP: 192.168.0.xxx HTTP Port: 9000 OS: Red Hat - EN - utf8 Platform: i686-linux Perl Version: 5.8.8 - i386-linux-thread-multi MySQL Version: 5.0.27 Total Players Recognized: 6 Library Statistics Total Tracks: 24,924 Total Albums: 2,247 Total Artists: 1,510 Total Genres: 110 Total Playing Time: 1759:57:34 Player Information Bedroom Player Model: boom Firmware: 50 Player IP Address: 192.168.0.131 Player MAC Address: 00:04:20:1e:60:34 Wireless Signal Strength: 88% Kitchen Player Model: boom Firmware: 50 Player IP Address: 192.168.0.132 Player MAC Address: 00:04:20:1e:5f:24 Wireless Signal Strength: 90% Living Room Player Model: receiver Firmware: 65 Player IP Address: 192.168.0.125 Player MAC Address: 00:04:20:16:8b:db Office Player Model: receiver Firmware: 65 Player IP Address: 192.168.0.139 Player MAC Address: 00:04:20:16:ac:ae Playroom Player Model: boom Firmware: 50 Player IP Address: 192.168.0.100 Player MAC Address: 00:04:20:1e:0b:c3 Squeezebox Player Model: boom Firmware: 50 Player IP Address: 192.168.0.126 Player MAC Address: 00:04:20:1e:79:d4 Wireless Signal Strength: 96%
I am also encountering this same problem on my WindowsXP server. Like others it does not happen immediately, but after the server has been up for a day or more. The server will pin the cpu and cause all the players to be unresponsive. The only thing in the logs are timeouts from the server trying to connect to mysqueezebox.com and failing I assume because the operating system can't get clock cycles to respond to the DNS request.
Are very long playlists involved? If so, see: bug_10889
This issue doesn't involve playlists at all for me. The CPU utilization and unresponsiveness occur when I'm just trying to access the various options under 'my music' on the boom. I have no static playlists defined at all.
SQLite bugs need to go back to 7.6 target.
Haven't heard of this issue in a long time, please reopen if necessary.