Tvheadend

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

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.

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?

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.

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.

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

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.

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.

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)

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

This condition must be met:

https://github.com/tvheadend/tvheadend/blob/master/src/input/mpegts/linuxdvb/linuxdvb_frontend.c#L535

Otherwise the "grab" thread is not started. It's probably your issue when the driver is BROKEN .

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.

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.

That was just me changing from debug to error so it spits it out regardless of --trace and such.

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

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

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?

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.

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 ?

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

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.

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

@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

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.

I have been getting this on latest build on 28.2, using digital device s8 MAX and latest drivers.

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.

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.