Tvheadend

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.

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"?

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).

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?

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.

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.

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

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...

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/ .

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.