Bugzilla – Bug 2348
On Mac OS X, perl process hogs cpu bandwidth when itunes music is played
Last modified: 2011-03-16 04:18:52 UTC
The following problem occurs on the Mac that is running Slimserver 6.2b2 (OS X 10.39, Cube with 1.5Gb ram): The Slimserver behaves normally when the Mac is first started, and no other applications are running. Reproducible problem: When itunes (version 5) is launched and a random song is played in itunes, within a couple minutes the cpu usage spikes to 100% (the OS X Activity monitor shows that the Slimserver perl process is using 60 -70%), which results in intermittent audio streaming to the squeezebox. The Squeezebox will play about 1 second of audio out of 15 during this condition. Quitting itunes does not clear the perl cpu usage problem. (Note that if itunes is launched, but no song is played in itunes, this cpu spike condition does not occur, and the Slimserver behaves normally). Note also that the itunes songs that are played to trigger this problem are all MP3 format, 320Kbs, ripped by itunes. While the perl process is hogging the cpu, shutting down the Slimserver from the System Preference pane kills the perl process, and the cpu utilization goes back to normal. However, restarting the Slimserver causes the perl process to again spike to 80%, and the Slimserver still won't stream properly when this is going on. While the cpu is being thrashed (Slimserver is running and perl process is at 80%), trying to browse to the Slimserver takes several minutes/attempts before the home page is served, and when it finally does appear, the right side of the Slimserver home page window often displays: 404 Not Found: There is no ":" skin, try http://The-Cube-Music-Server.local:9000/ instead. Sometimes this error is not displayed, and the Slimserver home page is displayed normally (though very slowly). After several minutes, the perl process goes back to 3-4%, and the Slimserver behaves normally again. The total time it takes for the perl process to go back to normal cpu usage is over 5 minutes. I don't understand what causes it to go back to normal...I haven't been able to do anything that seems to trigger the solution. This problem started with version 6 of slimserver, and does not occur with version 5.4.1. The Squeezebox player is running firmware v 40
This is going to be addressed in 6.5. In the mean time, you can go to the Server Settings, under the iTunes link and set the rescan interval to a much higher interval to reduce the frequency of the rescans.
6.5b1 fixed this problem for me. No more dropouts on playback, and slimserver is using 0.5% of the CPU! Thanks to the excellent slim developers, Mark
Well I have to take that back. When initially starting the slimserver, the CPU usage is low. But after some period of time (hours I think), regardless of whether any music is playing, the CPU usage builds back up and the squeezebox and server response gets slow again. What should I do to track down the problem further?
Mark: did you try upping the itunes rescan interval? it won't fix the root problem, but it should make it far less frequent.
I just upped the itunes rescan interval to 3600, and it bogged down the machine within 60 seconds of launching itunes. Does this setting change take effect immediately? If so, then the Perl process is jumping up to 65% for reasons unrelated to rescanning... Note: in my environment, the cpu usage builds up within a minute or two of launching itunes. If itunes is left closed, the slimserver behaves normally, with the perl process hovering around 3-5% -Adam
The problem is that the slimserver process uses too much cpu time when scanning relatively large itunes libraries. we don't have an immediate fix for this, will address it in version 6.5. In the mean time, setting that interval to something like 3600 seconds should make it only rescan once an hour or so. setting it to zero will make it never rescan automatically, then you can use the rescan button in the main server settings are to trigger a rescan manually.
I am running 6.5b1 and am getting this problem. I just changed the "iTunes Reload Interval" (is this the setting you guys are talking about?) to zero. The CPU time dropped after a while, presumably when it finished the current reload cycle. You are correct that my iTunes library is large--about 350GB. Until this problem is fixed it would be nice if there was a way for it to reload the library once a day at say 3:00 am. Is that possible? Thanks again. --Mark
Wow, that is a big library. Yes, you can set up an automatic rescan (under plugins) to be scheduled every day...
I've been seeing this same problem with 6.2 for weeks and 6.2.1 since I loaded it today. After an hour or so (don't know exactly), the perl process jumped up to take all available cpu time. I have auto scanning turned off, so I don't think that's it, mainly because the web interface doesn't indicate that it's scanning like it does when I manually scan. It will suck up all my available cpu for 15 minutes or so, then drop back down for a while. When perl is being a cpu hog, streaming to my squeezebox1 is very intermittent, causeing seconds long dropouts. I'm waiting to see how long it goes until it kicks on again. Is there some way I could help you figure out what's going on here? I'll send log files and monitor processes or whatever if it would help.
isn't this the same as bug 1469 ? Although it seems to be a bigger problem for Mac users this time around.
No, what I am reporting has nothing to do with bug 1649, at least nothing to do with playlist scans. What I am seeing is terrible slimserver performance with a very large iTunes library (350GB). I tried making it rescan the library only once per day, but even then the server was still slow all day. (I don't know how to interpret the logs to tell if it never finished scanning, or what exactly it was doing). I could never listen to music without long pauses, and remote control response took seconds or minutes. I tried an experiment, which seems to have worked: I configured the server not to use iTunes. The scanning of the music directory seemed to go quickly, and remote control and music playing is fine. This is much better.
I hope I'm tagging onto the right defect report. I'm kind of seeing the same thing but not to the letter. My subject line would be: On Mac OS X, perl process hogs cpu bandwidth when itunes music is running The actual report is exactly the original except: - iTunes just has to be open for me, not actually playing. - most of my music library is 160K AAC/MP4 - Perl does eventually calm down if I close iTunes - SlimServer Version: 6.2.1 - 5119 - Mac OS X Server 10.3.9 (7W98) - EN - utf8 Neil.
Subject: RE: On Mac OS X, perl process hogs cpu bandwidth when itunes music is played Yes, I posted this bug originally, and your description is accurate for my condition as well. Once iTunes launches, Perl starts hogging cpu within a minute or two, regardless of whether iTunes is playing music or not. Then perl calms down within 5 minutes of closing iTunes. During the time when perl is hogging the cpu,, Slim server is unable to serve web pages. -Adam -----Original Message----- From: Slim Devices Bugzilla [mailto:bugs@bugs.slimdevices.com] Sent: Wednesday, December 14, 2005 4:53 AM To: Adam Pemberton Subject: [Bug 2348] On Mac OS X, perl process hogs cpu bandwidth when itunes music is played https://bugs-archive.lyrion.org/show_bug.cgi?id=2348 neil@drempel.org.uk changed: What |Removed |Added ------------------------------------------------------------------------ ---- CC| |neil@drempel.org.uk ------- Comment #12 from neil@drempel.org.uk 2005-12-14 01:52 ------- I hope I'm tagging onto the right defect report. I'm kind of seeing the same thing but not to the letter. My subject line would be: On Mac OS X, perl process hogs cpu bandwidth when itunes music is running The actual report is exactly the original except: - iTunes just has to be open for me, not actually playing. - most of my music library is 160K AAC/MP4 - Perl does eventually calm down if I close iTunes - SlimServer Version: 6.2.1 - 5119 - Mac OS X Server 10.3.9 (7W98) - EN - utf8 Neil. ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter.
(In reply to comment #0) > The following problem occurs on the Mac that is running Slimserver 6.2b2 (OS X > 10.39, Cube with > 1.5Gb ram): > > The Slimserver behaves normally when the Mac is first started, and no other > applications are running. > > Reproducible problem: > When itunes (version 5) is launched and a random song is played in itunes, > within a couple minutes the > cpu usage spikes to 100% (the OS X Activity monitor shows that the Slimserver > perl process is using 60 > -70%), which results in intermittent audio streaming to the squeezebox. The > Squeezebox will play > about 1 second of audio out of 15 during this condition. Quitting itunes does > not clear the perl cpu > usage problem. (Note that if itunes is launched, but no song is played in > itunes, this cpu spike > condition does not occur, and the Slimserver behaves normally). Note also that > the itunes songs that > are played to trigger this problem are all MP3 format, 320Kbs, ripped by > itunes. > > While the perl process is hogging the cpu, shutting down the Slimserver from > the System Preference > pane kills the perl process, and the cpu utilization goes back to normal. > However, restarting the > Slimserver causes the perl process to again spike to 80%, and the Slimserver > still won't stream properly > when this is going on. > > While the cpu is being thrashed (Slimserver is running and perl process is at > 80%), trying to browse to > the Slimserver takes several minutes/attempts before the home page is served, > and when it finally does > appear, the right side of the Slimserver home page window often displays: > > 404 Not Found: > There is no ":" skin, try http://The-Cube-Music-Server.local:9000/ instead. > > Sometimes this error is not displayed, and the Slimserver home page is > displayed normally (though very > slowly). > > After several minutes, the perl process goes back to 3-4%, and the Slimserver > behaves normally again. > The total time it takes for the perl process to go back to normal cpu usage is > over 5 minutes. I don't > understand what causes it to go back to normal...I haven't been able to do > anything that seems to > trigger the solution. > > This problem started with version 6 of slimserver, and does not occur with > version 5.4.1. The > Squeezebox player is running firmware v 40 >
This appears not to be limited only to Mac OS. I'm seeing the same issue (apparently) thought it's hard to distinguish between bug 1469 and this one. The only way I seem to be able to avoid maxing out CPU with iTunes running along with SlimServer is to change the "iTunes Reload Interval" to "0". I'd really like to see this fixed as well as I depend heavily on iTunes and don't want to have to manually scan my libraries. Just thought I'd drop the fact that it's not limited to Mac OS X.
The latest 6.2.2 nightly release and 6.5 nightly release will be substantially more efficient when updating iTunes information. Please install that version and report your experiences here.
(In reply to comment #16) > The latest 6.2.2 nightly release and 6.5 nightly release will be substantially > more efficient when updating iTunes information. Please install that version > and report your experiences here. > What are the recommended settings for the update interval then with this rev?
The update interval sets the minimum amount of time between rescans. Set it to 5 minutes (300 seconds) and see how the performance works for you. Setting it to zero means that it won't rescan automatically, so you wouldn't actually see the effect of this change in that case.
This is definitely an improvement, but for my big library it is still not usable. The remote control button response is about 10 seconds, and playing halts for 15-30 seconds. I turned on d_itunes and noticed that it has been indexing the iTunes library for the last 15 minutes. It logs each song, about once per second. With about 40,000 songs this will take quite a while. Merry Christmas and happy optimizing, --Mark
Please try the latest nightly release (either 6.2.2 or 6.5) and see if the issue is better. SlimServer will still use a significant amount of CPU when updating a changed iTunes library, but audio playback and web serving should be far less impacted. If you are still having problems, please reopen the bug with details on your setup (library size and location, main server settings page, itunes settings page).