[mythtv] Suggestion for improving SLOW channel changing inLiveTV.....

Tim McClarren tim at 7thheaven.org
Sun Sep 11 02:35:59 UTC 2005

Ah, my bad... I can't read my own logs :)

It was taking me just under 2s, not 4s.

The time-savings with this patch averages right around 400ms on my setup.

I am getting channel changes in the 1200-1500ms range now, vs. 
1600-1900ms range before.

I still almost always get a "taking too long to be allowed to read.." 
log message on the front end.

I'm guessing that's related to my encoding settings.

Tim McClarren wrote:
> I just started looking at this.
> I instrumented tv_play.cpp and some of RingBuffer.cpp with logging, 
> because I was curious why it was taking me just under 4s to change 
> channels.
> A bunch of this time is spent getting stuff paused and unpaused.
> One thing I discovered is that RingBuffer.cpp has a loop in it that, I 
> think, can cause it to be sitting there doing very little for a long 
> period of time, while the other thread is waiting on it to finish up and 
> go into "pause".
> If you take a look at RingBuffer::ReadAheadThread(void), you'll see that 
> it checks the flag to see if it should be paused, but if it's not 
> supposed to be paused, it enters the loop right below, where it promptly 
> sleeps for 50ms, and could conceivably sleep for 500ms!  Using 
> "usleep()" seems bad to me... but I don't know anything about this code, 
> really.
> All the while, the other thread is waiting for this thread to finish and 
> then "pause".
> I have a patch for this problem, which introduces a private member 
> function that is called both before and from within the loop to check if 
> it should short-circuit.
> I also removed the usleep entirely, and instead have this reader thread 
> wait on an "interrupt" mutex which will wake up should the player thread 
> ask it to "pause".
> With these changes my channel changing dropped to just under 1.5s... I'm 
> guessing someone who starts at 2s would get some improvement, although 
> maybe not quite as much as me.
> It's not as much code as it sounds like, and only changes RingBuffer.h/cpp.
> If someone wants to look at this, I'm happy to send the diff.  I know 
> exceptionally little about Myth (although I've been using it for a year 
> or more, I just started futzing around in the code because the UI has 
> become increasingly arcane and confusing... it needs a serious overhaul 
> to make it all very simple for your average non-video professional).
> Ed W wrote:
>>> Main control logic's in tv_rec.cpp and tv_play.cpp.  The various 
>>> threads they're stopping/starting live elsewhere, but should be easy 
>>> enough to find with grep.
>>> And yes, this is how you speed up channel changing, not by coming up 
>>> with crazily overcomplicated schemes.
>> It's a while back, but I was seeing about 800ms spent waiting for 
>> things to pause on a box with mythbackend local.  It was pretty hard 
>> to figure out where the delays were though to be honest
>> I *think* that some of the problem may have been due to the size of 
>> the network packets used in frontend to backend comms?  So you have to 
>> wait longer than you think before the backend has recorded enough data 
>> before you actually start sending the first packets to the frontend?  
>> It's possible that an option to tune this size depending on whether 
>> the backend is local could be useful?
>> Also I think the min number of buffered frames could be lower in some 
>> circumstances, eg hardware mpeg cards
>> I still think that there is no need to wait for several of the pauses 
>> to actually hit their respective threads, eg audio.  Can't see what 
>> harm comes if we ask for a pause, then retune, then start sending more 
>> audio data before the audio thread even noticed what we were trying to 
>> do?  It's just a queue and apart from flushing the queue there is 
>> nothing else we can really gain by waiting for it to notice what we 
>> are up to...?
>> ...OK folks, so there are some easy starting points.  As Isaac said if 
>> you just go into the channel change function in *tv_play.cpp* then its 
>> possible to put in a few timing statements to see how long each stage 
>> takes.  Then dig into the slow statements and add some timing 
>> statements in those and so on.  This shows up how long the various 
>> "pause" functions take.  I have actually posted a patch to do this a 
>> long while back, but the point is that its pretty easy to do and your 
>> info would be very useful
>> Come on, lets see some action now!
>> Good luck
>> Ed W
>> -
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev at mythtv.org
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

More information about the mythtv-dev mailing list