Bug#788100: The bug is still there on new version

[Apostolos Kefalas]

On Sun, 14 Jun 2015 20:59:26 +0200 Eric Valette 
wrote:
> On 14/06/2015 11:49, Eric Valette wrote:
> > On 14/06/2015 11:35, Tobias Grimm wrote:
> >
> >> I'm afraid there's nothing I can do right now. Upstream probably
will not
> >> create a workaround and I can't do this either, because I have no
way to
> >> test this.
> >
> > I understand this. Thansk for your help anyway. Will see if I can
> > workaround something myself.
> 
> I cooked the attached diff myself and it seems to  fix nearly my 
> problem. Basically, in parser-nit if the tn.frequency is invalid I
use 
> the current_tp->frequency.
> 
> Doing that it scan the frequency range, find the transponders, but
for 
> some reason, it only output the last one (correctly BTW). I suspect
this 
> is because all the Network id and ts stream id looks the same on all 
> transponders which is also buggy or there is another bug somewhere
in 
> finding the correct nit location.
> 
> Any further advice appreciated.
> 
> -- eric
> 

1734c1734
  parse_nit(buf, section_length, table_id, table_id_ext, s-
flags);
---
 //parse_nit(buf, section_length, table_id, table_id_ext, s-
flags);
 
Do not parse the stupid (tv broadcast engineer who configured the) NIT
table seems to work fine with the VLC playlist I like to create.

Regards
Apostolos


signature.asc
Description: This is a digitally signed message part

Bug#788100: The bug is still there on new version

[Apostolos Kefalas]

On Sun, 14 Jun 2015 10:42:08 +0200 Eric Valette 
wrote:
> On 14/06/2015 00:25, Tobias Grimm wrote:
> > Ok. I digged a bit deeper into to this. For some reason your local
> > broadcaster sends 0x for the centre_frequency field of the
> > terrestrial delivery system descriptor in the NIT (Network
Information Table).
> >
> > I've contacted the upstream author, but he doesn't think, it should
be
> > fixed in w_scan if the broadcaster doesn't send the correct
transponder
> > data as defined by the ETSI specifications.
> >
> > You wrote, that this has been working before. Can you name the
version of
> > w_scan which worked for you?
> 
> 
> I dunno. About a year ago. And may its only the braodcast signal
that 
> has changed. But this is the national france TNT system so you have 
> quite some people impacted.
> 
> What should be fixed at least is that we shall not end up with a 
> frequency that is not tunable and return an error that has some
meaning 
> no? And do not change the trasnponder in that case.
> 
> 
> -- eric
> 

We have the exact same problem here in Greece. It would be great to
ignore NIT frequency if it is 0xF


Thanks
Apostolos
> 

Bug#788100: The bug is still there on new version

[Tobias Grimm]

The transponder data in the NIT are not DVB-T2 specific. See ETSI EN 300 468.

Other broadcasters obviously do it right and w_scan works fine. I have no
idea why your local TNT broadcasting station does not put the correct
frequencies into the transponder data.

I'm afraid there's nothing I can do right now. Upstream probably will not
create a workaround and I can't do this either, because I have no way to
test this.

Tobias


On 14.06.2015 10:51, Eric Valette wrote:

 On 14/06/2015 10:42, Eric Valette wrote:

 On 14/06/2015 00:25, Tobias Grimm wrote:
 Ok. I digged a bit deeper into to this. For some reason your local
 broadcaster sends 0x for the centre_frequency field of the
 terrestrial delivery system descriptor in the NIT (Network Information
 Table).
 
 
 In addition, I find this in the ETSI DVB T2 specification but so far, in
 FRANCE there is no DVB T2 braodcast.
 
 -- eric
 
 
 
 
 
 
 




signature.asc
Description: OpenPGP digital signature

Bug#788100: The bug is still there on new version

[Eric Valette]

On 14/06/2015 00:25, Tobias Grimm wrote:


You wrote, that this has been working before. Can you name the version of
w_scan which worked for you?


FYI: I tested an old 2012 version (wheezy) and the bug is still there so 
it should be the broadcast signal that changed not the code.


-- eric


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#788100: The bug is still there on new version

[Eric Valette]

On 14/06/2015 10:42, Eric Valette wrote:

On 14/06/2015 00:25, Tobias Grimm wrote:

Ok. I digged a bit deeper into to this. For some reason your local
broadcaster sends 0x for the centre_frequency field of the
terrestrial delivery system descriptor in the NIT (Network Information
Table).



In addition, I find this in the ETSI DVB T2 specification but so far, in 
FRANCE there is no DVB T2 braodcast.


-- eric


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#788100: The bug is still there on new version

[Eric Valette]

On 14/06/2015 00:25, Tobias Grimm wrote:

Ok. I digged a bit deeper into to this. For some reason your local
broadcaster sends 0x for the centre_frequency field of the
terrestrial delivery system descriptor in the NIT (Network Information Table).

I've contacted the upstream author, but he doesn't think, it should be
fixed in w_scan if the broadcaster doesn't send the correct transponder
data as defined by the ETSI specifications.

You wrote, that this has been working before. Can you name the version of
w_scan which worked for you?



I dunno. About a year ago. And may its only the braodcast signal that 
has changed. But this is the national france TNT system so you have 
quite some people impacted.


What should be fixed at least is that we shall not end up with a 
frequency that is not tunable and return an error that has some meaning 
no? And do not change the trasnponder in that case.



-- eric


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#788100: The bug is still there on new version

[Tobias Grimm]

Ok. I digged a bit deeper into to this. For some reason your local
broadcaster sends 0x for the centre_frequency field of the
terrestrial delivery system descriptor in the NIT (Network Information Table).

I've contacted the upstream author, but he doesn't think, it should be
fixed in w_scan if the broadcaster doesn't send the correct transponder
data as defined by the ETSI specifications.

You wrote, that this has been working before. Can you name the version of
w_scan which worked for you?

Tobias




signature.asc
Description: OpenPGP digital signature

Bug#788100: The bug is still there on new version

[Eric Valette]

As expected... Tell me if you want a full trace again with new version.


undefined coderate HP
  F4294967 B8 M64 C999 D999 G8 T8 other_frequency=0 (0)
  0 frequencies
find_transponder(8442:8442:1):  - found 
'new_transponders(000)'  QAM_AUTO f = 474000 kHz 
I999B8C999D999T999G999Y999 (8442:8442:1)

updating transponder:
   (QAM_AUTO f = 474000 kHz I999B8C999D999T999G999Y999 
(8442:8442:1)) 0x
to (QAM_64   f = 4294967 kHz I999B8C999D0T8G8Y0 (8442:8442:1)) 
0x405A

  = list_transponders() ===
  new_transponders(000): QAM_64   f = 4294967 kHz 
I999B8C999D0T8G8Y0 (8442:8442:1)
  = 



-- eric


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org