[mythtv] Understanding the myth source code

[James Courtier-Dutton]

On 28 May 2010 18:50, Ed W <lists at wildgooses.com> wrote:
>
> Not looked for far too long, but I really do think there is some scope for
> someone with some time to at least contribute an instrumentation patch and
> hopefully others will dig in and start to tune things?  Intuitively it seems
> it should be possible to get a frontend channel change experience in the 1-2
> second range for DVB-T and perhaps even sub 1 second for changes on the same
> mux...
>

I have done some experimenting.
As a comparison and to save me time regarding the channel change time,
I tried other open source tv recorders.
One is called VDR.
An interesting point of VDR is that they have actually already
implemented my two main ideas.
1) Fast channel changes.
2) Continuous update of the channels.conf file.
So, I managed to test a "proof of concept" without writing any source
code. I.e. I just tested VDR.
VDR has some nice features.
1) You do not have to go through a "tune" or "scan" stage during
setup. It is continuously re-tuning in the backround.
2) Its channel change times are very quick. Less that 2 seconds and
that is with the frontend across the network.
I have not tested the same mux channel change times.

If I could find an easy way to get rid of the processing myth does
between DVB card and the recorded data on the HD, I would be much
closer to quick channel switch times in myth.
VDR does not do any processing between DVB card and the recorded data
on the HD, it only filters on PID.
All the processing is done after that.
It builds a separate index file that the frontend uses to find each
I-Frame when seeking during playback.
So, all the processing is done in the "playback" stages, and not in
the "recording" stages.
This also has the added bonus in that the recording is a very good
likeness to what actually came from the DVB card and it minimises the
likelihood of a bug causing the recording to fail. If there is a bug
in the "processing" stage, and this stage is in the "playback" stages,
one can fix the bug and then the playback will work better, as the
recording itself is still good. If the "processing" stage is done
before record, and there is a bug, your recording is broken and even
after fixing the bug, you cannot view your film.
So, from a risk perspective, currently, I would say that VDR is a less
risky option.

Do the myth developers agree with me that minimising the amount of
processing between DVB card and the recording on the HD is a good way
to go?
If so, I might put some time in to get there, but if myth developers
think the current myth approach is better, I am unlikely to get my
patches included, so I might as well do my own thing.