[mythtv] MythChannels checkin review (was: DVB todo list)
ramon.roca at xcombo.com
Mon Aug 18 16:17:09 EDT 2003
> I was talking mainly about the changes to existing code and the DB. You
> can't really say there "I'll fix it later". As for what concretely I had
> in mind, see my first post in the thread "DVB Big PATCH, Part I - for
> CVS pls", from 04 Aug 2003 17:36:45 +0200.
MythChannels is just under development, just like DVB. About the thread that
you are mentioning, I thought that I gave a response to all those questions
you mention, however I have no problem in being patient repeating them:
> * All the PID stuff
Currently mytchannels only feeds distinct types of PIDs when are known.
Doesn't do nothing with playback (a lot have to be done here). I submited a
way dor diferentiating them therefore help those future developments. I have
no problem if you come with a distinct format to put all of them in a single
column or whatever format of your preference, but in the meantime I coded in
a certain way, you don't.
> * The freq conversion (not) in the backend
I know that you take out that conversion from the dvbtools because you find
that horrible (?), but the fact is that taking that out and since in some
cases DVB frequencies are never expressed in those units, there was a bug
introduced because a user can keep trying to tune to an invalid frequency
that he thinks is ok without success, being very difficult to diagnose that
(It happened to me). I see here there is two solutions:
a.-Keep consistent with dvbtools/dvb drivers to convert the values to a freq
that have sense (all dvb freqs are > 1000000, so it's quitre easy to
recognize the unit)
b.-Provide a clear message before tunning warning him that the freq used was
To me makes more sense solution a), it is consistent with dvb consensus of
use of frequencies, the driver, and can be done in a single point, channels
can be feeded in many ways/formats, so it's nice to recognize all of them.
So I've fixed this on that way, you don't.
> * The caps change in the enum (first item in my list) (to avoid
> later changes to the users' databases)
It's "enum" (LOV checked), so no way of confussion/errors here. In the code
is used quite often this comparison to findout the channel type, to change
that that form the database we should change the code to make case
insensitive those comparisons, If you want, certainly it can be done, but I
don't see it as a priority/stop issue.
> I also have a really bad feeling with the number of new tables. I
> personally think that every new table makes it harder to find your way
> around in MythTV, esp. for new developers and advanced users who look at
> the database, and harder to navigate it in GUI DB tools. You're adding
> something like 10 new tables. Use as many tables as really absolutely
> necessary, but no more. I haven't looked enough on it, though, to be
> able to say, if you really need all or could reasonably get rid of some.
There is not any table introduced without a reason. As discussed before, if
that information is not in tables, should be somewhere and I do find easier
to have that in the database than in configuration text files on the
filesystem. Certainly many of them are just related to some type of channel
reception/types, so the only possibility that I do see here is to load those
tables in separate scripts instead of cvs.sql/mc.sql etc to make them
optional (i.e., only for DVB setup), not sure if it is a good solution since
it will add an additional required step for some setups ans therefore
crypt, conditionalaccess -> for CA support
provider, languages -> for DVB support (provider also for CA)
satellite, diseqc, diseqc_ports -> for DVB-s support
channellists, channellistsmembers -> Channel lists support
Once using dvb, I don't think that disgregating by reception type will be
that helpul since you'll only be able to avoid a few of them. On the other
hand I don't see that complicated, will be a lot more complicated to have
that disgregated in configuration files, and by it's name, it's easy to
imagine what's about, on the other hand a few of them are just
master/detail, wich is very know way of designing normalized sql databases.
> Note that I didn't look at all at the MythChannels code itself (the part
> which doesn't touch existing code), so I can't say anything about that.
I do recommend you to do so, I'm sure that you'll find more issues there
that can be helpful. If not it's quite difficult that you get understanding
of what's about or the arguments that I'm using while answering your
Again, I don't see any *stop issue* on any of this.
More information about the mythtv-dev