[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