[mythtv] Suggestion for improving SLOW channel changing
lists at wildgooses.com
Sat Sep 10 11:19:59 UTC 2005
>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
>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
Come on, lets see some action now!
More information about the mythtv-dev