Bug 1934 - Idle Stall: UI Stalls When Browsing After SS Idle Time
: Idle Stall: UI Stalls When Browsing After SS Idle Time
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Player UI
: 6.1.1
: PC Windows XP
: P2 normal (vote)
: ---
Assigned To: Dan Sully
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-05 08:29 UTC by Ron Thigpen
Modified: 2008-09-15 14:36 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ron Thigpen 2005-08-05 08:29:17 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.
Comment 1 Blackketter Dean 2005-08-05 10:42:03 UTC
Dan: I've heard lots of complaints on this.  Any idea?
Comment 2 Dan Sully 2005-08-05 10:55:12 UTC
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.
Comment 3 Blackketter Dean 2005-09-07 15:31:16 UTC
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.
Comment 4 Dan Sully 2005-09-19 15:40:26 UTC
Fix commited as subversion change 4366
Comment 5 Dan Sully 2005-09-20 13:44:29 UTC
*** Bug 1470 has been marked as a duplicate of this bug. ***