Bug #1917

Git master fails to find services in some muxes that 3.3 could discover

Added by Koen Kooi almost 8 years ago. Updated over 7 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Found in version:
Affected Versions:


tvheadend 3.3 had some issues tuning into some channels where I had to do 'killall tvheadend' (and restart) to make the stream work. Since I'm forced to use that closed source crap TBS6618 driver I can't safely say who's at fault, the driver or tvheadend. Anyway, fast forward to this week and the troublesome channels don't even show up anymore when tvheadend scans the muxes! I know that lcn 112 should contain HBO2, but tvheadend says:

Jan 07 08:32:22 soekris tvheadend10610: mpegts: 396000 - starting for 'initscan' (weight 2)
Jan 07 08:32:22 soekris tvheadend10610: mpegts: 396000 - tuning on /dev/dvb/adapter0/frontend0
Jan 07 08:32:22 soekris tvheadend10610: subscription: 'initscan' subscribing to mux, weight: 2, adapter: '/dev/dvb/adapter0/frontend0', network: 'Ziggo', mux: '396000'
Jan 07 08:32:37 soekris tvheadend10610: mpegts: 396000 - initial scan no data, failed

Is there a way to force tvheadend to take a closer look into that mux? And is there a way to see if this is caused by a buggy driver or the dvb rewrite?


tvh.log (1.34 MB) tvh.log tvheadend --trace mpegts,linuxdvb,pat -l tvh.log Koen Kooi, 2014-01-07 09:27
tvh.log (20.3 KB) tvh.log Ivan Angelov, 2014-01-15 21:43
syslog discover 28E2.txt (59.7 KB) syslog discover 28E2.txt muxes added that have no services Rob vh, 2014-02-03 13:14
tvh.log (348 KB) tvh.log Viktor Kuzmin, 2014-07-06 23:04
tvh.log (348 KB) tvh.log Viktor Kuzmin, 2014-07-06 23:05



Updated by Adam Sutton almost 8 years ago

No data was received on that mux, at all. You're able to receive that with other systems?

What about other muxes? Are you still able to receive them?

Try attaching a debug log using the following options to start:

--trace mpegts,linuxdvb,pat -l tvh.log



Updated by Koen Kooi almost 8 years ago

I'm able to receive it on my TV, I haven't tried other systems, this is the only system within reach of the coax :( Other muxes work fine and I can really notice that channel switching is both faster and more reliable after updating from 3.3 to git master. I'll upload the log after it finish the initscan.


Updated by Koen Kooi almost 8 years ago

And the log


Updated by Adam Sutton almost 8 years ago

The log confirms what I suggested, there is no signal on that mux. Or at least TVH is unable to receive a signal on that mux. There is brief reports of a signal of sorts, but nothing decodable. And clearly something is meant to be there as its picking up service information from tables on other muxes.

Maybe double check the mux configuration? Looking at that log file there are quite a few muxes in your configuration that seem to be unusable (i.e. not locking / no data).



Updated by c d almost 8 years ago

Got the same error.
I found all services with w_scan, but not with tvheadend. :(

2014-01-11 17:44:16.000 mpegts: 113000 - starting for 'initscan' (weight 2)
2014-01-11 17:44:16.000 mpegts: 113000 - tuning on DRXK DVB-C DVB-T : DVB-C #0
2014-01-11 17:44:16.066 subscription: 'initscan' subscribing to mux, weight: 2, adapter: 'DRXK DVB-C DVB-T : DVB-C #0', network: 'Kabel BW', mux: '113000'
2014-01-11 17:44:21.006 mpegts: 113000 - initial scan no data, failed
2014-01-11 17:44:21.007 subscription: "initscan" unsubscribing


Updated by Ivan Angelov almost 8 years ago

Same issue on raspberry pi - w_scan detects all the services of this mux while tvheadend current git doesn't.
Log provided.


Updated by Adam Sutton almost 8 years ago

  • Category set to DVB
  • Status changed from New to Need feedback


are either of you able to provide access to your systems? It's probably the quickest route to a solution.



Updated by Koen Kooi almost 8 years ago

Sure, send me an email at with your SSH key and we'll work something out.


Updated by c d almost 8 years ago

Are there any new informations about the problem or how to fix it?
Thanks for your help :)


Updated by Rob vh almost 8 years ago

Not sure if my observation is the same bug but...
using 3.9.379 (Master at noon GMT, Monday Feb 3). I have an adapter defined for 28E2 (Freesat). I did not use the pre-populated muxes, but added one mux manually from the data in 10847000 DBV-S2 with BBC ONE HD etc. Network discovery = true, skip initial scan = false.
The Muxes display showed that only this mux was added, with 6 services. No other muxes appeared.

I had to restart tvheadend before the other muxes populated.

Among the newly found muxes was 10.817.500 V DVB-S, but after Initial Scan, this showed no services. King of Sat says the proper frequency is 10.818.000 V, so when I added that value manually, it populated with 9 services (BBC 1 Oxford, BBC News, etc).

I am going the manual add route, because using the predefined muxes for 28E2, I did not get most of the BBC services discovered.


Updated by Rob vh almost 8 years ago

For most of the muxes that show 0 services (on the 28E2), if I edit the mux and remove the "Initial scan complete" flag, the number of services jumps to a non-zero number and the services are added. Is the timeout for the initial discovery too low?


Updated by Koen Kooi over 7 years ago

Current git HEAD (c84bc2b Merge remote-tracking branch 'origin/pr/338') seems to detect everything 3.3 could detect. So I have HBO back in time for the new Game of Thrones season :)


Updated by Adam Sutton over 7 years ago

  • Status changed from Need feedback to Fixed

Looks to be fixed by last report.


Updated by Viktor Kuzmin over 7 years ago

I've switched from 3.4 to 3.9 latest git today and discovered that I can't scan 'Ku 10750' on Eutelsat 36E. Attached debug logs. Hopefully there can be workaround.

Also available in: Atom PDF