[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