[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