Timothy D. Lenz wrote:
> which, but not all, will be shut down in a year. For ATSC .1 is the primary
> channel and .2, .3, etc are the sub channels. The "#" on the remote could
> be used for the "." In the channels.conf an ATSC next channel number would
> look like:
> :@13.1
Well, at least I've never seen any TV remote with a '.', '#' or '-' key
on it. There wouldn't be a need for such a key here anyway.
'Just adding a . to the channel number' would horribly break lots of
things, since internally VDR assumes that any channel is identified by a
plain old integer number. VDR and plugins use calls like
Channels.GetByNumber(6), and not Channels.GetByNumber('6.1').
And don't even think about using floating point numbers for channels.
Why? For example, because there is no floating point representation for
1.1, the nearest binary floats are 1.09999999999999986677 and
1.10000000000000008882 (rounded).
The most realistic way to implement this is to add yet another 'name'
system for channels, so that the VDR-internal channel 15 is
'KUAT'/'6.0'. That way, VDR could continue to use the 'simple'
numbering, and just the channel switching would use the new numbering.
On a long term, this could even replace the 'old' :@number grouping, so
channels are numbered straight from 1 up without gaps.
Of course there are a lot of open questions. For example, does the
'channel up' key switch from 6.0 to 6.1 or to 7.0? Do we need two
(three, counting the bouquet left/right) keys for channel flipping? How
does this grouping map to the channels.conf? And what happens as soon as
people start crying for naming channels like '2.6.1' or '2.3-5'?
This probably has to start as a separate VDR patch project, and should
not rush into VDR core. This needs some time of gathering experience to
find the best way of handling.
Cheers,
Udo
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
