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

Tim McClarren tim at 7thheaven.org
Mon Sep 12 19:07:25 UTC 2005


So, in continuing to look at this, one other thing that is probably slow 
in my setup is that I use the Perl "changechannel" script to change 
channels on my Sony DSS receiver, which is connected over the serial line.

History tells me that forking and then launching Perl just to process a 
30 line script to send commands out the serial line is probably not that 
efficient.

I wrote a small module that is a serial line driver, and on top, a C++ 
driver class that can drive the Sony DSS.  I tried to make it somewhat 
modular so one could replace the Sony specific driver with code for 
other receivers (with different byte code commands).  So, this is C/C++ 
code that can be compiled into Myth.  There's no UI component yet, since 
I haven't fully learned how to do that.  Also, I think this should be 
non-blocking (it's not right now, but what I have is working).  I can't 
see any reason to actually wait 50 or 100ms for the DSS box to supply an 
"OK" response to a command to change the channel.  So, there ought to be 
a callback that the driver can call to notify the caller when a command 
failed.  This would allow the mythbackend to attempt to resync state 
with the receiver, and, if it fails for a period of time, to notify the 
front end.  The front end could then put up an OSD message to the effect 
"The receiver connected to serial port X on your Myth server appears to 
be malfunctioning", etc.  I'd really like it if the front end was more 
"user friendly" in this way, for all sorts of failure conditions.  Comments?

I would like to polish this up and bit, but I will submit the "pause" 
patches I mentioned below independently (hopefully later today).

Tim McClarren wrote:
> 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
> 
> 
> _______________________________________________
> 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