[mythtv] MythChannels checkin review (was: DVB todo list)
Ben Bucksch
linux.news at bucksch.org
Mon Aug 18 16:59:19 EDT 2003
Ramon Roca wrote:
>however I have no problem in being patient repeating them:
>
Please don't. We both wasted enough time on that already.
>> * All the PID stuff
>>
>>
>Currently mytchannels only feeds distinct types of PIDs when are known.
>Doesn't do nothing with playback ... 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.
>
I think we *really* discussed this enough. I'm talking about recording
(not playback), which your patch broke. IIRC, I did propose how you can
do it, the change can be done within less than 5 minutes. Call it "under
development" or whatever you want, but you need to fix this before it
can go into CVS. Otherwise, you'd cause a regression for no good reason,
which is not acceptable.
>> * The freq conversion (not) in the backend
>>
>>
>there was a bug introduced because a user can keep trying to tune to an invalid frequency that he thinks is ok without success
>
It's not a bug, if the user manually inserts invalid data in the
database and it doesn't work. I didn't specify a unit in the DB docs I
wrote, that's my fault, sorry, I'll do that with the next update.
>So I've fixed this on that way, you don't.
>
Yes, I wrote it intentionally in a certain way, with a reason (which I
explained a lot), and you just go and change it, because you like it
differently. You shouldn't be surprised, if I say no. I am not willing
to discuss this (or the PID stuff) further.
>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 introducing risks...
>
Some of the information (e.g. about satellites) can most likely be read
from config files, which have to be read anyways to get the channel/freq
information.
Maybe you can store some information in the code (or translation files)
directly, e.g. the "de" -> "Deutsch" mapping.
Also, maybe you can roll several tables into one without losing
information or flexibility.
Alternatively, maybe you could at least prefix the (really) dvb-specific
tables with "dvb_" in their table name, that would make using and
understanding the DB much easier IMHO.
And I'd really appreciate some documentation about what the tables are
for, exactly. It may be obvious to you, but not to me, and it has to be
obvious *without* reading any code.
For example (why docs are so important), there are some "sharable" field
in some tables, but I have no idea what exactly they mean or of they are
functional at all, and that although I did find an old post about in on
the mailing list archive. Maybe that field would actually be
applicatible for DVB with its parallel recordings, but I don't know.
But in general, I didn't look close enough at the tables to say that
they must be changed before checkin.
[direct MythChannels module code]
>I do recommend you to do so, I'm sure that you'll find more issues there
>that can be helpful.
>
Honestly, with your reactions in this case, I am inclined to not care at
all about MythChannels code and just put myself in user mode.
I'd be still glad to use it (apart from mplayer ;-P ).
>Again, I don't see any *stop issue* on any of this.
>
But I do, and to get my approval for checkin, you have to fix it.
More information about the mythtv-dev
mailing list