[mythtv] dvbsections.cpp / dvbchannel.cpp Changes In Progress

Taylor Jacob rtjacob at earthlink.net
Mon Aug 23 11:47:47 EDT 2004

>> The channels table will add a few fields for each service.  (ServiceID,
>> Reference to dvb_transport, pmtcache (which will be removed later on
>> when Auto-PID functionality is tested and working for dvbcam), EITSource
>> Transport.
> I'd say that even when Auto-PID works, leave in a PID cache to speed up
> channel changes.

Right now the PMT tables seem to come in about a second at worst after the Transport is tuned,
which might be as fast as the recorder can start.  Then again it seems to take me a good second
between channel changes right now in LiveTV, so slowing it down anymore would be even more

A better solution might be to keep a PMTVersion number in the channels table, and verify it in the
dvbverify thread, and also when tuning (Similar to what is already in place, but have it update
the fields in dvb_pids).

I just wonder how to handle it when a service is not where its supposed to be (right now it seems
to crash for me sometimes).  I suppose make the recorder not start, and start searching, and when
you finally find it or give up emit a signal to handle this error.

Another part of this solution is to add support in the Backend protocol so that you can first set
the frontend in a mode where it displays a page with some text such as "Searching for service...",
and then when its found it sets the forntend into a mode where it is expecting Video and Audio. 
This change also should be implimented such that the frontend can display a user formatted message
and just audio for audio channels.  I know this is needed since my frontend freaks out sometimes
when the backend takes too long to send video to it, and I have heard it mentioned before.

>> I am considering making there be a logfile of channel
>> adds/deletes/changes for the dvbscanning code, so that users can see
>> what is going on (at least when its first being implimented and hasn't
>> been 100% tested and working).  Should this be a file, or should I make
>> a table in the DB that holds this information for a week or so similar
>> to the signal strengh report?)
> I think this would be a good feature - even when working, it'd be nice to
> be able to see when channels have been added/removed.

This might go great in the MythLog tool I just need to do some reading about it.

More information about the mythtv-dev mailing list