NPVR v504

[sub]

The next release will wait up to 2.5 seconds for the channel numbers, instead of the 1 second in the current release.

The next release will also honor the ScanDropTime setting.

[mame]

The next release will wait up to 2.5 seconds for the channel numbers, instead of the 1 second in the current release.

The next release will also honor the ScanDropTime setting.

I understand that the sensitivity of a TV is greater than a dongle, but ...

- why, on any scan, serid: tsid: onid remain stable while chid changes? and also LCN may change?
for example, Rai 1 HD: its LCN is 501 but almost always appears 71 or 76 or other, despite the #501 being free and not assigned to any other channel.
You say "so the channel just gets allocated the next channel number", but it seems the opposite: 71 is less than 501.

- how is it possible that, scanning a frequency, it doesn't tune all the channels (e.g. all except 1)?

- how is it possible that the all the frequency 538 is not tuned on day 9 while it is on day 11?


In the meantime I wanted to do another test with subsequent scans and results have emerged that I have difficulty understanding: you can find everything in the attached zip (log and report).
Do you think that the next release will solve these problems?

[sub]

- why, on any scan, serid: tsid: onid remain stable while chid changes? and also LCN may change?
for example, Rai 1 HD: its LCN is 501 but almost always appears 71 or 76 or other, despite the #501 being free and not assigned to any other channel.
You say "so the channel just gets allocated the next channel number", but it seems the opposite: 71 is less than 501.

- how is it possible that, scanning a frequency, it doesn't tune all the channels (e.g. all except 1)?

- how is it possible that the all the frequency 538 is not tuned on day 9 while it is on day 11?

It's just a timing thing. NextPVR is specifically waiting on each frequency for thing called the SDT, which contains the list of channels, and their names. The is another separate piece of info in the stream called the NIT, broadcast in a different location in the stream, which carries the LCN numbers for the channels. NextPVR is saving the channels as soon as it gets the SDT (after waiting a mandatory drop time of 500ms), and will use the LCN numbers if it had received any for those channels. If it hadn't received an LCN, the channel just get assigned the next number.

Some broadcasters don't send any LCN data, so NextPVR doesn't explicitly wait for this to arrive.

"gets allocated the next channel number" isn't quite what you think it is. It was the next number at the time the scan started. This logic was really designed for broadcasters that didn't include any LCN data. In your case it's kind of getting a mix of some frequencies with LCN data, and some without (because it hasn't always waited long enough for it to arrive).

Unfortunately the likely hood of having received the LCN seems to vary, depending on how frequently the broadcaster sends the NIT. It sounds like your broadcaster sends it less frequently than mine.

Do you think that the next release will solve these problems?

Hopefully. The next release will increase the drop time.

[mame]

Well, quite clear the concept, but why this lack of reception ("If it hadn't received an LCN") does not occur by scanning the frequencies individually (or even a few mux at a time) and occurs regularly by scanning a greater number of mux (see my latest pdf report)?
When I scan, I think this occurs by scrolling the frequencies sequentially as indicated in the .ini file, and when it scans the frequency x what differs from doing it individually?
In the first case the #LCN is wrong (not received?) in the second it is OK (why now received?).

Hopefully, awaiting for the next release, let we know.

[sub]

but why this lack of reception ("If it hadn't received an LCN") does not occur by scanning the frequencies individually

The tuner actually spends a little longer on the first frequency, because there is some extra time in starting the tuner etc, and this gives more opportunity for the NIT to arrive.

[mame]

but why this lack of reception ("If it hadn't received an LCN") does not occur by scanning the frequencies individually

The tuner actually spends a little longer on the first frequency, because there is some extra time in starting the tuner etc, and this gives more opportunity for the NIT to arrive.

OK, let's not rush him by giving him the right time to "reflect"!