[mythtv] Channel changing Bugs...

Ben Bucksch ben.bucksch.news at beonex.com
Thu Apr 10 04:24:35 EDT 2003


Chris Palmer wrote:

>jasonmiller wrote
>  
>
>>Ahh, ok, I missed the sourceid*1000 part of the chanid equation.  
>>One backward combatible solution would be to do a string concatenation 
>>of the id and sprintf(tmp, "%03d", channum) instead of adding. 
>>
Do I understand you correctly that you want to base the channel index 
(the way to connect channel table and program / record tables) on the 
channel number from the antenna? That's a very bad idea - the channel 
numbers for stations here in Europe are arbitary and may change at any 
time, esp. on the satellite. It happens every few months that a station 
disappears on one channel and maybe appears at another. Both because of 
changes on the satellite and on the head station in our house. The 
channel number is a technical detail that has a meaning only to tune the 
tuner into the station, not to humans. (In fact, you could argue that 
the table should be called "station", not "channel".)

While we're talking about it: the way the channum is currently displayed 
in LiveTV and used to change stations there is useless for me. For the 
reasons above, I don't know (and don't want to learn) which channum a 
given station has. Some stations even have channums like "SE17" and 
"E5", and I have no clue how to change to them apart from 
ChanUp/ChanDown (maybe I am dumb and missed some feature). What I'd need 
is a preset, so that I can just press 7 on my remote (only that one key) 
and have it tune into "Pro 7" (station name). The mapping 7 -> "Pro 7" 
is an arbitary choice of the user, that's how all TVs work here.

>The database can keep things organized using an AUTOINCREMENT field for 
>the chanid.
>
Yes, it can, and autoincrements are simple to implement, but they are a 
*pain*, if you have to fix things manually (regenerate the channel table 
without losing program and record info, as mentioned).

IMHO, there should be at least the following fields in the 
station/channel table:

    * station id
      used to connect DB tables, no other purpose, never appears in the
      UI. Semantically an autoincrement, but implemented manually.
    * station preset
      A user-configurable number for the station. 2 purposes: Allows to
      change stations using the numeric keypad on the remote and
      (optionally) sorts stations in listings (e.g. EPG). Default may be
      based on the technical channel to meet expectations of American users.
    * xmltvid
      id used in the XMLTV listings. only used to resolve xmltv
      listings, the program table uses the internal station index
      (stationid) (This allows to change the xmltv source with possibly
      different ids).
    * short name
      For UI, represents station when there is limited space. Field
      should not be limited in length, though, and should be used in
      full length - I'd like to have e.g. "Kabel 1" as short name, not
      be limited to 5 chars.
    * long name
      For UI, represents a station when there is lots of space, e.g. in
      the info dialog on LiveTV.
    * Icon
    * video source and channel
      channel is the current "channum". used for the tuner only. never
      appears anywhere in the UI apart from the setup.

This doesn't take into account the problem somebody else mentioned, that 
you may get the same station from totally different cards, e.g. an 
analog tuner and a DVB-S (digital satelite) card. That would maybe 
indeed require a separate station table (having all the fields above 
apart from video source and channel), while the channel table connects 
station and video source, having as fields

    * video source index and station index
    * quality
      rating of different channels carrying the same station
    * channel, finetune
      for the tuner
    * brightness etc..

If there are different channels for one station, the app uses the 
channel with the best quality. If there are several requests for the 
same station (LiveTV + recording, 2 recordings, 2 LiveTV clients), the 
user could select who gets the best quality, or the app just gives 
recording precedence (switching Live TV to a worse channel, if necessary).



More information about the mythtv-dev mailing list