Project

General

Profile

Bug #3842

New muxes + changed muxes -- no update when Symbol Rate on Transponder is changed

Added by Gert Jansen over 5 years ago. Updated over 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2016-06-06
Due date:
% Done:

0%

Estimated time:
Found in version:
4.1-2109~g189dcb6
Affected Versions:

Description

I'm not sure if this is something not working as intended due to a bug, or due to a misconfiguration on my part - or just me making a wrong interpretation of what a feature does.

Last week (on the 31st of May) Canal Digitaal & TV Vlaanderen changed the Symbol Rates for 3 Transponders on Astra 3.
As a consequences all channels on these transponders stopped working, and all scheduled recordings failed as well.

The transponders with the new Symbol Rates were added automatically, because I had network discovery enabled.
They were added as new muxes, next to the existing - now outdated - muxes with the old Symbol Rates.
I got things working again by deleting the affecting channels and creating new ones from the services found on the new muxes.

At that time I was using version 4.1-1235~gd822a74

-

A few days ago, I saw that the feature 'Network Discovery' was changed so that instead of enabled or disabled, it now had the new options 'new muxes only' and 'new muxes + changed muxes'.
I installed version 4.1-2109~g189dcb6 and restored my configuration to the one I had on the 30th of May (i.e. before the changes to the 3 transponders were made)
I changed the option for Network Discovery from 'new muxes' to 'new muxes+changed muxes' and had TVHeadend rescan all muxes again.

I more or less expected/hoped that TVHeadend would update the existing muxes with the new Symbol Rate, and in doing so the affected channels would automatically work again.
However, that is not what happened. The 3 transponders were again added as a new muxes, while the old ones were kept, and the channels were still mapped to the old outdated muxes.

Am I reading to much into this feature, or should it have worked the way I wanted?

I still have the configuration of the 30th of May available, so I can retest if needed.

History

#1

Updated by Jaroslav Kysela over 5 years ago

Basically, TVH does what's indended. But yes, the things should be improved. I am fighting with a situation where the broadcasted information differs on some muxes, so autodiscovery in tvh will do a ping-pong with this information (muxA says that muxX has FEC 3/4 but muxB says that muxX has FEC 9/10 for example). For this reason, the new muxes are created when the tuning parameters differs so much.

But... I am thinking to add an algorithm which will try to select the working parameters and ignore the muxes (set the 'Enable' state to 'Ignored') which cannot be tuned or muxes with identical frequencies (because many tuners can auto-detect parameters so they are fine with incomplete or slightly incorrect ones).

Actually, the fastest way is to set the mux with mapped services to channels to correct parameters manually and set the clashing muxes as 'Ignore' at this time.

#2

Updated by Gert Jansen over 5 years ago

OK,

so no bug after all.

I was unsure what that new option for Network Discovery actually did, and couldn't find any info about it. Probably because it was so new.
I assumed it would update the definitions for the changed transponders and thus update all affected channels as well. That's basically what my old CanaalDigitaal-certified STB does.

Just for my information, could you tell me what the difference is between "new muxes only" and "new muxes+changed muxes"?

If I understand correctly, if it picks up a mux with changed settings (like new Symbol Rate), the net result would be the same for both "new muxes only"and "new+changed"?

#3

Updated by Jaroslav Kysela over 5 years ago

TVH tolerates some changes/deltas for DVB-S(2) (it's a bit different across mux types):

- 4Mhz for frequency
- 1000 symbol rate

And strict checking:

- modulation, FEC, polarisation, satellite position

Other parameters (pilot, rolloff are unchecked).

So if you enable 'new+changed' the changes inside the deltas and for other parameters are saved and used. For 'new only' option these changes are not saved (they are ignored).

#4

Updated by Gert Jansen over 5 years ago

In this case the symbol rate was changed from 27500 to 29900. That's 2400, since that's outside the allowed delta, it would have been treated as 'new' instead of 'changed' anyway, right?

#5

Updated by Jaroslav Kysela over 5 years ago

Yes, exactly. But TVH should disable muxes on same frequency (to avoid duplicate services). When I find a little time, I'll try to prepare something.

#6

Updated by B C over 5 years ago

mapped channels will stay on the old TP and (in my case as I'm lucky with my tuners) will still work. If some logic is found to disable the invalid TP (which can be tough as both do lock in a lot of cases) the mapped channels should roam as well.
From a transponders point of view, it has a unique orbital position, polarization and center frequency. Although it would be a great amount of work, it might be better to seperate Type, SR, modulation, FEC etc from frequency/polarization in a 1 to n relationship? If services are bound to frequency/pol only it should avoid a lot of double entries and work for the user.

#7

Updated by B C over 5 years ago

also take into account that the 4Mhz frequency diff does not work for SCPC carriers, I have some muxes with 2 Mhz spacing. So if TP bandwidth/SR is less than some value (eg 5000) do not treat them as the same TP

#8

Updated by Gert Jansen over 5 years ago

Thanks all for the insight :)

B C wrote:

mapped channels will stay on the old TP and (in my case as I'm lucky with my tuners) will still work.

Sadly, in my case, they indeed stayed on the old TP but didn't work anymore - probably because it (the Symbol Rate) was too different.

B C wrote:

If some logic is found to disable the invalid TP (which can be tough as both do lock in a lot of cases) the mapped channels should roam as well.

I don't know too much about how this all works, but could it help to detect duplicate muxes based on the Transponder ID? I'm not certain it is really unique, but for the few I checked on kingofsat that seems to be the case?
Furthermore, one of the duplicates in TVH has a scan result "failed" and one of them has a scan result "OK".

Most likely, it won't be as simple as that...

#9

Updated by Jaroslav Kysela over 5 years ago

B C wrote:

mapped channels will stay on the old TP and (in my case as I'm lucky with my tuners) will still work. If some logic is found to disable the invalid TP (which can be tough as both do lock in a lot of cases) the mapped channels should roam as well.

Yes, I agree. The services should migrate to last seen mux. Also, the automatically disabled TPs should be put to the scan queue when the mux info is re-broadcasted - in case when the broadcaster returns to previous parameters. Things are not so easy as they should be when this info on all muxes is synced.

From a transponders point of view, it has a unique orbital position, polarization and center frequency. Although it would be a great amount of work, it might be better to seperate Type, SR, modulation, FEC etc from frequency/polarization in a 1 to n relationship? If services are bound to frequency/pol only it should avoid a lot of double entries and work for the user.

I also though about this, but it's better/easier to create duplicate muxes.

also take into account that the 4Mhz frequency diff does not work for SCPC carrier

Interesting. Tried to put a compensation for this to https://tvheadend.org/projects/tvheadend/repository/revisions/d6bda752cc0ec5e3e3a7a00b082e660c4dccecb1/diff/ .

#10

Updated by B C over 5 years ago

Thanks for the compensation fix, will try it when I have time.

Another idea for selecting the right mux parameters would be to check the NIT on the TP in question. Although not 100% a must, but it should carry the right parameters. So assume we do successfully lock with a wrong FEC or whatever to a mux. We read the NIT for our own TP, check if it is already in the list of known muxes and add it, if not found, otherwise enable it if it was disabled. Next disable all other muxes with the same freq/pol. If there are services on a now disabled mux with the same ONID and TSID move them to the new mux. The following service scan on the TP will validate them anyway. Even if the NIT is actually not 100% correct it will leave only one enabled TP no matter how many versions there are available.

Also available in: Atom PDF