Tvheadend

Could you retest again and provide logs, please?

I guess I reported the success too early, still having the same problem with version 3.9.2231~g19dbe37...

This actually looks like issue #2474

I think issue #2605 is also related. All seem to result from an inability to correctly deal with a delivery system descriptor which is not valid for the transport stream on which it is broadcast. IMHO what tvh should be doing is noting the details from the dsd and in due course attempting to tune to that mux. If it fails to tune, the mux needs to be flagged as unavailable and no services should be ascribed to it. The rest of the information in the corresponding nit is potentially relevant to the tuned transport stream and can be filtered by onid+sid. ETSI TS 101 211, for example, describes how a dsd might not match the mux on which it's broadcast and although the example is where a stream is re-broadcast from one medium to another, it looks like "invalid" dsds are used in UK quite understandably within the terrestrial medium, and it may well be the same in Austria.

a) transmission of the NIT is mandatory for the actual delivery system;
b) the NIT describing the actual delivery system is valid if and only if it contains applicable delivery system
descriptors for the actual delivery system. At some transitions of broadcast delivery system boundaries, the
NIT carried in a TS is allowed to be invalid, and to describe an earlier network in the broadcast chain. In this
case, a different mechanism has to be selected by the IRD to obtain the relevant tuning information for the
actual delivery system. More information is provided in clause 5.3;
c) if a valid NIT for the actual delivery system is present in the SI bit stream then it shall list all TSs of the actual
delivery system;
d) the SI stream shall have at least 8 TS packets per 10 s carrying NIT data or NULL packets. This rule simplifies
the replacement of the NIT at broadcast delivery system boundaries. With the simple replacement mechanism,
local frequency control is possible with relatively low cost equipment.

On this definition, the transmitters round where I live don't seem to be sending out "valid" NITs at all. Perhaps it's this that is confusing tvh. Doubtless there is a similar system to that described in TS 101 211 in force in the US. If this is a problem all over the world, then it does need a fix.

Graham Horner wrote:

I think issue #2605 is also related. All seem to result from an inability to correctly deal with a delivery system descriptor which is not valid for the transport stream on which it is broadcast. IMHO what tvh should be doing is noting the details from the dsd and in due course attempting to tune to that mux. If it fails to tune, the mux needs to be flagged as unavailable and no services should be ascribed to it. The rest of the information in the corresponding nit is potentially relevant to the tuned transport stream and can be filtered by onid+sid. ETSI TS 101 211, for example, describes how a dsd might not match the mux on which it's broadcast and although the example is where a stream is re-broadcast from one medium to another, it looks like "invalid" dsds are used in UK quite understandably within the terrestrial medium, and it may well be the same in Austria.

Could you retest with v3.9-2374-gd9f4230 ?

The algorithm should be:

1) discover all muxes (use provided frequencies/parameters)
2) always update services for the currently tuned mux
3) match ONID/TSID for all other muxes in network, but update the services only when mux is alive (was tuned - some services are already present)

https://tvheadend.org/projects/tvheadend/repository/revisions/30cc0a73bdc59b36b151dddc8c049dbf9646420b/diff/
https://tvheadend.org/projects/tvheadend/repository/revisions/d9f42308817a8ad49b4ee9faaccd9c3c5b37c36d/diff/

No scanning:

2015-01-14 13:42:18.084 [  TRACE]:mpegts: network-list: found input 'Silicon Labs Si2168 : DVB-T #0'
2015-01-14 13:42:26.000 [  TRACE]:mpegts: 706MHz in Dover - starting for 'scan' (weight 4, flags 0022)
2015-01-14 13:42:26.000 [  TRACE]:mpegts: 706MHz in Dover -   mmi 0x89f0180 enabled 0
2015-01-14 13:42:26.000 [  DEBUG]:mpegts: 706MHz in Dover - no tuners enabled

and yes, tuner is enabled in the web interface.

Graham Horner wrote:

No scanning:

[...]

and yes, tuner is enabled in the web interface.

Including Init Scan (in the tuner settings) ?

No, only idle scan. I've never needed that before, I didn't think it was necessary if you used an initial scan file.

Skip initial scan in networks was turned off.

Graham Horner wrote:

No, only idle scan. I've never needed that before, I didn't think it was necessary if you used an initial scan file.

Skip initial scan in networks was turned off.

(weight 4, flags 0022) - 0x22 - SUBSCRIPTION_INITSCAN | SUBSCRIPTION_NONE. Tvheadend tries to subscribe the mux in the init scan phase (only once after start or if the new mux was created). If you don't enable the 'Init Scan' in the tuner settings, then the tuner is blocked for this operation (init scan).

OK. All working fine now!

Slight confusion over "initial scan", which for w_scan utility means checking all frequencies for valid broadcasts, whereas here it seems to mean checking (known) muxes for valid services. If so the help on the networks tab could usefully be re-phrased and help on the adapters tab expanded.

Many thanks for sticking with this and I hope it's solved the OP's issue as well.