Bug #2068
closed
too many services / network discovery does not work
Added by Simon Solothurnman almost 11 years ago. Updated almost 10 years ago.
100%
Description
Hi
I just patched tvheadend from 3.4.27 to latest git 3.9.542~g63ac3be and I noticed that tvheadend discovers way too many services per muxes.
After I tried to use network discovery which only brought up 14 channels I added the muxes manually. However, in that case, tvheadend "detected" 4418 services on my 43 muxes..
Tvheadend 3.4.27 was correctly identifying the actual 450 or so services.
I use Philips TDA10023 DVB-C Adapter (Mantis).
Best regards,l
Files
| screenshot.png (99.2 KB) screenshot.png | Thomas Reitmayr, 2014-05-30 23:00 | ||
| logfile.gz (22.1 KB) logfile.gz | Thomas Reitmayr, 2014-05-30 23:00 | ||
| logfile2.gz (98.1 KB) logfile2.gz | Thomas Reitmayr, 2014-06-14 12:30 | ||
| logfile-working.gz (72.4 KB) logfile-working.gz | Thomas Reitmayr, 2014-08-18 14:24 |
Updated by Adam Sutton almost 11 years ago
- Status changed from New to Need feedback
My guess you've not got the network ID set? so it's picking up all the possible services for a bunch of networks, still slightly odd that's it's not also more muxes.
Adam
Updated by Adam Sutton almost 11 years ago
- Category changed from PVR / DVR to DVB
Updated by Thomas Reitmayr almost 11 years ago
- File screenshot.png screenshot.png added
- File logfile.gz logfile.gz added
Hi,
I've probably got the same problem, just with a few less muxes. Here are some links to what I expect to be detected in my region:
Summary (look at Mux WN and Mux W2 only):
http://www.ors.at/fileadmin/user_upload/downloads/DVB-T_PID_Liste.pdf
Mux WN:
http://igorfuna.com/dvb-t/austria/multiplex-a-transport-stream-analysis
Mux W2:
http://igorfuna.com/dvb-t/austria/multiplex-b-transport-stream-analysis
I create one DVB-T Network (without Network ID limitation) and added the two Muxes with their frequencies 498 and 578 MHz. There is also a third MUX C-W1 in my area but I did not add it.
The result was that the services of Mux W2 and C-W1 (!) were detected. Then I disabled one mux and reenabled it, and did the same with the second mux. Now the result was double the services I saw before(!) and no service from Mux WN at all.
However the behavior is not always like this, sometimes a different mux is correctly decoded but a different one is missing. I suspect that each mux carries the information about all services provided by all three muxes, and TvHeadend cannot sort that out correctly but just takes whatever service information is decoded first - just a wild guess.
I attached a screenshot of the final list of services along with a trace file (stripped by the UPnP lines).
The TvHeadend version I used is from today, commit 0ebca1b3dbb6a18d8adcf66a32b5922ce769b9b5.
Hope this can give you some clue...
Thanks,
-Thomas
PS: Creating separate networks with NID filtering did not help either in another experiment...
Updated by Thomas Reitmayr almost 11 years ago
- File logfile2.gz logfile2.gz added
I saw that a few more debug messages were added, so I created a new log file "logfile2.gz" from the current version in git (commit 7a06f00d972e986d98a40ec3a775f8b4b332a9cf). Again I added the two muxes, and again they got the transmitted services wrong. First mux was added at 2014-06-14 12:20:13.172, second mux at 2014-06-14 12:20:54.883.
BTW, another wild guess: Does Tvheadend somehow distinguish the muxes by their ONID without considering further IDs (which in the current case would not be sufficient) in order to filter out the actually transmitted services of a mux?
Updated by Jaroslav Kysela over 10 years ago
Could you retest again and provide logs, please?
Updated by Thomas Reitmayr over 10 years ago
- File logfile-working.gz logfile-working.gz added
Thanks Jaroslav, for me it looks very good now with version c31a0c8077909d324d8e989582cb824bbac2f6b7!
In the new log "logfile-working.gz" I added the three muxes mentioned in my first comment (at times 13:48:41.340, 13:49:45.532, and 13:51:49.246) and each of them only adds the services it actually provides.
Still would like to see some tests from the original reporter of this bug...
Updated by Thomas Reitmayr over 10 years ago
I guess I reported the success too early, still having the same problem with version 3.9.2231~g19dbe37...
Updated by Thomas Reitmayr over 10 years ago
This actually looks like issue #2474
Updated by Graham H over 10 years ago
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.
Updated by Jaroslav Kysela over 10 years ago
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/
Updated by Graham H over 10 years ago
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.
Updated by Jaroslav Kysela over 10 years ago
Graham Horner wrote:
No scanning:
[...]
and yes, tuner is enabled in the web interface.
Including Init Scan (in the tuner settings) ?
Updated by Graham H over 10 years ago
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.
Updated by Jaroslav Kysela over 10 years ago
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).
Updated by Graham H over 10 years ago
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.
Updated by Jaroslav Kysela almost 10 years ago
- Status changed from Need feedback to Fixed
- % Done changed from 0 to 100
Applied in changeset commit:tvheadend|0e5ec2a7d45d5dfa72f3b53926fa92538f8053c5.