one mux only gives me 10000 for LCN (1 Viewer)

[gemx]

I have checked it and the problem is that e.g. in your ts dump there are only 3 NIT sections (they contain the LCN) in the whole approx. 100 MB file.
That means it takes it's for the first NIT section to arrive.
The NIT grabber currently has a timeout of 5 seconds which in your case was not enough.
No NIT section has been received during this period.
I could make the timeout bigger but that would mean that scanning takes longer for all.
Since the LCN is only additional info i would suggest leaving things as they are.

 

[tourettes]

I have checked it and the problem is that e.g. in your ts dump there are only 3 NIT sections (they contain the LCN) in the whole approx. 100 MB file.
That means it takes it's for the first NIT section to arrive.
The NIT grabber currently has a timeout of 5 seconds which in your case was not enough.
No NIT section has been received during this period.
I could make the timeout bigger but that would mean that scanning takes longer for all.
Since the LCN is only additional info i would suggest leaving things as they are.

I would propose that we add user configurable NIT timeout for 1.0.1 as some 3rd party clients might be interested in the information (sort channels etc.).

 

[binary64]

Thank you very much for looking gemx,

Ok, so I would need a timeout of 20 secs I guess. Other people in my country have this issue with this same mux with MP tve3. Could this be treated like a bug though: add a user option in.. or hook into an existing timeout and append "/NIT" to the textbox label. Also, channel scanning is seldom done, it's not like we're talking about zapping times here.

Good thing tho, it seems if i do 2 or 3 re-scans over the top of existing channels, it updates the LCN properly, and doesn't seem to overwrite the correct LCN with 10000 when it's timed out that time. Can anyone confirm this ?

 

[binary64]

Just re-read what gemx said: "Since the LCN is only additional info i would suggest leaving things as they are."

Most countries don't care about LCN(?), but here in the UK we live by it. So it's not just some wierd meta information we wont care about.

Perhaps if it was made to be 10 secs, then it would be more specs-compliant.. and squash another bug.

 

[binary64]

This "bug" still exists in RC2:

I thought some more about it, and gemx said it would affect all users. Well if it's a timeout, and most users TV broadcasters send frequent NIT's, then they shouldn't be affected by increasing the timeout. Ie, most people should wait below the NIT timeout value, depending on when they tuned in it might take 0ms-10secs). The only people who would be "forced" to wait longer for a channels-scan (which is rarely done, and manually done anyway - it's not like this is a WAF task) are the people who would have been given a channel lineup with missing LCN's anyway, so what does it matter.

Hope I make a bit of sense here.

 

[tourettes]

This "bug" still exists in RC2:

I thought some more about it, and gemx said it would affect all users. Well if it's a timeout, and most users TV broadcasters send frequent NIT's, then they shouldn't be affected by increasing the timeout. Ie, most people should wait below the NIT timeout value, depending on when they tuned in it might take 0ms-10secs). The only people who would be "forced" to wait longer for a channels-scan (which is rarely done, and manually done anyway - it's not like this is a WAF task) are the people who would have been given a channel lineup with missing LCN's anyway, so what does it matter.

Hope I make a bit of sense here.

If you look at the Mantis you'll see that the timeout issue has target after the 1.0 release. Thats why its still open at RC2.

0001367: Wrong LCN value in channel scan - MediaPortal Bugtracker

What comes to the scanning. Currently it can take up to 30 minutes... now we dont really want to add 15 minutes extra

 

[revs]

How about when a UK Transmitter is selected for scanning the scanning is changed. That way its not slow for everyone else?

Just pop up a message saying it may take a while to scan! How often do people scan anyway? I just do it once when I setup the TV Server.

 

[markius]

I could make the timeout bigger but that would mean that scanning takes longer for all.
Since the LCN is only additional info i would suggest leaving things as they are.

<EDIT> D'uh... just realised this is the same as what binary64 wrote :sorry:
I blame too many late nights watching Olympics!
</EDIT>

Would it be possible to change the logic slightly?

My understanding is that the channel scan will wait for 5 seconds for NIT sections to arrive before moving on to the next MUX and if we up the timeout to 20 seconds then channel scanning will be slower. (My understanding could of course be way off)

Could we have logic that waits for *up to* 20 seconds for the NIT section, but will move on to the next MUX as soon as the NIT section is seen? This may even result in faster channel scans on MUXs where NIT sections are transmitted more frequently.

Just a thought and as I say my assumptions could be way off

Cheers for the hard work guys... loving your work!

Mark

 

[wonkyd]

Sorry to resurrect an old thread but this all came about when the split-NIT was implemented in the UK.
However in the recent 1.0.1 SVNs I’ve not seen this issue; anyone else out there still had the problem?

 

[wonkyd]

Sorry to resurrect an old thread but this all came about when the split-NIT was implemented in the UK.
However in the recent 1.0.1 SVNs I’ve not seen this issue; anyone else out there still had the problem?

Scrub that!

Now all MUXs are giving me an LCN of 10000. There were some LCN/Name changes earlier this week, maybe they've changed something in the NIT again?