[mythtv] [PATCH] DVB support

[Isaac Richards]

On Thursday 01 May 2003 10:12 pm, Ben Bucksch wrote:
> Channels must be entered manually into the database (see docs posted
> earlier). Somebody needs to write a importer from a channel listing
> format, e.g. dvbtune's XML output (data directly from the DVB feed) or
> channels.conf. Ideally, we should one day have a manual graphical config
> tool as well, at least to change the names and presets of the channels.

This needs to be taken care of before I can accept things.  Having people 
manually insert things into the database isn't going to happen.

>  1.2. Stream
>
> I have a simple recorder and channel implementation (the normal external
> channel impl. had some dependencies on analog TV tuning) which should
> allow people to use an external program to tune and to receive an MPEG
> stream via stdout/pipe.

Don't include changes if you don't think they should be applied.

>  2.2. Base classes
>
> Both the |Channel| (used for tuning) and the |MpegRecorder| (used to
> record MPEG data) have fairly large dependencies on V4L / analog TV
> (/dev/video devices etc.). While I needed some generic functionality in
> these classes, and other classes (TVRec, most notably) use the Channel
> interface extensively, the dependency on V4L of course broke DVB
> support, because there is no /dev/video. So, I separated the generic
> functionality and interface from the V4L dependencies, kept the generic
> functionality where it was and introduced new subclasses for analog TV,
> which then contain the V4L-specific parts. The new hierarchy is:

I asked you not to munge up MpegRecorder at all, but you did.  Inherit off of 
the base recorder class.  I'd also actually prefer it if you kept 
channel.cpp/h as the v4l interface, created a basechannel.cpp/h base class, 
and then inherited your dvb channel stuff off of that.

>  2.3. New tuning parameter storage
>
> As discussed recently, DVB tuning needs quite a number of new tuning
> parameters for each channel. I tried to come up with a generic and
> future-proof method how to store them. Unfortunately, Isaac didn't like
> my first solution, I haven't gotten any feedback on my other suggestion.
> I hope we'll see a good solution being proposed later, and it'll be
> implemented, but for now, I kept the method I already implemented,
> namely to store a list of parameters/properties in one field.

What you proposed would be preferable to what you have now.

> Analog tuning can optionally (per a compile-time flag, defaulf off) use
> the new way to store tuning parameters. If used, the channum column can
> be (ab)used as "preset" the way Europeans expect or even need (I can't
> enter a channum like "SE11" on my remote, and many of my analog channels
> have that format). In that case, the UI will show the preset in all
> places where it now shows the channum.
> For DVB, the channum is free to be used as preset anyways.

And how are people supposed to use the new format?  Manual db interaction?  
You didn't update filldatabase or anything to go along with it.

> 2.5. Don't use device in DB query
>
> TVRec uses the videodevice as parameter for almost every query. This 
> breaks, if there is no video device, e.g. for StreamChannel, maybe also 
> for DVBChannel. I don't think that's needed anyways, the card id should 
> work just as well, so I queried for that instead.

What's with the chan->GetCardID() -- isn't that already a member variable in 
the TVRec class?

Everything else looks ok, from a quick once-over.  I'm not planning on 
applying anything until after the 0.9 release, anyway, so no rush on getting 
things done in an acceptible manner =)

Isaac