[mythtv] Channel changing Bugs...

[Henk Poley]

> Van: Ben Bucksch <ben.bucksch.news at beonex.com>
>> 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.
> <snip>

Yes, indeed, and ripping it out now and reimplementing it when everything
gets digitaly broadcasted seems dorky to me...

Analog (now):
USA: unique frequency is unique channel number (and vice versa)
EUR: unique channel has frequency (sometimes multiple)
     channel number (read: order) is user defined

Digital ("tomorrow"):
unique channel has frequency (data stream) and sub-stream number.

See the differences, you basicaly need an extra row for the sub-stream
number, that's about it. And it might as well lead some 'ignorant' ;-)
Americans to the walhalla of user defined channel order.

Dropping chanid -which only equals to freqency in the USA- saves a couple
of milisecs, singlehandedly drops support for Europe and possibly other
contintents too, and you will need to reimplement the code when adding
support for purely digital stations.

> Van: Andy Davidoff <dert at pobox.com>
> 
> I'm not saying the members of the discussion support the idea, just
> that all comments do, whether intentionally or not.  Chanid duplicates
> existing data available in the same place, while adding complexity.
> 
> There's an easy solution to the >999 channels problem: drop chanid.

I hope I have enlightened you :-)

	Henk Poley <><