Bugzilla – Bug 1934
Idle Stall: UI Stalls When Browsing After SS Idle Time
Last modified: 2008-09-15 14:36:01 UTC
Am experiencing symptoms I call 'Idle Stall'. System: 2 SB2s, almost always sync'd Wireless connection to D-Link 624, 802.11g, 70-95% signal Athlon 2400, 1GB RAM, 400GB SATA HDD WinXP SP2 35,000 track library 98%MP3, 2%FLAC stall usually occurs on first use after some idle time display is normal and responsive up to certain points most noticable stall on browsing to "new music" as soon as right arrow is hit, display remains stuck sometimes for minutes at a time once it responds the first time, it is OK afterwards similar issues on browse by artist, not as severe 'waking' the system via web interface also brings it out of the stall occurs even when only ~50% of physical RAM is assigned Theory: even though sufficient physical resources are available, the application is getting into something of an idle state. may be memory swapping of some sort may be OS memory issue (tunable via OS settings?) (mozilla used to do a similar thing on Win) may be db connections timing out Workaround: i've set up an AT (like chron) job at 30min frequency calls wget to fetch this URL: http://[username]:[password]@slimserver.mydomain.org:9000/browsedb.html?hierarchy=age,track&level=0&player=00%3A04%3A20%3A05%3Aac%3A69 this remediates the problem for now.
Dan: I've heard lots of complaints on this. Any idea?
We could put an option in to explictly do the 'commit suppression' - for those that want their disks to spin down. For everyone else, the DB will periodically commit, keeping the process more active.
I propose that we start an internal timer in slimserver that whacks the database every 30 seconds (like the example below.) this would be an option.
Fix commited as subversion change 4366
*** Bug 1470 has been marked as a duplicate of this bug. ***