Would it be possible to add support for the subchannel numbering system used with ATSC? Exmple of the channels in our area:
4 KVOA 4.1 KVOAD 6 KUAT 6.1 KUATD1 6.2 KUATK 6.3 KUATV 6.4 KUATC 9 KGUN 9.1 KGUND 11 KMSB 11.1 KMSBH 13 KOLD 13.1 KOLD-DT 14 KUDF 18 KTTU 18.1 KTTUDT 27 KUAS 27.1 KUASHD 34 KFTU 38 KUVE 40 KHRR 40.1 KHRR-DT 48 K48GX 58 KWBA 58.1 KWBA-DT 58.2 LATV
All the x.x channels are the new ATSC channels, rest are old NTSC most of 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
On 03/06/08 00:49, Timothy D. Lenz wrote:
Would it be possible to add support for the subchannel numbering system used with ATSC? Exmple of the channels in our area:
4 KVOA 4.1 KVOAD 6 KUAT 6.1 KUATD1 6.2 KUATK 6.3 KUATV 6.4 KUATC 9 KGUN 9.1 KGUND 11 KMSB 11.1 KMSBH 13 KOLD 13.1 KOLD-DT 14 KUDF 18 KTTU 18.1 KTTUDT 27 KUAS 27.1 KUASHD 34 KFTU 38 KUVE 40 KHRR 40.1 KHRR-DT 48 K48GX 58 KWBA 58.1 KWBA-DT 58.2 LATV
All the x.x channels are the new ATSC channels, rest are old NTSC most of 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
I don't like that dot notation.
You could add a '0' to the old channels and leave out the '.', as in
40 KVOA 41 KVOAD 60 KUAT 61 KUATD1 62 KUATK 63 KUATV 64 KUATC 90 KGUN 91 KGUND
Klaus
On Thu, Mar 6, 2008 at 12:49 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I don't like that dot notation.
You could add a '0' to the old channels and leave out the '.', as in
40 KVOA 41 KVOAD 60 KUAT 61 KUATD1 62 KUATK 63 KUATV 64 KUATC 90 KGUN 91 KGUND
That's fine as long as you don't actually have channel 60, 61, 62, 63, etc.. I don't particularly like the . either, but this method isn't any better.
On 03/06/08 17:36, VDR User wrote:
On Thu, Mar 6, 2008 at 12:49 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I don't like that dot notation.
You could add a '0' to the old channels and leave out the '.', as in
40 KVOA 41 KVOAD 60 KUAT 61 KUATD1 62 KUATK 63 KUATV 64 KUATC 90 KGUN 91 KGUND
That's fine as long as you don't actually have channel 60, 61, 62, 63, etc.. I don't particularly like the . either, but this method isn't any better.
Well, at least it doesn't require an additional symbol. Besides, channel numbers are just that: numbers - and that's *integers*, not decimals ;-)
Klaus
Well, ".", "#", "*", something in the channels.conf. "0" is not a valid notation because 0 is part of the number system. 40 won't work for KVOA because 40 is KHRR. And when displayed it should be "."
----- Original Message ----- From: "Klaus Schmidinger" Klaus.Schmidinger@cadsoft.de To: vdr@linuxtv.org Sent: Thursday, March 06, 2008 1:49 AM Subject: Re: [vdr] sub channel numbering system
On 03/06/08 00:49, Timothy D. Lenz wrote:
Would it be possible to add support for the subchannel numbering system
used
with ATSC? Exmple of the channels in our area:
4 KVOA 4.1 KVOAD 6 KUAT 6.1 KUATD1 6.2 KUATK 6.3 KUATV 6.4 KUATC 9 KGUN 9.1 KGUND 11 KMSB 11.1 KMSBH 13 KOLD 13.1 KOLD-DT 14 KUDF 18 KTTU 18.1 KTTUDT 27 KUAS 27.1 KUASHD 34 KFTU 38 KUVE 40 KHRR 40.1 KHRR-DT 48 K48GX 58 KWBA 58.1 KWBA-DT 58.2 LATV
All the x.x channels are the new ATSC channels, rest are old NTSC most
of
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
I don't like that dot notation.
You could add a '0' to the old channels and leave out the '.', as in
40 KVOA 41 KVOAD 60 KUAT 61 KUATD1 62 KUATK 63 KUATV 64 KUATC 90 KGUN 91 KGUND
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi!
On Thursday 06 March 2008 21:13:25 Timothy D. Lenz wrote:
Well, ".", "#", "*", something in the channels.conf. "0" is not a valid notation because 0 is part of the number system. 40 won't work for KVOA because 40 is KHRR. And when displayed it should be "."
We are talking about channel numbers, correct? Thats the arbitrary number I (or in the default case vdr) assign to an channel. vdr channel management has the advantage channel numbers even can have gaps between them. And I can even renumber them if I want to. So if KHRR is on 40 just moved it up to channel number 400, following up with assigning 40 to KHRR. Should 400 be taken by another channel, consider moving that one to channel number 400000 or taking a free x00 number.
Cya, Ed :)
On 03/06/08 21:13, Timothy D. Lenz wrote:
Well, ".", "#", "*", something in the channels.conf. "0" is not a valid notation because 0 is part of the number system. 40 won't work for KVOA because 40 is KHRR. And when displayed it should be "."
Well, 40 would become 400, accordingly.
Just add a 0 to each channel number (or two zeros, if you have two digit sub channel numbers).
Klaus
----- Original Message ----- From: "Klaus Schmidinger" Klaus.Schmidinger@cadsoft.de To: vdr@linuxtv.org Sent: Thursday, March 06, 2008 1:49 AM Subject: Re: [vdr] sub channel numbering system
On 03/06/08 00:49, Timothy D. Lenz wrote:
Would it be possible to add support for the subchannel numbering system
used
with ATSC? Exmple of the channels in our area:
4 KVOA 4.1 KVOAD 6 KUAT 6.1 KUATD1 6.2 KUATK 6.3 KUATV 6.4 KUATC 9 KGUN 9.1 KGUND 11 KMSB 11.1 KMSBH 13 KOLD 13.1 KOLD-DT 14 KUDF 18 KTTU 18.1 KTTUDT 27 KUAS 27.1 KUASHD 34 KFTU 38 KUVE 40 KHRR 40.1 KHRR-DT 48 K48GX 58 KWBA 58.1 KWBA-DT 58.2 LATV
All the x.x channels are the new ATSC channels, rest are old NTSC most
of
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
I don't like that dot notation.
You could add a '0' to the old channels and leave out the '.', as in
40 KVOA 41 KVOAD 60 KUAT 61 KUATD1 62 KUATK 63 KUATV 64 KUATC 90 KGUN 91 KGUND
On Thu, Mar 6, 2008 at 11:37 PM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 03/06/08 21:13, Timothy D. Lenz wrote:
Well, ".", "#", "*", something in the channels.conf. "0" is not a valid notation because 0 is part of the number system. 40 won't work for KVOA because 40 is KHRR. And when displayed it should be "."
Well, 40 would become 400, accordingly.
Just add a 0 to each channel number (or two zeros, if you have two digit sub channel numbers).
Klaus, come on, you know bastardizing the channel numbers like that is a horrible idea! ;)
On 03/07/08 16:31, VDR User wrote:
On Thu, Mar 6, 2008 at 11:37 PM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 03/06/08 21:13, Timothy D. Lenz wrote:
Well, ".", "#", "*", something in the channels.conf. "0" is not a valid notation because 0 is part of the number system. 40 won't work for KVOA because 40 is KHRR. And when displayed it should be "."
Well, 40 would become 400, accordingly.
Just add a 0 to each channel number (or two zeros, if you have two digit sub channel numbers).
Klaus, come on, you know bastardizing the channel numbers like that is a horrible idea! ;)
"Bastardizing" channel numbers the way those "sub channels" do, that's a horrible idea!
Channel numbers are *numbers*, *integer* numbers! There's a first channel, and a second one, and a third one, and they are numbered 1, 2 and 3. Now what's a "2.1" channel? Is that "ten percent more than the second channel"?
VDR stores channel numbers as integers. So if you want to have a numbering scheme where you have channels "between" other channels, you need to make room for these additional entries. And the only way I see to do this is to shift all numbers one digit to the left.
Klaus
So what happens when the sub number was 2.10 is it now 21? And 2.11 becomes 21? I don't understand why there are such numbers to begin with. Why not just map 2.1 to the next available open number, giving the user the choice to move the channels in any order afterwards?
my 2c
On 3/7/08, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 03/07/08 16:31, VDR User wrote:
On Thu, Mar 6, 2008 at 11:37 PM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 03/06/08 21:13, Timothy D. Lenz wrote:
Well, ".", "#", "*", something in the channels.conf. "0" is not a
valid
notation because 0 is part of the number system. 40 won't work for
KVOA
because 40 is KHRR. And when displayed it should be "."
Well, 40 would become 400, accordingly.
Just add a 0 to each channel number (or two zeros, if you have two digit sub channel numbers).
Klaus, come on, you know bastardizing the channel numbers like that is a horrible idea! ;)
"Bastardizing" channel numbers the way those "sub channels" do, that's a horrible idea!
Channel numbers are *numbers*, *integer* numbers! There's a first channel, and a second one, and a third one, and they are numbered 1, 2 and 3. Now what's a "2.1" channel? Is that "ten percent more than the second channel"?
VDR stores channel numbers as integers. So if you want to have a numbering scheme where you have channels "between" other channels, you need to make room for these additional entries. And the only way I see to do this is to shift all numbers one digit to the left.
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Fri, Mar 07, 2008 at 04:57:50PM +0100, Klaus Schmidinger wrote:
On 03/07/08 16:31, VDR User wrote:
On Thu, Mar 6, 2008 at 11:37 PM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 03/06/08 21:13, Timothy D. Lenz wrote:
Well, ".", "#", "*", something in the channels.conf. "0" is not a valid notation because 0 is part of the number system. 40 won't work for KVOA because 40 is KHRR. And when displayed it should be "."
Well, 40 would become 400, accordingly.
Just add a 0 to each channel number (or two zeros, if you have two digit sub channel numbers).
Klaus, come on, you know bastardizing the channel numbers like that is a horrible idea! ;)
"Bastardizing" channel numbers the way those "sub channels" do, that's a horrible idea!
Channel numbers are *numbers*, *integer* numbers! There's a first channel, and a second one, and a third one, and they are numbered 1, 2 and 3. Now what's a "2.1" channel? Is that "ten percent more than the second channel"?
VDR stores channel numbers as integers. So if you want to have a numbering scheme where you have channels "between" other channels, you need to make room for these additional entries. And the only way I see to do this is to shift all numbers one digit to the left.
Klaus
I'm sorry if you don't see it the way the rest of us do, but the goal here should be the user experience. The channels are advertised from the channel makers as 2-1, 2-2, or 2.1, 2.2, or 2*1, 2*2 or whatever. When users go to a channel, they are not thinking:
hmm what channel "number" shal I go to
no they know
if I want to watch WJLA, I go to 7*1 for the HD version, or 7*2 for the SD version. They know this because that is how it is advertised to them in their markets. They have accepted that channels are not just integers.
The other issue you have is that channels in their system have well-known identifiers that are called "channels" for example NASATV is called channel 213. This is something we have talked about in the past both on and off-list. If you want to somehow map these subchannels to some wierd integer that's say greater than a million, that's fine, your channel numbers are integers, but the user needs to be able to select the channel he wants. Is the goal here that the user is able to use the program or that channels can continue to antiquatedly be identified as ints?
_J
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
So if provider 1 broadcasts a 2.1 channel and provider 2 also broadcasts a 2.1 channel and you as a vdr user can have more than 1 provider. What will the channel numbering scheme be for Provider 2? Will this introduce a bouqet in vdr?
On 3/7/08, jhall@maoz.com jhall@maoz.com wrote:
On Fri, Mar 07, 2008 at 04:57:50PM +0100, Klaus Schmidinger wrote:
On 03/07/08 16:31, VDR User wrote:
On Thu, Mar 6, 2008 at 11:37 PM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 03/06/08 21:13, Timothy D. Lenz wrote:
Well, ".", "#", "*", something in the channels.conf. "0" is not a
valid
notation because 0 is part of the number system. 40 won't work for
KVOA
because 40 is KHRR. And when displayed it should be "."
Well, 40 would become 400, accordingly.
Just add a 0 to each channel number (or two zeros, if you have two
digit
sub channel numbers).
Klaus, come on, you know bastardizing the channel numbers like that is a horrible idea! ;)
"Bastardizing" channel numbers the way those "sub channels" do, that's a horrible idea!
Channel numbers are *numbers*, *integer* numbers! There's a first channel, and a second one, and a third one, and they are numbered 1, 2 and 3. Now what's a "2.1" channel? Is that "ten percent more than the second channel"?
VDR stores channel numbers as integers. So if you want to have a numbering scheme where you have channels "between" other channels, you need to make room for these additional entries. And the only way I see to do this is to shift all numbers one digit to the left.
Klaus
I'm sorry if you don't see it the way the rest of us do, but the goal here should be the user experience. The channels are advertised from the channel makers as 2-1, 2-2, or 2.1, 2.2, or 2*1, 2*2 or whatever. When users go to a channel, they are not thinking:
hmm what channel "number" shal I go to
no they know
if I want to watch WJLA, I go to 7*1 for the HD version, or 7*2 for the SD version. They know this because that is how it is advertised to them in their markets. They have accepted that channels are not just integers.
The other issue you have is that channels in their system have well-known identifiers that are called "channels" for example NASATV is called channel 213. This is something we have talked about in the past both on and off-list. If you want to somehow map these subchannels to some wierd integer that's say greater than a million, that's fine, your channel numbers are integers, but the user needs to be able to select the channel he wants. Is the goal here that the user is able to use the program or that channels can continue to antiquatedly be identified as ints?
_J
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Fri, Mar 7, 2008 at 8:46 AM, Theunis Potgieter theunis.potgieter@gmail.com wrote:
So if provider 1 broadcasts a 2.1 channel and provider 2 also broadcasts a 2.1 channel and you as a vdr user can have more than 1 provider. What will the channel numbering scheme be for Provider 2? Will this introduce a bouqet in vdr?
That problem already exists even without sub-channels and has never been officially addressed (to my knowledge). The people I know dealing with this issue pad the channel numbers by adding a set number. For example, if provider A and provider B both use 0000-9999 for their channel numbers, the user pads one of the providers by adding say 10000 to the channel numbers thus having one provider retain 0000-9999, and the other becoming 10000-19999.
Then perhaps the core should expose the required features, so that Klaus can keep it his default way but a plugin can extend without having to patch the core. The end user can then choose from a range of plugins for his/her provider(s) in the way they think is best.
On 3/7/08, VDR User user.vdr@gmail.com wrote:
On Fri, Mar 7, 2008 at 8:46 AM, Theunis Potgieter theunis.potgieter@gmail.com wrote:
So if provider 1 broadcasts a 2.1 channel and provider 2 also broadcasts a 2.1 channel and you as a vdr user can have more than 1 provider. What will the channel numbering scheme be for Provider 2? Will this introduce a bouqet in vdr?
That problem already exists even without sub-channels and has never been officially addressed (to my knowledge). The people I know dealing with this issue pad the channel numbers by adding a set number. For example, if provider A and provider B both use 0000-9999 for their channel numbers, the user pads one of the providers by adding say 10000 to the channel numbers thus having one provider retain 0000-9999, and the other becoming 10000-19999.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
And that works to a point. I have been trying to pad using the sat number for example 790000, 970000, 1130000, etc. But this makes the numbers a bit long. The problem here is that some providers like to sprawl with there numbers using 4 and sometimes even 5 digits. The 5 digit channel problem is minor though as those seem to tend to be data channels with nothing on them.
----- Original Message ----- From: "VDR User" user.vdr@gmail.com To: "VDR Mailing List" vdr@linuxtv.org Sent: Friday, March 07, 2008 9:53 AM Subject: Re: [vdr] sub channel numbering system
On Fri, Mar 7, 2008 at 8:46 AM, Theunis Potgieter theunis.potgieter@gmail.com wrote:
So if provider 1 broadcasts a 2.1 channel and provider 2 also broadcasts a 2.1 channel and you as a vdr user can have more than 1 provider. What will the channel numbering scheme be for Provider 2? Will this introduce a bouqet in vdr?
That problem already exists even without sub-channels and has never been officially addressed (to my knowledge). The people I know dealing with this issue pad the channel numbers by adding a set number. For example, if provider A and provider B both use 0000-9999 for their channel numbers, the user pads one of the providers by adding say 10000 to the channel numbers thus having one provider retain 0000-9999, and the other becoming 10000-19999.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
People I know dealing with this issue pad the channel numbers by adding a set number. For example, if provider A and provider B both use 0000-9999 for their channel numbers, the user pads one of the providers by adding say 10000 to the channel numbers thus having one provider retain 0000-9999, and the other becoming 10000-19999.
Well, it comes to my mind that you should just use normal 'main' channel numbers.
If you usually watch it in HD, then mark that with main channel number. Then put another version of the channel (SD) to same number * 100 (or 1000).
15 ABC HD 1500 ABC SD
or for easy remote use, for alternative channel triple the last digit.
15 ABC HD 1555 ABC SD 16 NBC HD 1666 NBC SD
Why should you select between SD/HD? Or is there a different programme on? I'd delete the SD ones if they show the same show :)
Also I don't understand standard channel numbers. In Finland Swedish-speaking Yle FST thinks they are at position 5. No way, for me they are at 100 and beyond.
I watch channels, not channel numbers. If show is coming from "Sub", I know it is 5 in my setup. So for me channel numbers are to my own preference, not because somebody is saying so. Easies up the channel browsing as it happens in my priority preference (channel numbering), not some political aspect.
EPGSearch then records my shows from channels by keywords without channel numbers.
That is something I brought up some time ago before I ran into the sub-numbering. The Channels.conf has a way to group by provider, but right now the only place to make use of it from in the program is while in live video using the <> keys. If Provider grouping was expanded on then number reuse would be solved.
(1)Confine channel selection to the current provider group would allow reuse of numbers.
(2)Provide a way to more easly direct select providers. Remotes don't really have a useable ascii keyboard, but they could be given numbers and their own menu. Right now :@xxxx denotes a channel, :abc denotes a section/provider/whatever. Apply a version of the number system to the provider grouping. If a number is not used, it starts counting from the last used provider number. If no numbers where used, then it starts with 1 with 0 reservered for the provider guide. The new group entry would be :xx abc or even :xxabc. basicly, if the first charator/s are digits, then they are a user assigned number for that provider. If the Provders name starts with a number, then just use a space, for example ": 1 abc".
Now start a number with "*" if you are changing providers and use "*0" for the menu of providers which would work just like a menu for channels. Only when switching to another provider it would land on the first channel in that providers list.
(3)As for VDR relying on channel numbers being a problem for adding subchannel suport. This is from the manual that is packed with VDR:
A particular channel can be uniquely identified by its channel ID, which is a string that looks like this:
S19.2E-1-1089-12003-0
VDR already dosn't depend soly on channel numbers according to that.
----- Original Message ----- From: "Theunis Potgieter" theunis.potgieter@gmail.com To: "VDR Mailing List" vdr@linuxtv.org Sent: Friday, March 07, 2008 9:46 AM Subject: Re: [vdr] sub channel numbering system
So if provider 1 broadcasts a 2.1 channel and provider 2 also broadcasts a 2.1 channel and you as a vdr user can have more than 1 provider. What will the channel numbering scheme be for Provider 2? Will this introduce a bouqet in vdr?
On 3/7/08, jhall@maoz.com jhall@maoz.com wrote:
On Fri, Mar 07, 2008 at 04:57:50PM +0100, Klaus Schmidinger wrote:
On 03/07/08 16:31, VDR User wrote:
On Thu, Mar 6, 2008 at 11:37 PM, Klaus Schmidinger
On Fri, Mar 7, 2008 at 7:57 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
VDR stores channel numbers as integers. So if you want to have a numbering scheme where you have channels "between" other channels, you need to make room for these additional entries. And the only way I see to do this is to shift all numbers one digit to the left.
For example, channel 6.1 should not become 61 and force the real 61 to become something else. It's pretty obvious thats a terrible way to address the issue. The idea is to keep channel numbers in sync with the provider, not change it all around because of a personal dislike.
Yes, I understand at present VDR stores channel numbers as integers, and maybe that should change to better suit current/future needs (scaled integers?). Afterall, channel numbers aren't defined as integers by specification, that was simply a VDR design decision made long ago when this issue didn't exist.
If you are really disgusted by using "." (which -is- the most commonly accepted & used numbering sub-system) to denote sub-channels then maybe someone can brainstorm a different solution that's reasonable. Hopefully others will chime in on this although I think Timothy Lenz's previous post sums it up pretty clearly...
On Fri, 7 Mar 2008, Klaus Schmidinger wrote:
Channel numbers are *numbers*, *integer* numbers! There's a first channel, and a second one, and a third one, and they are numbered 1, 2 and 3. Now what's a "2.1" channel? Is that "ten percent more than the second channel"?
Well, integer channel numbers are used in Europe, where every subchannel are handled as a main channel.
http://en.wikipedia.org/wiki/Virtual_channel
..IIRC there were some requests for supporting LCN a long time ago, so this thread seems to be just a reminder for it.
BR, -- rofa
Like it or not Sub channels are here to stay and the "." is the standard for denoting a sub number. "vdr-1.5.15"
----- Original Message ----- From: "Klaus Schmidinger" Klaus.Schmidinger@cadsoft.de To: vdr@linuxtv.org Sent: Thursday, March 06, 2008 1:49 AM Subject: Re: [vdr] sub channel numbering system
I don't like that dot notation.
On Thu, Mar 6, 2008 at 12:20 PM, Timothy D. Lenz tlenz@vorgon.com wrote:
Like it or not Sub channels are here to stay and the "." is the standard for denoting a sub number. "vdr-1.5.15"
Can't argue with that! ;)
Timothy D. Lenz wrote:
Would it be possible to add support for the subchannel numbering system used with ATSC? Exmple of the channels in our area:
Since VDR needs to be patched for ATSC anyway, I'll consider adding sub-channel support in the next ATSC patch. But my first impression is that such a change will likely be very ugly and break many things...
However, none of the North American satellite providers have channel numbers lower than 50 (I think) so the easiest solution is to number your ATSC channels from 1 to 49. Is it really that important that your channel numbers match the broadcaster's?
On Fri, Mar 7, 2008 at 9:47 AM, Alex Lasnier alex@fepg.org wrote:
Since VDR needs to be patched for ATSC anyway, I'll consider adding sub-channel support in the next ATSC patch. But my first impression is that such a change will likely be very ugly and break many things...
However, none of the North American satellite providers have channel numbers lower than 50 (I think) so the easiest solution is to number your ATSC channels from 1 to 49. Is it really that important that your channel numbers match the broadcaster's?
Why wouldn't you want your channel numbers to match that of your provider(s)? Isn't it a better idea to have proper support for this rather then forcing channels into certain # ranges, or anything other then what they're intended to be? What possible side-effects exist in relation to EPG data?
Call me crazy, I just believe proper support for sub-channels, and multiple providers using the same channel numbers for that matter, should take priority over some hack that technically works. The use of regular integers for channel numbers has become outdated thus justifying a change to something more suitable. I don't see any good reason to think this is a bad idea, especially since the issue won't go away and only get bigger over time, no different then that of dvb-s2 and hdtv.
From what I have seen, the bigger providers start with 100. Smaller FTA
broadcasters seomtimes don't even number their channels and are assigned 0. So for many of the channels, they just given the next free number paded with the sat angle number. For OTA ATSC channels, if you live in/near a major city or between 2 major citys, you will have a lot of channels and it is much nicer if you can use the channel number assigned. Must people refer to channels by the number and it is by the number that you select the channel. If someone says there is somthing coming on channel 9 and don't sue the same numbers, then you first have to figure out what channel 9 is, then find it in your number system. The channel number has been the most common way to refer to a local channel for decades.
----- Original Message ----- From: "Alex Lasnier" alex@fepg.org To: "VDR Mailing List" vdr@linuxtv.org Sent: Friday, March 07, 2008 10:47 AM Subject: Re: [vdr] sub channel numbering system
Timothy D. Lenz wrote:
Would it be possible to add support for the subchannel numbering system
used
with ATSC? Exmple of the channels in our area:
Since VDR needs to be patched for ATSC anyway, I'll consider adding sub-channel support in the next ATSC patch. But my first impression is that such a change will likely be very ugly and break many things...
However, none of the North American satellite providers have channel numbers lower than 50 (I think) so the easiest solution is to number your ATSC channels from 1 to 49. Is it really that important that your channel numbers match the broadcaster's?
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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
On Sat, 8 Mar 2008, Udo Richter wrote:
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.
Well, if vdr would support multiple channel lists, you could name a list as "6". Then the main channel would be the first channel on the list "6.1" and subchannels from 2 to 999.
The only problem would be switching between channel lists. You could assign a special shortcut key ('#') for these lists and direct zapping to channel list "6" would simply be pressing keys '#' + '6'. It would go to the main channel 1 and only an additional '2' would be required to enter directly to a subchannel 2 ("6.2" -> '#' + '6' + '2'). You only have to make sure that the channel list "6" is the sixth entry.
BR, -- rofa
On Sat, Mar 8, 2008 at 3:05 AM, Udo Richter udo_richter@gmx.de 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.
On 03/08/08 18:47, VDR User wrote:
On Sat, Mar 8, 2008 at 3:05 AM, Udo Richter udo_richter@gmx.de 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.
Whatever you do, just keep in mind that internally channels will stay addressable by integer numbers, and it must be possible to have *one* list containig *all* channels, and each channel must be addressable by a number. If you want to have channel numbers appear as 6.1 to the user, and force them to press an extra (exotic) key when entering channel number, well, whatever. Internally you'll have to shift the numbers accordingly to make room for your sub channel numbers. And if different providers use the same channel numbers, you'll have to add proper offsets.
Klaus
Hi vdr user On Sa, Mär 08, 2008 at 09:47:01 -0800, VDR User wrote:
replace the outdated regular integers with something better suited for the task.
Outdated regular integer uy it works and it is easy to handle.
aha you can decide that this subnumbering stuff is better? Sorry vdr works great and it does what it needs to do.
BTW. vdr user where is your realname??? BR. Halim
On Sat, Mar 8, 2008 at 10:06 AM, Halim Sahin halim.sahin@t-online.de wrote:
Hi vdr user
Hi.
Outdated regular integer uy it works and it is easy to handle.
Regular integers are whole numbers. 6.1 for example, is not a whole number.
aha you can decide that this subnumbering stuff is better? Sorry vdr works great and it does what it needs to do.
VDR does work great, I agree. But it does not have perfect design and is not yet able to support all things dvb-related. This is why it's under continuous development. I would hope the idea is to make it better rather then say 'it works good enough so no bother'.
BTW. vdr user where is your realname???
My real name is Mr. VDR User... I guess my mum was able to look into the future! ;)
The remotes that come with Nexus video cards have a telephone stile num pad with both "*" and "#"
----- Original Message ----- From: "Udo Richter" udo_richter@gmx.de To: "VDR Mailing List" vdr@linuxtv.org Sent: Saturday, March 08, 2008 4:05 AM Subject: Re: [vdr] sub channel numbering system
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.
-
Alex Lasnier -
Ed Hein -
Halim Sahin -
jhall＠maoz.com -
jori.hamalainen＠teliasonera.com -
Klaus Schmidinger -
Rolf Ahrenberg -
Theunis Potgieter -
Timothy D. Lenz -
Udo Richter -
VDR User