Bug 1153 - Don't run intensive tasks while music is playing.
: Don't run intensive tasks while music is playing.
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Database
: 6.0.0
: All All
: P2 major (vote)
: ---
Assigned To: Dan Sully
:
Depends on:
Blocks: 1459
  Show dependency treegraph
 
Reported: 2005-03-21 17:33 UTC by Dan Sully
Modified: 2009-09-08 09:13 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Sully 2005-03-21 17:33:10 UTC
For compute intensive tasks, such as the db cleanup sweep - since we control the
horizontal and the vertical, don't run those when music is playing.
 
Enter the function occasionally, and keep track of - ok, I've not played any
music in the past 15 minutes, it's ok to run now.

And back off when music starts up again.

The same can apply to the Rescan plugin, as well as iTunes auto-scanning.
Comment 1 Blackketter Dean 2005-04-28 14:49:34 UTC
What's the actual problem here?  Is it that the music breaks up?  Or the UI is unresponsive?  

It's not clear from the description what the bug is, rather specifies an optimization before we know 
what we're optimizing for.

Comment 2 Dan Sully 2005-04-28 15:41:34 UTC
Dropouts - that's always the problem. Bad for SB1/SliMP3 users. Not so bad (may not exist) for SB2 Users.

Bad in general on slower machines.

IMO, spiking the CPU when we're playing music can cause issues.
Comment 3 Blackketter Dean 2005-04-28 17:38:05 UTC
Ok, let's understand the specific issues and fix them.  The "intensive" tasks shouldn't be blocking for 
seconds.  Background scanning shouldn't be an intensive task, nor should iTunes importing...
Comment 4 James Craig 2005-04-29 01:55:09 UTC
The iTunes problem is the playlists. 

Processing them uses 100% CPU on my 2Ghz P4. 
Results in TOTAL loss of connection to clients.

I guess parsing the playlists is so simple (it's just a lookup in a hash I
think?) that it can really churn the CPU.
Comment 5 Blackketter Dean 2005-04-29 08:18:47 UTC
James:  That sounds like a separate bug.  Total disconnections shouldn't happen at all.  Can you file 
another bug with details and attach a compressed copy of your iTunes Music Library.xml file?  Thanks.
Comment 6 James Craig 2005-04-29 08:29:30 UTC
Maybe I used the wrong wording;
When the iTunes playlists start scanning (note not the files/library) the
display stops, then the music stops and I get the 'lost connection with
SlimServer' message. 
When the rescan completes the clients reconnect immediately, not going through
the setup screens.
Comment 7 Blackketter Dean 2005-04-29 09:13:01 UTC
That definitely shouldn't happen (and the disconnection problem would happen even if you weren't 
playing music.)  Please do file a separate bug with details and your XML file.

thanks.
Comment 8 Andy Grundman 2005-05-17 09:56:13 UTC
On my SB2, when SlimServer is running a 100% task such as a rescan, there is no
problem with the music, but the scrolling and IR response time is severely
impacted.  There is a lag of several seconds when using the remote, and
scrolling text becomes jerky.  Maybe these processes could be throttled to run
slower if any player is currently active.
Comment 9 Blackketter Dean 2005-06-07 14:13:38 UTC
Would like some profiling to find out which section of the scan code is blocking for too long.
Comment 10 Dan Sully 2006-04-30 17:31:58 UTC
This is part of the split-scanner changes.
Comment 11 Dan Sully 2006-05-24 17:12:04 UTC
Marking this as closed - trunk now includes the forked scanner.

If there are other bugs, please create them with more specific wording.

Thanks