[mythtv] [PATCH] DVB support

[Isaac Richards]

On Friday 02 May 2003 12:25 pm, Ben Bucksch wrote:
> Hi Isaac, thanks for the quick response.
>
> Isaac wrote:
> >I asked you not to munge up MpegRecorder at all, but you did.  Inherit off
> > of the base recorder class.
>
> I didn't understand you that way. Should I just *copy* all your code
> which is in mpegrecorder after my patch (for seeking etc.), 320 lines in
> 24 functions, although it's identical in 3 files, which all only have
> 150 lines and 6 functions or less right now?

Yes.  But it's only 2 files, since you should also be taking out the stream* 
stuff, as you said it's not fit to commit anyway.

> >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.
>
> That means that I have to rename *all* the references to |Channel| in
> all other files. Also, I find it confusing to have the analog-specific
> part having a generic name like Channel.

Yup, that's what it means.  Trying to match the existing abstraction layers -- 
recorderbase and decoderbase.  

> >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.
>
> I thought I'd wait for your reaction before I write code that you may
> eventually reject anyways. Or ask me to use another way to store the
> parameters.

I said your proposed stuff (a table like the recording parameters, 
essentially) would be my preferred way to handle it.

> >What's with the chan->GetCardID() -- isn't that already a member variable
> > in the TVRec class?
>
> Possible, havn't noticed that, will check.

Since you made it pass that int to the channel object, it's there =)

> >Everything else looks ok, from a quick once-over.
>
> That's great. Before I submit a new patch (dissecting the patches
> manually costs time), could you please tell me any other complaints you
> may have, so that I can fix them in the next batch of patches, having
> them ready to be checked in?

Hmm..  I think the newstruct.pro stuff should get included in the main 
settings.pro file.

> >I'm not planning on applying anything until after the 0.9 release, anyway
>
> Too bad. I was hoping to get that puppy in in the next days, partially
> to avoid conflicts and having to fix them manually.

Sorry, but that's not going to happen.  I'm not going to introduce massive 
changes that breaks things this close to the next release.  I have to 
maintain this stuff, and live with the code.  You don't =)

Isaac