[mythtv] DVB support - Status update
Ben Bucksch
linux.news at bucksch.org
Wed Apr 30 19:46:57 EDT 2003
As promised, here my alternate idea about how to store a variable set of
properties to a DB column, without adding a new table each time or
adding *all* the possible columns to *all* rows. E.g. I need different
tuning parameters for a channel, depending on if it's on a DVB or analog
TV or different options for capturecards, depending on the type of card.
My current (implemented) solution is to store them all in one column and
there store a string of name/value pairs like "freq=235745|pol=v|symbol
rate=22000" for DVB-S channels, "channum=54|finetune=0" for analog
channels and a much longer list for DVB-C channels. I am not happy with
that, and Isaac expressed that he dislikes it.
My other idea was to create one new table which stores all these
variable properties for all tables/columns. This is similar to the
existing table codecparams, but more general, like the settings table
(in fact, codecparams could be stored in this new table).
The table would have the following columns (names are not good, should
find better words):
* "table" - set or string - the name of the table to which the
property applies
* "is" - int - a unique ID (primary key) for the row (in the above
table) to which the property applies, e.g. the cardid for table
capturecard
* "column" - set or string or int - the column (within the above
table) to which the property applies
* "name" - string - property name/key
* "value" - string - the content of the property
some example rows for the table:
| table | id | column | property | value
----------------------------------------------------------
1 | channel | 1 | tuning | freq | 4576457
2 | channel | 1 | tuning | pol | V
3 | channel | 1 | tuning | symbol rate | 22000
4 | channel | 1 | subtuning | pid vid | 512
5 | channel | 1 | subtuning | pid aud | 513
6 | channel | 2 | tuning | freq | 4576457
7 | channel | 2 | tuning | pol | V
8 | channel | 2 | tuning | symbol rate | 22000
9 | channel | 2 | subtuning | pid vid | 514
10 | channel | 2 | subtuning | pid aud | 515
11 | capturecard | 1 | options | use ts | 1
12 | capturecard | 1 | options | dvb type | S
The column "column" is strictly unnecessary, but makes the meaning of
the properties clearer and also allows to group properties. For example,
if all channel/tuning properties match between 2 channels and only the
channel/subtuning properties differ, DVB cards can (at least the budget
ones in theory) tune to both channels at the same time.
I would write mythcontext convience functions which allows to get/set
the properties for a given table/column/id, e.g.
typedef map<QString, QString> ParameterList;
GetParameterList(const QString& table, const QString& column, int id);
SetParameterList(const QString& table, const QString& column, int id,
const ParameterList& list);
SetParameter(const QString& table, const QString& column, int id,
const QString& name, const QString& value);
What do you think of that? Isaac? If you don't like it, what would you do?
Ben
Ben Bucksch wrote:
> Isaac Richards wrote:
>
>> I think it's a pretty poor idea to make things that
>> un-human-modifiable, but, whatever.
>
> It's still human-modifyable, but I am not totally happy with it
> either. If you have other suggestions, I am open for them. I thought
> about an options table, like codecparams, but one for all tables and
> several "columns" per table. I'll describe it more detailed later.
>
> I don't think that extending the channel table is a good idea, though,
> because there are a *lot* of options for DVB tuning (about 10), and
> neither a table specifically for DVB, because it's probably not the
> last tuning method. I need to add a few options to the capturecard as
> well. So, I don't think that would be very future-proof.
More information about the mythtv-dev
mailing list