Bug #3020
closed
TVH 4.2 git HEAD: cannot find services on various 19.2E DVB muxes
Added by Manuel Lauss almost 10 years ago. Updated over 9 years ago.
0%
Description
The latest git head of tvheadend does not find any services
for example on Astra 19.2E, muxes 12480V, 12226.5H.
I've tried a scan of a fresh -git install, and using the 3.4.27 config files,
in both cases it couldn't find anything to various muxes.
TVH 3.4.27 works fine. Hardware is a PCTV Systems DVB-S2 USB Stick.
Jul 18 12:25:19 moya tvheadend89418: http: 192.168.2.104: using ticket 74CD01BF75E04E618E05AB9042409CFC5F044209 for /stream/channelid/35995696
Jul 18 12:25:19 moya tvheadend89418: mpegts: 12226.5H in Astra - tuning on PCTV S2 Stick
Jul 18 12:25:20 moya tvheadend89418: eit: registering mux 12226.5H in Astra
Jul 18 12:25:20 moya tvheadend89418: subscription: 002A: "HTTP" subscribing on channel "RTL Austria", weight: 100, adapter: "PCTV S2 Stick", network: "Astra", mux: "12226.5H", provider: "RTL", service: "RTL Austria", profile="pass", hostname="192.168.2.104", client="VLC/3.0.0-git LibVLC/3.0.0-git"
Jul 18 12:25:29 moya tvheadend89418: mpegts: 12226.5H in Astra - scan no data, failed
Jul 18 12:25:29 moya tvheadend89418: subscription: 002A: service instance is bad, reason: No input detected
Jul 18 12:25:33 moya tvheadend89418: subscription: 002A: No input source available for subscription "HTTP" to channel "RTL Austria"
Jul 18 12:25:33 moya tvheadend89418: webui: Couldn't start streaming /stream/channelid/35995696?ticket=74CD01BF75E04E618E05AB9042409CFC5F044209&mux=matroska, No input detected
Files
| log.txt.gz (25.6 KB) log.txt.gz | Kevin Schulz, 2015-08-10 14:57 |
Updated by Gary Brown almost 10 years ago
Try this mux Let us know what happens with this one.
"frequency": 11953500,
"symbol_rate": 27500000,
"fec": "3/4",
"polarisation": "Horizontal",
"modulation": "QPSK",
"delivery_system": "SYS_DVBS",
Updated by Manuel Lauss almost 10 years ago
Gary Brown wrote:
Try this mux Let us know what happens with this one.
"frequency": 11953500,
"symbol_rate": 27500000,
"fec": "3/4",
"polarisation": "Horizontal",
"modulation": "QPSK",
"delivery_system": "SYS_DVBS",
No reception. I've tried a few other DVB-S muxes, they're all dead.
Only the DVB-S2 ones are working.
Updated by Gary Brown almost 10 years ago
I've just added that mux to my setup and it works fine here.
can you check the tuner in windows. does the problems still exist?
can you check another tuner and see if you can get the dvb-s signals?
Updated by Manuel Lauss almost 10 years ago
As I wrote in the intial message: with TVH 3.4.27, all channels/muxes work
and TVH finds streams. Only current git head / TVH 4.2 doesn't seen to
be able to handle DVB-S.
Updated by Manuel Lauss almost 10 years ago
I've found no differences in the tuning parameters sent to the dvb frontend in linuxdvb_frontend_tune0 (other than
slightly different sequence of commands, and that tvh-git always sends tuning commands twice in rapid succession).
Sometimes when I tune a DVB-S mux it doesn't set a frequency at all and just logs that there's no free adapter available.
DVB-S2 muxes always work correctly.
Updated by Jaroslav Kysela almost 10 years ago
It appears like a specific driver issue which was not visible with previous tvh versions. You may try to change some tuner settings like 'tune repeats' or increase delay times in the code. I
Updated by Manuel Lauss almost 10 years ago
I've added a few more debug printf()s, and now it looks like that at least the DVB frontend code is working. It's tuning in on DVB-S muxes and gets a signal lock.
It's somewhere higher up the callchain that says that scan data is empty.
Updated by Jaroslav Kysela almost 10 years ago
If you configure tvh with --enable-trace then "--trace mpegts -l /tmp/tvh.log" should log the amount of the received data from the driver.
Updated by Kevin Schulz almost 10 years ago
- File log.txt.gz log.txt.gz added
I've a similar problem, version 3.4 scan 1500 services and in 4.2 git HEAD only 623 services.
Checked with single frequency (12544), failing with "scan no data", see trace log (scan start at line 2311).
Config option "Force old status" makes no difference. I've checked in terminal with w_scan,
it found more then 1200 services, the frequency 12544 is also found.
Best Regards
Kevin
Updated by Manuel Lauss almost 10 years ago
What I wrote in comment #7 is wrong; indeed on DVB-S muxes the frontend never gets any signal, the fe monitor receives status 0 all the time. DVB-S2 muxes however lock on after ~150ms. I've even changed the sequence of tuning data sent to the frontend to match tvh 3.4, but nothing seems to work.
I have currently no idea where to look next.
TVH: satconf_start_mux
2015-08-10 17:02:30.000 [ INFO] mpegts: 11953.5H in Astra - tuning on PCTV S2 USB Stick
TVH: fe_tune0 said: 0
TVH: ld_tune said 0
TVH: TUNE1 0
TUNE0: freq = 1353500 fe_freq = 11953500 diff = 10600000
TVH: ARMING FE TIMER
TVH: TUNE 1 DONE
2015-08-10 17:02:30.069 [ ERROR] linuxdvb: NEW TUNE
2015-08-10 17:02:30.069 [ ERROR] linuxdvb: S2CMD 17 => 5
2015-08-10 17:02:30.069 [ ERROR] linuxdvb: S2CMD 03 => 1353500
2015-08-10 17:02:30.069 [ ERROR] linuxdvb: S2CMD 04 => 0
2015-08-10 17:02:30.069 [ ERROR] linuxdvb: S2CMD 08 => 27500000
2015-08-10 17:02:30.069 [ ERROR] linuxdvb: S2CMD 09 => 3
2015-08-10 17:02:30.069 [ ERROR] linuxdvb: S2CMD 06 => 2
2015-08-10 17:02:30.069 [ ERROR] linuxdvb: S2CMD 13 => 0
2015-08-10 17:02:30.069 [ ERROR] linuxdvb: S2CMD 12 => 2
2015-08-10 17:02:30.069 [ ERROR] linuxdvb: S2CMD 01 => 0
2015-08-10 17:02:30.069 [ INFO] subscription: 0001: "epggrab" subscribing to mux "11953.5H", weight: 4, adapter: "PCTV S2 USB Stick", network: "Astra", service: "Raw PID Subscription"
TVH: READING FE STATUS: 0 11 0 (8000)
2015-08-10 17:02:30.359 [ INFO] AVAHI: Service 'MoyaTV' successfully established.
TVH: READING FE STATUS: 0 0 0 (8000)
TVH: READING FE STATUS: 0 0 0 (8000)
TVH: READING FE STATUS: 0 0 0 (8000)
TVH: READING FE STATUS: 0 0 0 (8000)
TVH: READING FE STATUS: 0 0 0 (8000)
TVH: READING FE STATUS: 0 0 0 (8000)
TVH: READING FE STATUS: 0 0 0 (8000)
TVH: READING FE STATUS: 0 0 0 (8000)
TVH: READING FE STATUS: 0 95 0 (8000)
TVH: READING FE STATUS: 0 0 0 (8000)
TVH: READING FE STATUS: 0 0 0 (8000)
TVH: READING FE STATUS: 0 0 0 (8000)
TVH: READING FE STATUS: 0 0 0 (8000)
TVH: READING FE STATUS: 0 0 0 (8000)
TVH: READING FE STATUS: 0 0 0 (8000)
TVH: READING FE STATUS: 0 0 0 (8000)
TVH: satconf_start_mux
2015-08-10 17:02:39.000 [ INFO] mpegts: 11229V in Astra - tuning on PCTV S2 USB Stick
2015-08-10 17:02:39.000 [ INFO] subscription: 0001: "epggrab" unsubscribing
TVH: fe_tune0 said: 0
TVH: ld_tune said 0
TVH: TUNE1 0
TUNE0: freq = 1479000 fe_freq = 11229000 diff = 9750000
2015-08-10 17:02:39.056 [ ERROR] linuxdvb: NEW TUNE
2015-08-10 17:02:39.056 [ ERROR] linuxdvb: S2CMD 17 => 6
2015-08-10 17:02:39.056 [ ERROR] linuxdvb: S2CMD 03 => 1479000
2015-08-10 17:02:39.056 [ ERROR] linuxdvb: S2CMD 04 => 0
2015-08-10 17:02:39.056 [ ERROR] linuxdvb: S2CMD 08 => 22000000
2015-08-10 17:02:39.056 [ ERROR] linuxdvb: S2CMD 09 => 2
2015-08-10 17:02:39.056 [ ERROR] linuxdvb: S2CMD 06 => 2
2015-08-10 17:02:39.056 [ ERROR] linuxdvb: S2CMD 12 => 2
2015-08-10 17:02:39.056 [ ERROR] linuxdvb: S2CMD 13 => 0
2015-08-10 17:02:39.056 [ ERROR] linuxdvb: S2CMD 01 => 0
TVH: ARMING FE TIMER
TVH: TUNE 1 DONE
2015-08-10 17:02:39.060 [ INFO] subscription: 0003: "scan" subscribing to mux "11229V", weight: 5, adapter: "PCTV S2 USB Stick", network: "Astra", service: "Raw PID Subscription"
TVH: READING FE STATUS: 0 11 0 (8000)
TVH: READING FE STATUS: 0 0 31 (8000)
TVH: READING FE STATUS: 0 95 31 (8000)
TVH: READING FE STATUS: 0 0 31 (8000)
TVH: READING FE STATUS: 0 0 31 (8000)
Updated by Kevin Schulz almost 10 years ago
Hi,
in the meantime, i've tested it with vdr+wirblescan, more then 1200 services was found.
That is definitely no hardware problem.
I believe tvh check the signal quality in a parent instance and if tvh thinks the level is to weak,
it drops the connection, can a developer check this?
Manuel, how strong is your signal level?
Best Regards
Kevin
Updated by Jaroslav Kysela almost 10 years ago
This condition must be met:
Otherwise the "grab" thread is not started. It's probably your issue when the driver is BROKEN .
Updated by Manuel Lauss almost 10 years ago
Correct, and that's the case. Somehow the frontend doesn't like the way tvheadend-git is poking
it when it's supposed to tune DVB-S (not S2) muxes. The FE_STATUS ioctl never returns the FE_HAS_LOCK
condition.
The hardware works, w_scan and tvheadend-3.4 are both able to enumerate and stream video from DVB-S muxes.
Updated by B C almost 10 years ago
imho the driver not the hw is causing the problem. why are all s2cmds marked with error in the log? I would not suspect any locking when tuning fails.
Updated by Manuel Lauss almost 10 years ago
That was just me changing from debug to error so it spits it out regardless of --trace and such.
Updated by Jaroslav Kysela almost 10 years ago
Did someone try to set the status as SIGNAL_GOOD to start the grab thread regarless the lock status reported from the driver ?
diff --git a/src/input/mpegts/linuxdvb/linuxdvb_frontend.c b/src/input/mpegts/linuxdvb/linuxdvb_frontend.c
index 2b74179..f6df77f 100644
--- a/src/input/mpegts/linuxdvb/linuxdvb_frontend.c
+++ b/src/input/mpegts/linuxdvb/linuxdvb_frontend.c
@@ -497,6 +497,8 @@ linuxdvb_frontend_monitor ( void *aux )
else
status = SIGNAL_NONE;
+ status = SIGNAL_GOOD;
+
/* Set default period */
if (fe_status != lfe->lfe_status) {
tvhdebug("linuxdvb", "%s - status %7s (%s%s%s%s%s%s)", buf,
Anyway, it would be good to report the issue to the author of the DVB driver...
Updated by Manuel Lauss almost 10 years ago
It seems that currently this bug is gone. I built a debug-enabled kernel, enabled tracing in the frontend and compared its debug output from TVH3 to TVH4, but found no meaningful differences.
TVH4 now finds the missing services, even on plain old DVB-S transponders, and streaming them works fine.
The bug went away, but this kernel warning appeared instead, when tvh is launched:
[ 6.737232] usb 1-8: DVB: adapter 0 frontend 0 frequency 0 out of range (950000..2150000)
I'll keep poking it to see whether it breaks again...
Updated by B C almost 10 years ago
The frequency out of range message is nothing to worry about, it happens on every start up and sometimes if funky NIT tables send invalid data.
When you did build your kernel, was it the same version or might the drive have been fixed?
Updated by Manuel Lauss almost 10 years ago
Well, i used 4.1.4 the last few days, and have now updated to 4.1.5, tried both with and without debug options enabled. there were no changes to the fe (m88ds3103) and bridge chip (em28178) code.
but as I said, the whole time TVH3 was able to tune in on everything.
Updated by Jaroslav Kysela almost 10 years ago
Manuel Lauss wrote:
Well, i used 4.1.4 the last few days, and have now updated to 4.1.5, tried both with and without debug options enabled. there were no changes to the fe (m88ds3103) and bridge chip (em28178) code.
but as I said, the whole time TVH3 was able to tune in on everything.
This does not help much. TVH3 code is dead. Have you tried the patch in comment#16 ?
Updated by Kevin Schulz almost 10 years ago
Hi,
if have tried the patch, with no success:
2015-08-17 11:42:32.095 mpegts: 12544.75H in Astra - tuning on Technisat SkyStar USB HD (DVB-S/S2) : DVB-S #0
2015-08-17 11:42:35.041 subscription: 00B7: "scan" subscribing to mux "12544.75H", weight: 5, adapter: "Technisat SkyStar USB HD (DVB-S/S2) : DVB-S #0", network: "Astra", service: "Raw PID Subscription"
2015-08-17 11:42:37.223 linuxdvb: Technisat SkyStar USB HD (DVB-S/S2) : DVB-S #0 - poll TIMEOUT
2015-08-17 11:42:38.859 linuxdvb: Technisat SkyStar USB HD (DVB-S/S2) : DVB-S #0 - retune nodata
2015-08-17 11:42:42.537 mpegts: 12544.75H in Astra - scan no data, failed
Note: my hardware differs from Manuel, it's another driver
Best Regards
Kevin
Updated by Jaroslav Kysela almost 10 years ago
OK. Thanks. The driver do not send any data, so tuning really failed. I would contact the author of the driver to look in this issue. It appears that it's buggy.
Another way is to find a workaround for TVH4.
Updated by B C almost 10 years ago
for the workaround part, try to change settings like Full DiseqC, Tune Before DiseqC, Tune Repeats, Old Status and disable power saving for the LNBs
Updated by Kevin Schulz almost 10 years ago
@B C
Before i post my issue, i have tried different combinations without success.
@Jaroslav
Why is the driver in TVH4 buggy and with THV3, w_scan and other does it work?
Is TVH4 not so tolerant?
For my understand, can you please explain this a little bit?
Thanks,
Kevin
Updated by Jaroslav Kysela almost 10 years ago
Kevin Schulz wrote:
@Jaroslav
Why is the driver in TVH4 buggy and with THV3, w_scan and other does it work?
Is TVH4 not so tolerant?
For my understand, can you please explain this a little bit?
TVH4 uses different code to drive the linuxdvb devices than TVH3. Nothing else. Unfortunately, there are a lot of changes.
If you can modify TVH4 code to follow the w_scan or use other working code for your kernel driver then we can add a workaround to TVH4 (specific ioctl sequence or so). Unfortunately, it's difficult to identify the "working" initialization sequence without the identic hw/kernel combo like yours. Note that I think that the kernel linuxdvb driver is a bit buggy in your case and it seems that it does not like the initialization sequence from TVH4. On other side, TVH4 code is tested with a lot of other linuxdvb drivers.
Updated by pri vado almost 10 years ago
I have been getting this on latest build on 28.2, using digital device s8 MAX and latest drivers.
Updated by Manuel Lauss almost 10 years ago
After upgrading the kernel to 4.2, the issue resurfaces again (only DVB-S2 muxes can be tuned), I'll leave the kernel at 4.1.6 at the moment
and try to bisect the root cause.
Updated by Manuel Lauss over 9 years ago
This bug can be closed as invalid. At least in my case this issue was a bug in the frontend driver in the 4.2 kernels after all.
It has been fixed and I'm running tvheadend-git and kernel-git without any issues.