[mythtv] [PATCH] DVB support

ramon.roca at xcombo.com ramon.roca at xcombo.com
Fri May 2 17:23:01 EDT 2003


I'm impressed for the incredible amount of work that has being done in the
very last days.
I'm really suprised that Ben has done tha major part of the DVB remotely,
without a card!. I just can't believe it.
Personally I'm afraid for haven't got time for working deeper on it, you
guys go that fast that I can't find time for catch you!. Just amazing.
About the current discussions...

> > 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.
>

channels.conf is certainly a not very well readable format, also aren't
files like /etc/inittab or /etc/fstab, but is the facto "standard" created
by the DVB driver developers, all the applications that are currently
dealing with it and therefore the cuurent DVB users are used with it. I do
agree that some of the ideas (multple row, etc) that I've been reading could
make this more "user friendly", however we must be aware that we will create
a mythtv "propietary" way for storing this data and therefore certainly
create the need for a tool that populates the channel info. If in the
meantime if we simply use the channels.conf format, we can just load this
data straight to the table without major inconveniences.

There is many ways to get channels.conf for a given type of reception. What
I'm familiar with is the ones that works with DVB-s (Satellite). That data
could be retrieved online even without having to tune from a variety of
sources: I'm looking already onto it, and as soon as I will have time for it
and we all agree in a format, I'm COMMITED to write scripts for loading the
database (I'm sorry but what I can not commit is on timeframes). Anyway
filling manually the database will be only a temporary solution, so I don't
think that we must be afraid with this.

As a examples of sources:
www.satcodx2.com/_data/0192.sdx (for a given satellite, there is more url's
for each satellite). I've been testing perl scipts that are grabbing from
there.
http://www.dxandy.de/cgi-bin/dvbchan.pl as a example of a web-based
generator
With Satellite, I think that to use this kind of sources are even better
than dvbtune since we still need the list of transponders available for each
satellite, that changes from time to time so to get it from those online
sources will be the best way to ensure a quality up-to-date data around all
the globe. Anyway, to have dvbtune will obviously be also good. If we want
to assist at this level, maybe I've to thing also something to configure
diseq conmuters which are common in case that you want to get signal from
more than one satellite (diseq.conf file)

> > 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.
>

To me that sounds as a minor question.

> > 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.
>

What about chanid? Let the users choose wich column do they want to use?


Those are just my opinions, any final decission on all of this will be of
course ok to me!!

Thanks again,

Ramon.



More information about the mythtv-dev mailing list