On Sat, Mar 8, 2008 at 3:05 AM, Udo Richter <[EMAIL PROTECTED]> wrote:
> 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).
Correct me if I'm wrong but using scaled integers would allow doing
X.Y just fine.
> 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.
That might be the most realistic way to fix this if you refuse to
replace the outdated regular integers with something better suited for
the task. Why does it really matter if upgrading to a more
appropriate numbering system breaks things? They'll just have to be
fixed as has happened many times before. The question of remote
control behavior can be addressed as setup options. Let the user
decide how he wants his remote control to act.
> And what happens as soon as people start crying for naming channels
> like '2.6.1' or '2.3-5'?
I don't really believe something like that would be the cause of big
debate but if it were it could easily be resolved by either using
whichever works best, or by a vote.
> 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.
I completely agree here. We want a system that best suits the needs
and the only way to figure that out is by testing the system.
vdr mailing list