[mythtv] Fw: DVB Big PATCH, Part I - for CVS pls
ramon.roca at xcombo.com
Mon Aug 4 19:33:18 EDT 2003
> * enum('Analog','DVB-s','DVB-c','DVB-t','Personal') DEFAULT 'Analog'
> NOT NULL;
> I'd use uppercase for DVB-S etc., that's the common notation.
good idea, maybe on next? ;)
> Please define "Personal".
take a look for the definitition at mythchannels/channelstree.cpp. Anwyay
it's reserved still for future use.
> * PIDs
> o Please use more descriptive names for the PID fields. vpids,
> apids, adpids, tpids, ppids, what? Which one is the generic
> one for things that we don't support yet?
adpids=audio dolby pids
We don't support some all of them, but I'm already able to fill them. Nice
to have them already uploaded, harder if we do have to do it later once the
user have already worked on customizing his channels
> o As discussed: Why do we need that separation at all, if the
> PIDs are usually chosen automatically anyways? I don't
> totally oppose the separation, but it makes things a bit
> more complicated.
Yes. Discussed theoretically. Right now we still need at least audio/video.
Sure will be nice to update them, but thats not done. Once we have it done,
maybe we will still need them, i.e. to force an specific audio pid for a
given channel in a distinct criteria than the general preferences... anyway
now Is how it works.
You'll find also a good reason to store them here:
I do find them more readable in that way instead of something like
> o If you separate them, you must read/use them all in
Unless the code gets magic, we will have to read them everywhere we want to
use them =)
> * I already rejected that freq conversion in the backend.
You are feel to reject/improve whatever you want. I'm sure that having coded
more than 7,000 lines of C++/Qt without many prior experience on that,
you'll find things to be improved.
> * Do you need a primary key for the conditional access table? It
> only lists 1:n properties for providers, it doesn't have an
> "identity" itself.
Don't know, I just use to create a a pk to every table I do create ;-) It's
certainly a relationship table, In the meantime it's useful to filet
channels when you are grabbing them from internet by conditional access
> * "Deutsch", not "Deustch" ;-)
Sorry. Given my english, I'm am sure that will be more like this, feel free
to patch them whenever you see one.
> * You are adding a terrible lot of tables. Do you really need them
> all? For example
> o Can't you completely include the disecq settings into the
> sat table?
NO. Channels belongs to satellites, diseqc to antenna configuration. That
would be a BIG mistake. Imagine for instance more than one card in a backend
with different diseqc configurations as a source at each card.
> o Why do you need the sat table at all? It seems you only need
> it for disecq, so why is the current solution (one diseqc
> int in the channel_dvb table) not sufficient? Does anybody
> have a motor dish which accepts sat positions? Or do you
> just want to have a name, for a nicer UI (would be a
> reason)? Do you really need to prefill all the values, or
> can you fetch it from some imported channel config file?
You already mentioned some of the reasons. Every satellite receiver has that
table in somewhat format. In our case, having a relational database is the
best place to have it, better than hardcoded. Note it's basically static but
might have to be updated from time to time when new satellites are launched
or stop working.
> o What's that channellists? Nothing uses it, and I can't see
> how it would be used. Why do you need channellistsmembers
> and don't just add a single channellistid field to the
> channel table?
That's a master/detail. A common way to describe this kind of relationships
in a relational model.
Will be already used within mythchannels to browse channels by groups. All
the satellite receivers that I have seen have that propierty, and again,
since I'm able to load it.... Sure will be nice top extend that to the rest
More information about the mythtv-dev