Project

General

Profile

Bug #3327

timeout waiting for packets

Added by Trex the Daemon over 6 years ago. Updated over 6 years ago.

Status:
Invalid
Priority:
Normal
Category:
Streaming
Target version:
-
Start date:
2015-11-20
Due date:
% Done:

0%

Estimated time:
Found in version:
HTS Tvheadend 4.1-1008
Affected Versions:

Description

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.411 http: 5.2.200.205: using ticket 97C952958016F93E69E3A0E009289267723A66A7 for /stream/channel/b4b41d1eca4b9271ae9a5aaad9faf3b1

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

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


Files

tvheadend_Screnshot.jpg (34.3 KB) tvheadend_Screnshot.jpg signal Trex the Daemon, 2015-11-20 18:26
tvheadend.log (85.7 KB) tvheadend.log log Trex the Daemon, 2015-11-20 18:26
tvheadend.log (59.4 KB) tvheadend.log Trex the Daemon, 2015-11-25 08:19

History

#1

Updated by Trex the Daemon over 6 years ago

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"

#2

Updated by Jaroslav Kysela over 6 years ago

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

#3

Updated by Trex the Daemon over 6 years ago

Hello,
I've done the trace as requested.
The command line I've used was the one i've extracted from the service file, appending the trace and log switches:
/usr/local/bin/tvheadend -f -p /run/tvheadend.pid -C -u osmc -g video --trace linuxdvb,diseqc -l /tmp/tvheadend.log
As you can see in the screenshot, the signal level is unknown. However, if it's scanning for muxes, I can see there a signal level.
I've swithced between an astra demo channel, that's unencrypted, and one hbo channel from the 0.8W satellite. The subscription card is fitted into the oscam server and it's tested to be working on a dm800hd. But the free channel should work anyways, so it's not a descrambling problem.
Rotor position 17 is the 19.2E and rotor position 10 is thor 0.8W. (Just so you can understand the logs).
I'm no specialist in tvheadend, but I have some technical and linux knowledge, as I'm an embedded enginner, so you can ask me to do some measurements if necessary.
I've checked the logs myself, but I cannot see anything suspicious...

#4

Updated by Jaroslav Kysela over 6 years ago

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

#5

Updated by Mark Clarkstone over 6 years ago

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.

#6

Updated by Trex the Daemon over 6 years ago

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 ?

#7

Updated by Trex the Daemon over 6 years ago

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.

#8

Updated by Mark Clarkstone over 6 years ago

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.

#9

Updated by Trex the Daemon over 6 years ago

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.

#10

Updated by Jaroslav Kysela over 6 years ago

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

#11

Updated by Trex the Daemon over 6 years ago

Jaroslav Kysela wrote:

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

Well, I did make the changes you're requested.. Set the value to 20. And it was working.
But what I don't really understand is that once the dish is on the orbital position with the channel I want to watch, why does this have an influence on it ?

#12

Updated by Jaroslav Kysela over 6 years ago

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.

#13

Updated by Trex the Daemon over 6 years ago

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.

#14

Updated by Jaroslav Kysela over 6 years ago

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

#15

Updated by Trex the Daemon over 6 years ago

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.

#16

Updated by Jaroslav Kysela over 6 years ago

  • Status changed from New to Invalid

Also available in: Atom PDF