Re: [vdr] Channels getting deleted on new scan

2018-03-12 Thread VDR User
Definitely true! We have an obsession with trying to be `different` or
non-standard. For some reason people and companies don't feel
"special" enough otherwise.

On Sun, Mar 11, 2018 at 2:31 PM, Timothy D. Lenz  wrote:
> Standards??? what's that? Only thing around here that is standard is to be
> proprietary
>
>
> On 3/11/2018 2:19 PM, Klaus Schmidinger wrote:
>>
>> On 11.03.2018 22:10, Timothy D. Lenz wrote:
>>>
>>> It turns out that both stations are owned by the same company. I have
>>> sent KGUN9 a second email about the conflict and reported it to the FCC as
>>> interference because they interfering with each other. Looking at this site:
>>> https://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf
>>>
>>> I found this near the end:
>>>
>>> "RID
>>> Radio ID. Typical 0. Can be used to differentiate between channels having
>>> the same SID, NID and TID."
>>
>>
>> Introducing the RID was a pretty ugly workaround.
>> I suggest not to use it and rather try and find somebody at the
>> broadcaster who knows his stuff ;-).
>>
>> My guess is they simply copy/pasted the configuration
>> for these channels and didn't bother adhering to standards.
>>
>> Klaus
>>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Channels getting deleted on new scan

2018-03-11 Thread Timothy D. Lenz
Standards??? what's that? Only thing around here that is standard is to 
be proprietary


On 3/11/2018 2:19 PM, Klaus Schmidinger wrote:

On 11.03.2018 22:10, Timothy D. Lenz wrote:
It turns out that both stations are owned by the same company. I have 
sent KGUN9 a second email about the conflict and reported it to the 
FCC as interference because they interfering with each other. Looking 
at this site: 
https://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf


I found this near the end:

"RID
Radio ID. Typical 0. Can be used to differentiate between channels 
having the same SID, NID and TID."


Introducing the RID was a pretty ugly workaround.
I suggest not to use it and rather try and find somebody at the
broadcaster who knows his stuff ;-).

My guess is they simply copy/pasted the configuration
for these channels and didn't bother adhering to standards.

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Channels getting deleted on new scan

2018-03-11 Thread Klaus Schmidinger

On 11.03.2018 22:10, Timothy D. Lenz wrote:

It turns out that both stations are owned by the same company. I have sent 
KGUN9 a second email about the conflict and reported it to the FCC as 
interference because they interfering with each other. Looking at this site: 
https://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf

I found this near the end:

"RID
Radio ID. Typical 0. Can be used to differentiate between channels having the same 
SID, NID and TID."


Introducing the RID was a pretty ugly workaround.
I suggest not to use it and rather try and find somebody at the
broadcaster who knows his stuff ;-).

My guess is they simply copy/pasted the configuration
for these channels and didn't bother adhering to standards.

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Channels getting deleted on new scan

2018-03-11 Thread Timothy D. Lenz
It turns out that both stations are owned by the same company. I have 
sent KGUN9 a second email about the conflict and reported it to the FCC 
as interference because they interfering with each other. Looking at 
this site: https://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf


I found this near the end:

"RID
Radio ID. Typical 0. Can be used to differentiate between channels 
having the same SID, NID and TID."


For some reason or another, I had to set all ATSC RID's to 0 for 
everything to work.  I changed them to the entries in my conf but it 
doesn't seem to be working. Channels are not being deleted, but 
something is still wrong. Might be a problem with vdr admin.  I had to 
add entries for a sat broadcast which (is scrambed) as 90 or 91 would 
not show. letting it set for a bit, looks like now I am seeing 581 guide 
data for 91. :(


On 3/10/2018 1:30 AM, Klaus Schmidinger wrote:

On 10.03.2018 01:21, Torgeir Veimo wrote:

Isn't there a plugin that can change such data before it gets processed?


The problem is that these are *duplicate* channels - they can't be in the
channel list to begin with. They need to have different Transport Stream 
Ids.
And as wen can see from Timothy's old channel list, they used to have 
these.

So somebody just screwed up!

Klaus

On 10 March 2018 at 08:47, Timothy D. Lenz > wrote:


    Wel, it gets better. Tonight I see VDR is grabbing guide data 
for 9x and using it for 58.x. So 58.x data is now being lost. g



    On 3/9/2018 2:29 AM, Klaus Schmidinger wrote:

    On 08.03.2018 22:38, Klaus Schmidinger wrote:

    On 08.03.2018 22:13, Timothy D. Lenz wrote:

    I was hoping it was something simple I could fix in 
the conf. I haven't worked on it or in linux in a long time and don't 
have the free time to figure it all out again. I'll have to look at 
this some other time. I am in the U.S. and these are ATA channels. 
They each have their own
    freq. and my guess is that they can use what ever 
numbers they want since they are on there own freq which they bought.



    Well, it's funny though that they use exactly the same IDs 
;-).


    Sure they can do whatever they want, but there are a few 
basic rules that
    should be followed in order to guarantee a reasonable 
coexistance. One of
    them is that channels that are broadcast in the same area 
(like from the
    same terrestrial transmitter, on the same cable or the 
same satellite)
    should use unique IDs, even if they are on different 
transponders. One
    of these IDs is the "transport stream id", which in your 
case is 207 for

    both channels. This should be different.


    For testing I added your new channel list to my channels.conf.
    Here's what my VDR reported upon startup:

    Mar  9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf
    Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0 

    Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
    Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0


    With your old list I get no such log entries. So I guess 
somebody messed up

    with the TIDs, and the problem should be fixed there.

    Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Channels getting deleted on new scan

2018-03-10 Thread Timothy D. Lenz
I told a neighbor about this who used to work in Broadcast many years 
ago locally. And back then when they were just setting up the digital 
gear for the switch over, she said the engineers they where bringing in 
were not engineers and had little clue what they were doing. It's only 
gotten worse.


She did hear something about CW and KGUN local stations now being owned 
by the same company.


Another problem is, I built this using an Asus motherboard. I will never 
buy anything from them again. I have had a number of Asus boards and and 
all have had problems. All where unstable and VERY picky about what 
cards you used. Swap the motherboard and nothing else and all the 
strange problems would go away. One of the problems I have is that when 
I try to run the ATSC plugin's channel scan, 80-90% of the time it 
crashes VDR and no one could figure out why. Sometimes it works just 
fine. other times no. And it looks like I won't be getting any more 
scans for awhile because it is back to crashing. Maybe some day I'll get 
the time and money and time to build another system.. someday...


On 3/10/2018 1:30 AM, Klaus Schmidinger wrote:

On 10.03.2018 01:21, Torgeir Veimo wrote:

Isn't there a plugin that can change such data before it gets processed?


The problem is that these are *duplicate* channels - they can't be in the
channel list to begin with. They need to have different Transport Stream 
Ids.
And as wen can see from Timothy's old channel list, they used to have 
these.

So somebody just screwed up!

Klaus

On 10 March 2018 at 08:47, Timothy D. Lenz > wrote:


    Wel, it gets better. Tonight I see VDR is grabbing guide data 
for 9x and using it for 58.x. So 58.x data is now being lost. g



    On 3/9/2018 2:29 AM, Klaus Schmidinger wrote:

    On 08.03.2018 22:38, Klaus Schmidinger wrote:

    On 08.03.2018 22:13, Timothy D. Lenz wrote:

    I was hoping it was something simple I could fix in 
the conf. I haven't worked on it or in linux in a long time and don't 
have the free time to figure it all out again. I'll have to look at 
this some other time. I am in the U.S. and these are ATA channels. 
They each have their own
    freq. and my guess is that they can use what ever 
numbers they want since they are on there own freq which they bought.



    Well, it's funny though that they use exactly the same IDs 
;-).


    Sure they can do whatever they want, but there are a few 
basic rules that
    should be followed in order to guarantee a reasonable 
coexistance. One of
    them is that channels that are broadcast in the same area 
(like from the
    same terrestrial transmitter, on the same cable or the 
same satellite)
    should use unique IDs, even if they are on different 
transponders. One
    of these IDs is the "transport stream id", which in your 
case is 207 for

    both channels. This should be different.


    For testing I added your new channel list to my channels.conf.
    Here's what my VDR reported upon startup:

    Mar  9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf
    Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0 

    Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
    Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0


    With your old list I get no such log entries. So I guess 
somebody messed up

    with the TIDs, and the problem should be fixed there.

    Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Channels getting deleted on new scan

2018-03-10 Thread Klaus Schmidinger

On 10.03.2018 01:21, Torgeir Veimo wrote:

Isn't there a plugin that can change such data before it gets processed?


The problem is that these are *duplicate* channels - they can't be in the
channel list to begin with. They need to have different Transport Stream Ids.
And as wen can see from Timothy's old channel list, they used to have these.
So somebody just screwed up!

Klaus


On 10 March 2018 at 08:47, Timothy D. Lenz mailto:tl...@vorgon.com>> wrote:

Wel, it gets better. Tonight I see VDR is grabbing guide data for 9x 
and using it for 58.x. So 58.x data is now being lost. g


On 3/9/2018 2:29 AM, Klaus Schmidinger wrote:

On 08.03.2018 22:38, Klaus Schmidinger wrote:

On 08.03.2018 22:13, Timothy D. Lenz wrote:

I was hoping it was something simple I could fix in the conf. I 
haven't worked on it or in linux in a long time and don't have the free time to 
figure it all out again. I'll have to look at this some other time. I am in the 
U.S. and these are ATA channels. They each have their own
freq. and my guess is that they can use what ever numbers they 
want since they are on there own freq which they bought.


Well, it's funny though that they use exactly the same IDs ;-).

Sure they can do whatever they want, but there are a few basic 
rules that
should be followed in order to guarantee a reasonable coexistance. 
One of
them is that channels that are broadcast in the same area (like 
from the
same terrestrial transmitter, on the same cable or the same 
satellite)
should use unique IDs, even if they are on different transponders. 
One
of these IDs is the "transport stream id", which in your case is 
207 for
both channels. This should be different.


For testing I added your new channel list to my channels.conf.
Here's what my VDR reported upon startup:

Mar  9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0

With your old list I get no such log entries. So I guess somebody 
messed up
with the TIDs, and the problem should be fixed there.

Klaus


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Channels getting deleted on new scan

2018-03-09 Thread Torgeir Veimo
Isn't there a plugin that can change such data before it gets processed?

On 10 March 2018 at 08:47, Timothy D. Lenz  wrote:

> Wel, it gets better. Tonight I see VDR is grabbing guide data for 9x
> and using it for 58.x. So 58.x data is now being lost. g
>
>
> On 3/9/2018 2:29 AM, Klaus Schmidinger wrote:
>
>> On 08.03.2018 22:38, Klaus Schmidinger wrote:
>>
>>> On 08.03.2018 22:13, Timothy D. Lenz wrote:
>>>
 I was hoping it was something simple I could fix in the conf. I haven't
 worked on it or in linux in a long time and don't have the free time to
 figure it all out again. I'll have to look at this some other time. I am in
 the U.S. and these are ATA channels. They each have their own freq. and my
 guess is that they can use what ever numbers they want since they are on
 there own freq which they bought.

>>>
>>> Well, it's funny though that they use exactly the same IDs ;-).
>>>
>>> Sure they can do whatever they want, but there are a few basic rules that
>>> should be followed in order to guarantee a reasonable coexistance. One of
>>> them is that channels that are broadcast in the same area (like from the
>>> same terrestrial transmitter, on the same cable or the same satellite)
>>> should use unique IDs, even if they are on different transponders. One
>>> of these IDs is the "transport stream id", which in your case is 207 for
>>> both channels. This should be different.
>>>
>>
>> For testing I added your new channel list to my channels.conf.
>> Here's what my VDR reported upon startup:
>>
>> Mar  9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf
>> Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel
>> KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0
>>
>> Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel
>> LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
>> Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel
>> ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0
>>
>> With your old list I get no such log entries. So I guess somebody messed
>> up
>> with the TIDs, and the problem should be fixed there.
>>
>> Klaus
>>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>



-- 
-Tor
___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Channels getting deleted on new scan

2018-03-09 Thread Timothy D. Lenz
Wel, it gets better. Tonight I see VDR is grabbing guide data for 9x 
and using it for 58.x. So 58.x data is now being lost. g


On 3/9/2018 2:29 AM, Klaus Schmidinger wrote:

On 08.03.2018 22:38, Klaus Schmidinger wrote:

On 08.03.2018 22:13, Timothy D. Lenz wrote:
I was hoping it was something simple I could fix in the conf. I 
haven't worked on it or in linux in a long time and don't have the 
free time to figure it all out again. I'll have to look at this some 
other time. I am in the U.S. and these are ATA channels. They each 
have their own freq. and my guess is that they can use what ever 
numbers they want since they are on there own freq which they bought.


Well, it's funny though that they use exactly the same IDs ;-).

Sure they can do whatever they want, but there are a few basic rules that
should be followed in order to guarantee a reasonable coexistance. One of
them is that channels that are broadcast in the same area (like from the
same terrestrial transmitter, on the same cable or the same satellite)
should use unique IDs, even if they are on different transponders. One
of these IDs is the "transport stream id", which in your case is 207 for
both channels. This should be different.


For testing I added your new channel list to my channels.conf.
Here's what my VDR reported upon startup:

Mar  9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0 

Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0


With your old list I get no such log entries. So I guess somebody messed up
with the TIDs, and the problem should be fixed there.

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Channels getting deleted on new scan

2018-03-09 Thread Timothy D. Lenz
I sent an email to KGUN and if they don't fix the conflict right away, I 
guess I'll have to make a complaint to the FCC, not that it will do much 
good.


On 3/9/2018 2:29 AM, Klaus Schmidinger wrote:

On 08.03.2018 22:38, Klaus Schmidinger wrote:

On 08.03.2018 22:13, Timothy D. Lenz wrote:
I was hoping it was something simple I could fix in the conf. I 
haven't worked on it or in linux in a long time and don't have the 
free time to figure it all out again. I'll have to look at this some 
other time. I am in the U.S. and these are ATA channels. They each 
have their own freq. and my guess is that they can use what ever 
numbers they want since they are on there own freq which they bought.


Well, it's funny though that they use exactly the same IDs ;-).

Sure they can do whatever they want, but there are a few basic rules that
should be followed in order to guarantee a reasonable coexistance. One of
them is that channels that are broadcast in the same area (like from the
same terrestrial transmitter, on the same cable or the same satellite)
should use unique IDs, even if they are on different transponders. One
of these IDs is the "transport stream id", which in your case is 207 for
both channels. This should be different.


For testing I added your new channel list to my channels.conf.
Here's what my VDR reported upon startup:

Mar  9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0 

Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0


With your old list I get no such log entries. So I guess somebody messed up
with the TIDs, and the problem should be fixed there.

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Channels getting deleted on new scan

2018-03-09 Thread Klaus Schmidinger

On 08.03.2018 22:38, Klaus Schmidinger wrote:

On 08.03.2018 22:13, Timothy D. Lenz wrote:
I was hoping it was something simple I could fix in the conf. I haven't worked on it or in linux in a long time and don't have the free time to figure it all out again. I'll have to look at this some other time. I am in the U.S. and these are ATA channels. They each have their own freq. and my 
guess is that they can use what ever numbers they want since they are on there own freq which they bought.


Well, it's funny though that they use exactly the same IDs ;-).

Sure they can do whatever they want, but there are a few basic rules that
should be followed in order to guarantee a reasonable coexistance. One of
them is that channels that are broadcast in the same area (like from the
same terrestrial transmitter, on the same cable or the same satellite)
should use unique IDs, even if they are on different transponders. One
of these IDs is the "transport stream id", which in your case is 207 for
both channels. This should be different.


For testing I added your new channel list to my channels.conf.
Here's what my VDR reported upon startup:

Mar  9 10:21:46 raspi4 vdr: [3134] loading ../cfg/channels.conf
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
Mar  9 10:21:46 raspi4 vdr: [3134] deleting duplicate channel 
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0

With your old list I get no such log entries. So I guess somebody messed up
with the TIDs, and the problem should be fixed there.

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Channels getting deleted on new scan

2018-03-08 Thread Klaus Schmidinger

On 08.03.2018 22:13, Timothy D. Lenz wrote:
I was hoping it was something simple I could fix in the conf. I haven't worked on it or in linux in a long time and don't have the free time to figure it all out again. I'll have to look at this some other time. I am in the U.S. and these are ATA channels. They each have their own freq. and my guess 
is that they can use what ever numbers they want since they are on there own freq which they bought.


Well, it's funny though that they use exactly the same IDs ;-).

Sure they can do whatever they want, but there are a few basic rules that
should be followed in order to guarantee a reasonable coexistance. One of
them is that channels that are broadcast in the same area (like from the
same terrestrial transmitter, on the same cable or the same satellite)
should use unique IDs, even if they are on different transponders. One
of these IDs is the "transport stream id", which in your case is 207 for
both channels. This should be different.

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Channels getting deleted on new scan

2018-03-08 Thread Timothy D. Lenz
I was hoping it was something simple I could fix in the conf. I haven't 
worked on it or in linux in a long time and don't have the free time to 
figure it all out again. I'll have to look at this some other time. I am 
in the U.S. and these are ATA channels. They each have their own freq. 
and my guess is that they can use what ever numbers they want since they 
are on there own freq which they bought.


On 3/8/2018 2:51 AM, Klaus Schmidinger wrote:

On 08.03.2018 03:36, Timothy D. Lenz wrote:
Haven't used the list in awhile I I think my first reply went to the 
wrong address. So redoing plus adding some info.


91 is 9.1 KGUN which is the local for ABC Broadcast Network A National 
Network. The other 9.x channels are assorted small stations. 581 or 
58.1 is CW, Another big network. They are very different. 58.2 is some 
spanish channel using sub channel space.


And here is the channel.conf provided by ATSCEPG plugin:

...
:@91
KGUN-HD,KGUN-HD:189028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:207:0 


...
:@581
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:207:0 


...


The four rightmost numbers are SID:NID:TID:RID. These values are used to 
compose
the "channel id". So these channels have exactly the same "id", and thus 
are
"the same" to VDR. Since you are saying that these are in fact very 
different

channels (presumably with different EPG), it is just plain wrong to use the
same values for NID, TID and SID (RID=0 is irrelevant). The question is: 
who

does it wrong? If these values are broadcast as such in the SDT, it´s the
broadcaster´s fault. If they are correct (i.e. different for each channel)
in the SDT, it´s the ATSCEPG plugin´s fault.

To see which values are broadcast, you can set

static bool DebugSdt = true;

in sdt.c.

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Channels getting deleted on new scan

2018-03-08 Thread Klaus Schmidinger

On 08.03.2018 03:36, Timothy D. Lenz wrote:

Haven't used the list in awhile I I think my first reply went to the wrong 
address. So redoing plus adding some info.

91 is 9.1 KGUN which is the local for ABC Broadcast Network A National Network. 
The other 9.x channels are assorted small stations. 581 or 58.1 is CW, Another 
big network. They are very different. 58.2 is some spanish channel using sub 
channel space.

And here is the channel.conf provided by ATSCEPG plugin:

...
:@91
KGUN-HD,KGUN-HD:189028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:207:0
...
:@581
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:207:0
...


The four rightmost numbers are SID:NID:TID:RID. These values are used to compose
the "channel id". So these channels have exactly the same "id", and thus are
"the same" to VDR. Since you are saying that these are in fact very different
channels (presumably with different EPG), it is just plain wrong to use the
same values for NID, TID and SID (RID=0 is irrelevant). The question is: who
does it wrong? If these values are broadcast as such in the SDT, it´s the
broadcaster´s fault. If they are correct (i.e. different for each channel)
in the SDT, it´s the ATSCEPG plugin´s fault.

To see which values are broadcast, you can set

static bool DebugSdt = true;

in sdt.c.

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] Channels getting deleted on new scan

2018-03-07 Thread Timothy D. Lenz
Haven't used the list in awhile I I think my first reply went to the 
wrong address. So redoing plus adding some info.


91 is 9.1 KGUN which is the local for ABC Broadcast Network A National 
Network. The other 9.x channels are assorted small stations. 581 or 58.1 
is CW, Another big network. They are very different. 58.2 is some 
spanish channel using sub channel space.


And here is the channel.conf provided by ATSCEPG plugin:

:@41
KVOA,KVOA:69028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:1:0:211:0
:@42
COZI-TV,COZI-TV:69028615:M10:A:0:65=2:0;68=eng@106:0:0:2:0:211:0
:@43
ESCAPE,ESCAPE:69028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:211:0
:@91
KGUN-HD,KGUN-HD:189028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:207:0
:@92
LAFF,LAFF:189028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
:@93
Antenna,Antenna:189028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0
:@94
Bounce,Bounce:189028615:M10:A:0:97=2:0;100=eng@106:0:0:6:0:207:0
:@131
KOLD DT,KOLD DT:213028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:219:0
:@132
Me TV,Me TV:213028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:219:0
:@133
Grit,Grit:213028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:219:0
:@141
KUDF-HD,KUDF-HD:473028615:M10:A:0:49=2:0;52=spa@106:0:0:1:0:8263:0
:@142
Telemax,Telemax:473028615:M10:A:0:65=2:0;68=spa@106:0:0:2:0:8263:0
:@143
GNTVLat,GNTVLat:473028615:M10:A:0:81=2:0;84=spa@106:0:0:3:0:8263:0
:@144
GoodNws,GoodNws:473028615:M10:A:0:97=2:0;100=eng@106:0:0:4:0:8263:0
:@91
KGUN-HD,KGUN-HD:485028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:207:0
:@92
LAFF,LAFF:485028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
:@93
Antenna,Antenna:485028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0
:@94
Bounce,Bounce:485028615:M10:A:0:97=2:0;100=eng@106:0:0:6:0:207:0
:@341
KFTU-CD,KFTU-CD:497028615:M10:A:0:49=2:0;52=spa@106,53=mul@106:0:0:1:0:7037:0
:@342
KUVE-HD,KUVE-HD:497028615:M10:A:0:65=2:0;68=spa@106,69=mul@106:0:0:2:0:7037:0
:@181
KTTU-HD,KTTU-HD:503028615:M10:A:0:49=2:0;52=eng@106:0:0:1:0:221:0
:@182
Estrell,Estrell:503028615:M10:A:0:65=2:0;68=spa@106:0:0:2:0:221:0
:@183
H and I,H and I:503028615:M10:A:0:81=2:0;83=eng@106:0:0:3:0:221:0
:@211
HSN,K21CX-D:515028615:M10:A:0:481=2:0;482=eng@106:0:0:1:0:1:0
:@41
KVOA,KVOA:527028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:1:0:211:0
:@42
COZI-TV,COZI-TV:527028615:M10:A:0:65=2:0;68=eng@106:0:0:2:0:211:0
:@43
ESCAPE,ESCAPE:527028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:211:0
:@111
KMSB-HD,KMSB-HD:539028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:1:0:217:0
:@112
Movies,Movies:539028615:M10:A:0:65=2:0;68=eng@106:0:0:2:0:217:0
:@113
Justice,Justice:539028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:217:0
:@114
Quest,Quest:539028615:M10:A:0:97=2:0;100=eng@106:0:0:4:0:217:0
:@271
PBS HD,PBS HD:557028615:M10:A:0:49=2:0;52=eng@106,56=@106:0:0:1:0:223:0
:@272
KIDS,KIDS:557028615:M10:A:0:65=2:0;68=eng@106,72=@106:0:0:2:0:223:0
:@273
PBS 6+,PBS 6+:557028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:223:0
:@61
PBS HD,PBS HD:569028615:M10:A:0:49=2:0;52=eng@106,56=eng@106:0:0:1:0:213:0
:@62
KIDS,KIDS:569028615:M10:A:0:65=2:0;68=spa@106,72=spa@106:0:0:2:0:213:0
:@63
PBS 6+,PBS 6+:569028615:M10:A:0:81=2:0;84=eng@106,88=eng@106:0:0:3:0:213:0
:@131
KOLD DT,KOLD DT:581028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:219:0
:@132
Me TV,Me TV:581028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:219:0
:@133
Grit,Grit:581028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:219:0
:@401
KHRR-DT,KHRR-DT:629028615:M10:A:0:49=2:0;52=spa@106:0:0:3:0:225:0
:@402
Exitos ,Exitos :629028615:M10:A:0:65=2:0;68=spa@106:0:0:4:0:225:0
:@403
ION,ION:629028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:225:0
:@421
KUVE-CD,KUVE-CD:641028615:M10:A:0:49=2:0;52=spa@106:0:0:1:0:9307:0
:@422
KFTU,KFTU:641028615:M10:A:0:65=2:0;68=spa@106,69=mul@106:0:0:2:0:9307:0
:@423
KUVE-D3,KUVE-D3:641028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:9307:0
:@424
KUVE-D4,KUVE-D4:641028615:M10:A:0:97=2:0;100=eng@106:0:0:4:0:9307:0
:@581
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=spa@106:0:0:3:0:207:0
:@582
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
:@583
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0
:@461
KUVE-DT,KUVE-DT:665028615:M10:A:0:49=2:0;52=spa@106,53=mul@106:0:0:1:0:179:0
:@462
KFTU-HD,KFTU-HD:665028615:M10:A:0:65=2:0;68=spa@106,69=mul@106:0:0:2:0:179:0
:@463
getTV,getTV:665028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:179:0
:@464
ESCAPE,ESCAPE:665028615:M10:A:0:97=2:0;100=eng@106:0:0:4:0:179:0


On 3/7/2018 3:04 AM, Klaus Schmidinger wrote:

On 07.03.2018 00:04, Timothy D. Lenz wrote:

So I'm using an old version of VDR, looks like 1.7.15 with the ATSC
plugin. Just don't have the time to update everything. I noticed that
the 9x locals stopped getting guide data. I did a new scan and the new
list worked for 9x but would wipe 58x channels. comparing them, they
changed the next to last field entry for 9x from 215 to 207 which is the
same as for the 58x. That's the only reason I see. I can switch to 9x
...


Using the same NID, TID and SID makes these channels look like "the s

Re: [vdr] Channels getting deleted on new scan

2018-03-07 Thread Klaus Schmidinger

On 07.03.2018 00:04, Timothy D. Lenz wrote:

So I'm using an old version of VDR, looks like 1.7.15 with the ATSC
plugin. Just don't have the time to update everything. I noticed that
the 9x locals stopped getting guide data. I did a new scan and the new
list worked for 9x but would wipe 58x channels. comparing them, they
changed the next to last field entry for 9x from 215 to 207 which is the
same as for the 58x. That's the only reason I see. I can switch to 9x
...


Using the same NID, TID and SID makes these channels look like "the same"
to VDR, and it only assigns the schedule to teh first one it finds in its
channel list.

Are channels 91 and 581 carrying the same content, and this supposed to
have the same EPG?

Klaus

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[vdr] Channels getting deleted on new scan

2018-03-06 Thread Timothy D. Lenz

So I'm using an old version of VDR, looks like 1.7.15 with the ATSC
plugin. Just don't have the time to update everything. I noticed that
the 9x locals stopped getting guide data. I did a new scan and the new
list worked for 9x but would wipe 58x channels. comparing them, they
changed the next to last field entry for 9x from 215 to 207 which is the
same as for the 58x. That's the only reason I see. I can switch to 9x

---
:@91
KGUN-DT,KGUN-DT:189028615:M10:A:0:49=2:0;53=esl@106,52=eng@106:0:0:3:0:215:0
:@92
Laff   ,Laff   :189028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:215:0
:@93
Antenna,Antenna:189028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:215:0
---
:@581
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0
:@582
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
:@583
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0
---

Old List:

:@41
KVOA,KVOA:527028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:1:0:211:0
:@42
COZI-TV,COZI-TV:527028615:M10:A:0:65=2:0;68=eng@106:0:0:2:0:211:0
:@61
PBS HD,PBS HD:569028615:M10:A:0:49=2:0;52=eng@106,56=eng@106:0:0:1:0:213:0
:@62
V-Me,V-Me:569028615:M10:A:0:65=2:0;68=eng@106,72=eng@106:0:0:2:0:213:0
:@63
ReadyTV,ReadyTV:569028615:M10:A:0:81=2:0;84=eng@106,88=eng@106:0:0:3:0:213:0
:@91
KGUN-DT,KGUN-DT:189028615:M10:A:0:49=2:0;53=esl@106,52=eng@106:0:0:3:0:215:0
:@92
Laff   ,Laff   :189028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:215:0
:@93
Antenna,Antenna:189028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:215:0
:@111
KMSB-HD,KMSB-HD:539028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:1:0:217:0
:@112
Movies,Movies:539028615:M10:A:0:65=2:0;68=eng@106:0:0:2:0:217:0
:@113
Justice,Justice:539028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:217:0
:@131
KOLD DT,KOLD DT:581028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:219:0
:@132
Me TV,Me TV:581028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:219:0
:@133
Grit,Grit:581028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:219:0
:@141
KUDF-LP,KUDF-LP:473028615:M10:A:0:81=2:0;84=esl@106:0:0:3:0:8263:0
:@181
KTTU-HD,KTTU-HD:503028615:M10:A:0:49=2:0;52=eng@106:0:0:1:0:221:0
:@182
Estrell,Estrell:503028615:M10:A:0:65=2:0;68=esl@106:0:0:2:0:221:0
:@211
HSN,K21CX-D:515028615:M10:A:0:481=2:0;482=eng@106:0:0:1:0:1:0
:@271
PBS HD,PBS HD:557028615:M10:A:0:49=2:0;52=eng@106,56=eng@106:0:0:1:0:223:0
:@272
KIDS,KIDS:557028615:M10:A:0:65=2:0;68=eng@106,72=eng@106:0:0:2:0:223:0
:@273
WORLD,WORLD:557028615:M10:A:0:81=2:0;84=eng@106,88=eng@106:0:0:3:0:223:0
:@341
KFTU-CD,KFTU-CD:497028615:M10:A:0:49=2:0;52=esl@106,53=mul@106:0:0:1:0:7037:0
:@342
KUVE-HD,KUVE-HD:497028615:M10:A:0:65=2:0;68=esl@106,69=mul@106:0:0:2:0:7037:0
:@401
KHRR-DT,KHRR-DT:629028615:M10:A:0:49=2:0;52=esl@106:0:0:3:0:225:0
:@402
Exitos ,Exitos :629028615:M10:A:0:65=2:0;68=esl@106:0:0:4:0:225:0
:@403
ION,ION:629028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:225:0
:@421
KUVE-CD,KUVE-CD:641028615:M10:A:0:49=2:0;52=esl@106,53=mul@106:0:0:1:0:9307:0
:@422
KFTU,KFTU:641028615:M10:A:0:65=2:0;68=esl@106,69=mul@106:0:0:2:0:9307:0
:@423
KUVE-D3,KUVE-D3:641028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:9307:0
:@424
KUVE-D4,KUVE-D4:641028615:M10:A:0:97=2:0;100=eng@106:0:0:4:0:9307:0
:@461
KUVE-DT,KUVE-DT:665028615:M10:A:0:49=2:0;52=esl@106,53=mul@106:0:0:1:0:179:0
:@462
KFTU-HD,KFTU-HD:665028615:M10:A:0:65=2:0;68=esl@106,69=mul@106:0:0:2:0:179:0
:@463
getTV,getTV:665028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:179:0
:@464
ESCAPE,ESCAPE:665028615:M10:A:0:97=2:0;100=eng@106:0:0:4:0:179:0
:@581
KWBA-HD,KWBA-HD:653028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:207:0
:@582
LATV,LATV:653028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
:@583
ThisTV,ThisTV:653028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0

---

New List:

:@41
KVOA,KVOA:527028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:1:0:211:0
:@42
COZI-TV,COZI-TV:527028615:M10:A:0:65=2:0;68=eng@106:0:0:2:0:211:0
:@43
ESCAPE,ESCAPE:527028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:211:0
:@61
PBS HD,PBS HD:569028615:M10:A:0:49=2:0;52=eng@106,56=eng@106:0:0:1:0:213:0
:@62
KIDS,KIDS:569028615:M10:A:0:65=2:0;68=eng@106,72=eng@106:0:0:2:0:213:0
:@63
PBS 6+,PBS 6+:569028615:M10:A:0:81=2:0;84=eng@106,88=eng@106:0:0:3:0:213:0
:@91
KGUN-HD,KGUN-HD:189028615:M10:A:0:49=2:0;53=esl@106,52=eng@106:0:0:3:0:207:0
:@92
LAFF,LAFF:189028615:M10:A:0:65=2:0;68=eng@106:0:0:4:0:207:0
:@93
Antenna,Antenna:189028615:M10:A:0:81=2:0;84=eng@106:0:0:5:0:207:0
:@94
Bounce,Bounce:189028615:M10:A:0:97=2:0;100=eng@106:0:0:6:0:207:0
:@111
KMSB-HD,KMSB-HD:539028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:1:0:217:0
:@112
Movies,Movies:539028615:M10:A:0:65=2:0;68=eng@106:0:0:2:0:217:0
:@113
Justice,Justice:539028615:M10:A:0:81=2:0;84=eng@106:0:0:3:0:217:0
:@114
Quest,Quest:539028615:M10:A:0:97=2:0;100=eng@106:0:0:4:0:217:0
:@131
KOLD DT,KOLD DT:581028615:M10:A:0:49=2:0;52=eng@106,53=esl@106:0:0:3:0:219:0
:@132
Me