Tvheadend

Unable to tune any channel for most of the time. Adapter is recognized, mux scanning, diseq 1.2 positioner works, as dish moves to channel, but there is no streaming. Tried with kodi tvheadend client and web client. Trace below is from web client.
It happened once that everything worked.

Setup:
Raspberry Pi 2
Tuner: DVBSKY S960
Kernel:
4.2.3-2-osmc
Latest firmware file from dvbsky homepage.

Dmesg output:
[ 21.007261] m88ds3103 3-0068: found a 'Montage Technology M88DS3103' in cold state
[ 21.018123] m88ds3103 3-0068: downloading firmware from file 'dvb-demod-m88ds3103.fw'
[ 22.074414] m88ds3103 3-0068: found a 'Montage Technology M88DS3103' in warm state
[ 22.074448] m88ds3103 3-0068: firmware version: 3.B

2015-11-20 13:29:32.623 subscription: 0524: "HTTP" subscribing on channel "Astra HD Promo", weight: 100, adapter: "Montage Technology M88DS3103 : DVB-S #0", network: "Astra 19.2E", mux: "11302.75H", provider: "AstrA HD Promo", service: "Astra HD Promo", profile="pass", hostname="5.2.200.205", client="VLC/2.2.1 LibVLC/2.2.1"

2015-11-20 13:29:53.625 webui: Stop streaming /stream/channel/b4b41d1eca4b9271ae9a5aaad9faf3b1?ticket=97C952958016F93E69E3A0E009289267723A66A7, timeout waiting for packets

2015-11-20 13:29:53.626 subscription: 0524: "HTTP" unsubscribing from "Astra HD Promo", hostname="5.2.200.205", client="VLC/2.2.1 LibVLC/2.2.1"

2015-11-20 13:29:53.660 http: 5.2.200.205: using ticket 97C952958016F93E69E3A0E009289267723A66A7 for /stream/channel/b4b41d1eca4b9271ae9a5aaad9faf3b1

2015-11-20 13:29:53.661 mpegts: 11302.75H in Astra 19.2E - tuning on Montage Technology M88DS3103 : DVB-S #0

2015-11-20 13:29:53.847 subscription: 0525: "HTTP" subscribing on channel "Astra HD Promo", weight: 100, adapter: "Montage Technology M88DS3103 : DVB-S #0", network: "Astra 19.2E", mux: "11302.75H", provider: "AstrA HD Promo", service: "Astra HD Promo", profile="pass", hostname="5.2.200.205", client="VLC/2.2.1 LibVLC/2.2.1"

2015-11-20 13:30:14.849 webui: Stop streaming /stream/channel/b4b41d1eca4b9271ae9a5aaad9faf3b1?ticket=97C952958016F93E69E3A0E009289267723A66A7, timeout waiting for packets

2015-11-20 13:30:14.850 subscription: 0525: "HTTP" unsubscribing from "Astra HD Promo", hostname="5.2.200.205", client="VLC/2.2.1 LibVLC/2.2.1"

2015-11-20 13:30:14.885 http: 5.2.200.205: using ticket 97C952958016F93E69E3A0E009289267723A66A7 for /stream/channel/b4b41d1eca4b9271ae9a5aaad9faf3b1

2015-11-20 13:30:14.886 mpegts: 11302.75H in Astra 19.2E - tuning on Montage Technology M88DS3103 : DVB-S #0

2015-11-20 13:30:15.363 subscription: 0526: "HTTP" subscribing on channel "Astra HD Promo", weight: 100, adapter: "Montage Technology M88DS3103 : DVB-S #0", network: "Astra 19.2E", mux: "11302.75H", provider: "AstrA HD Promo", service: "Astra HD Promo", profile="pass", hostname="5.2.200.205", client="NSPlayer/7.10.0.3059"

2015-11-20 13:30:35.366 webui: Stop streaming /stream/channel/b4b41d1eca4b9271ae9a5aaad9faf3b1?ticket=97C952958016F93E69E3A0E009289267723A66A7, timeout waiting for packets

2015-11-20 13:30:35.366 subscription: 0526: "HTTP" unsubscribing from "Astra HD Promo", hostname="5.2.200.205", client="NSPlayer/7.10.0.3059"

Provide '--trace linuxdvb,diseqc'. Do you see a signal in the status tab when tuned to a mux ? https://tvheadend.org/projects/tvheadend/wiki/Traces

Could you try to set the initial rotor timeout to a lower value? I don't know which range do you use (the duration for the maximal rotor movement), but there's 120 seconds by default which triggers the package timeout check in src/webui/webui.c - http_stream_run().

Looks like you may be suffering from the regression in the kernel driver I had with my DVBSky T9850 which uses the m88ds3101. Make sure that your kernel has the following patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=56ea37da3b93dfe46cb5c3ee0ee4cc44229ece47

HTH.

Jaroslav Kysela wrote:

Could you try to set the initial rotor timeout to a lower value? I don't know which range do you use (the duration for the maximal rotor movement), but there's 120 seconds by default which triggers the package timeout check in src/webui/webui.c - http_stream_run().

You mean rotor initialization time (on the parameters tab? ). I couldn't find in the menu elswhere something related to this.
But I don't think this is the issue, as then if the dish is already on the same orbital position, it should work, right ? But also in this case, i receive timeout. So I tend to assume that it could be the kernel issue that was posted by Mark.

But I would like to sort this out too, so could you tell me where can I find this option ?

Mark Clarkstone wrote:

Looks like you may be suffering from the regression in the kernel driver I had with my DVBSky T9850 which uses the m88ds3101. Make sure that your kernel has the following patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=56ea37da3b93dfe46cb5c3ee0ee4cc44229ece47

HTH.

Hmmm, currently I'm using the OSMC build with the default kernel, that is 4.2.3-2-osmc
Could you tell me where can I check if this patch is already included in the 4.2.3.2 kernel ? Meanwhile I will ask on the OSMC forum, maybe Sam will help me out.

Trex the Daemon wrote:

Mark Clarkstone wrote:

Looks like you may be suffering from the regression in the kernel driver I had with my DVBSky T9850 which uses the m88ds3101. Make sure that your kernel has the following patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=56ea37da3b93dfe46cb5c3ee0ee4cc44229ece47

HTH.

Hmmm, currently I'm using the OSMC build with the default kernel, that is 4.2.3-2-osmc
Could you tell me where can I check if this patch is already included in the 4.2.3.2 kernel ? Meanwhile I will ask on the OSMC forum, maybe Sam will help me out.

Looks like osmc uses the official kernel.org sources as shown here That lists kernel 4.3.0 for the rpi so I think all you'd need is a newer osmc version with the newer kernel.

Well, I will have to compile a new kernel, I suppose.
Or wait for Sam to release a new OSMC version..

Mark Clarkstone wrote:

Trex the Daemon wrote:

Mark Clarkstone wrote:

Looks like you may be suffering from the regression in the kernel driver I had with my DVBSky T9850 which uses the m88ds3101. Make sure that your kernel has the following patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=56ea37da3b93dfe46cb5c3ee0ee4cc44229ece47

HTH.

Hmmm, currently I'm using the OSMC build with the default kernel, that is 4.2.3-2-osmc
Could you tell me where can I check if this patch is already included in the 4.2.3.2 kernel ? Meanwhile I will ask on the OSMC forum, maybe Sam will help me out.

Looks like osmc uses the official kernel.org sources as shown here That lists kernel 4.3.0 for the rpi so I think all you'd need is a newer osmc version with the newer kernel.

Trex the Daemon wrote:

Jaroslav Kysela wrote:

Could you try to set the initial rotor timeout to a lower value? I don't know which range do you use (the duration for the maximal rotor movement), but there's 120 seconds by default which triggers the package timeout check in src/webui/webui.c - http_stream_run().

You mean rotor initialization time (on the parameters tab? ). I couldn't find in the menu elswhere something related to this.
But I don't think this is the issue, as then if the dish is already on the same orbital position, it should work, right ? But also in this case, i receive timeout. So I tend to assume that it could be the kernel issue that was posted by Mark.

You're wrong. TVH does not know the rotor position when it starts. This value defines the initialization time in seconds which TVH requires to finish the first rotor movement. If you interrrupt this (and you did based on the log - the sequence was not completed due another bug in the code), TVH will try to wait again for the full interval. Provide log when you set this value to 20 seconds or so..

I explained it. TVH actually does not know the initial position - so it expects the biggest movement when TVH starts (yep - we can probably read the actual position using DiseqC 2.0, but we send the DiseqC commands only one way at the moment).

The times for next movements are calculated regarding the known positions, so TVH won't wait so long.

Jaroslav Kysela wrote:

I explained it. TVH actually does not know the initial position - so it expects the biggest movement when TVH starts (yep - we can probably read the actual position using DiseqC 2.0, but we send the DiseqC commands only one way at the moment).

The times for next movements are calculated regarding the known positions, so TVH won't wait so long.

So that means that after startup, TVH will wait 120s no matter what BEFORE it starts to stream anything ? Well, that seems to me not the best solution. Why not try to lock on the channel meanwhile ?
I thought that setting refers to the initial delay that tvh will wait until declaring timeout.

Too much work - this time interval is used only once after start. Also, there might be other transponders with same parameters on the "way" from different satellites, so it's not as easy to wait only for "lock".

Well, it seems that reducing the timeout sovles the problem.
Meanwhile updated to kernel 4.3, but the issue was sovled with reducing the timeout.
Thanks for support, I suppose this thread can be closed.

Trex the Daemon wrote:

Jaroslav Kysela wrote:

I explained it. TVH actually does not know the initial position - so it expects the biggest movement when TVH starts (yep - we can probably read the actual position using DiseqC 2.0, but we send the DiseqC commands only one way at the moment).

The times for next movements are calculated regarding the known positions, so TVH won't wait so long.

So that means that after startup, TVH will wait 120s no matter what BEFORE it starts to stream anything ? Well, that seems to me not the best solution. Why not try to lock on the channel meanwhile ?
I thought that setting refers to the initial delay that tvh will wait until declaring timeout.