[mythtv] DVB support - Status update

[Rick King]

Hi Ben,

I'm really annoyed that I can't spend ANY time on this ATM. Its great work
you are doing which deserves alot of praise. However, as I said before I
believe I have a good flexible schema for the database which avoids stuffing
multiple values into one field, avoids filling the database with device
specific options, tables or blanks and avoids the generic columns on your
suggestion below. The problem is because I havent thought about it for a
while its not clear enough in my head for me to explain it. I will try and
spend a bit of time Thursday or Friday thinking it through and writing a
description of it (its not particularly complicated) but I can't guarantee
that. I will certainly have something at the end of next week for you.

Obviously as the one doing the coding its up to you what you do but I would
say that if you can hold off making these changes to the database side until
I can express my ideas, it might save some effort.

Sorry to be brief and vague again, I'm demoing my masters project tomorrow
and its not finished yet. :( (and then as soon as I've done that I've got to
write a 30+ page report on it) :(

Rick

----- Original Message ----- 
From: "Ben Bucksch" <linux.news at bucksch.org>
To: "Development of mythtv" <mythtv-dev at snowman.net>
Sent: Wednesday, April 30, 2003 5:46 PM
Subject: Re: [mythtv] DVB support - Status update


> 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.
>
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at snowman.net
> http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-dev
>