[mythtv] CC benchmarks and procedure list ? Was: how would one speed up the channel changing in mythtv ?

Robert Johnston anaerin at gmail.com
Mon Oct 20 18:55:11 UTC 2008


On 20/10/2008 8:13 AM, Linuxguy123 wrote:
> Back to my original question: why are some mythtv installs changing
> channels faster than others ?  What mythtv settings affect channel
> changing speeds.

It's not only Myth settings, it's also hardware, software, networking, 
and probably more.

The way I understand it, changing channel in a "Live TV" session does 
the following:

Issue "Change Channel" request (Frontend) - est 1% time.

Stop recording previous stream, close file (Backend) - est 3% time.

De-allocate previously in-use tuner (Backend) - est 3% time.

Schedule a new recording starting "Now" on the chosen channel (Frontend) 
- DB Insert, est 3% time.

Reschedule recordings to take into account new recording (Backend) - DB 
Query/Update/Insert, est 10% time

Allocate an available tuner (Backend) - DB Lookup, est 3% time.

Locate suitable storage (Storage groups) (Backend) - DB + Filesys 
lookup, est 3% transaction time.

Tune to the required channel using said tuner (Using Frequency, IR 
Blaster, Multiplex, IP etc.) (Backend) - DB + Hardware, est 10% time.

Wait for signal (IR Blaster to complete, tuning to stabilize, 
FE_HAS_LOCK, Cam to begin decrypting, IP Stream to start, etc.) 
(Backend) - All Hardware, est 45% time.

Begin recording to file (Backend) - FS, est 5% time.

Open file/stream and play back (Frontend) - FS, est 10% time.

(Network overhead, filesystem delays, IO waits - est 4% time. On a 
remote Frontend, this will increase considerably, as the network 
overhead increases.)


Myth USED to (In 0.19 and below) use a seperate "Ringbuffer" for LiveTV, 
allocating a single file for the TV stream and reserving the tuner for 
as long as necessary. This did lead to fast "Live TV" sessions, but 
meant "Live TV" couldn't be kept, and as it was particularly "Dumb" 
about tuner allocation, meant it could cause massive upsets as it missed 
all your recordings while you were watching "Live TV".

As it stands now, "Live TV" is just a recording that starts "Now". 
Myth's primary use case isn't for "Live TV" - That's what the tuner in 
your TV is for (Or xawtv/tvtime/<your-tv-app-here>). Myth's primary use 
case is for timeshifting programming. That then enables Myth to work 
properly, with all it's included features (like commercial flagging) 
available to run on the data. And many people have found, once you're 
using Myth as it's meant to be used, you can take back your life from 
the whims of the TV Schedulers, and watch what you want, when you want.

> FWIW, I'll probably take what I get from these answers and start
> searching in the code as to why they make a difference.

All kinds of things change these values.

Using a slave backend (For recording)? Increase networking and DB overhead.
Using a remote frontend (For playback)? Increase networking and DB overhead.
Using remote-mounted storage groups? Increase FS overhead.
Using DVB/ATSC? Increase allocation,de-allocation and tuning times.
Using IP Recorder? Increase networking overhead.
Using Brooktree capture? Include/increase capture overhead (Compression 
overheads).
Using IR-controlled STB? Increase tuning/lock overhead (IR Blaster).
Using Firewire capture? Increase allocation overhead (Firewire reset).
Using wireless networking? Increase network overhead (Massively!).

All these things are factors in how Myth performs, both in "Live TV", 
and in recordings. But in recordings it's nowhere near so important, as 
a missed 5 seconds of commercials at the start of a show isn't so 
visible as the 5 second wait to change channels.

I'm certain the developers will appreciate non-breaking patches to the 
code to help increase any and/or all of the above, but do be warned that 
many eyes have already looked over these code paths thorourghly and 
found little to optimise.
-- 
Robert "Devil's Advocate" Johnston


More information about the mythtv-dev mailing list