Project

General

Profile

Bug #5756

High bandwith at one tuner

Added by Vlad Lanetz about 5 years ago. Updated about 5 years ago.

Status:
New
Priority:
Normal
Assignee:
John Törnblom
Category:
Streaming
Target version:
-
Start date:
2019-10-20
Due date:
% Done:

0%

Estimated time:
Found in version:
HTS Tvheadend 4.3-1789
Affected Versions:

Description

Three identical usb tuners TBS5580 are used.
On one of them very high bandwith during epg grab and at usual viewing of channels (screenshots 1,2). I guess this has become a problem of a lot of transport and continuity errors when watching TV (screenshots 3).
With the other two, this has never been observed.

2019-10-20 18:55:59.465 linuxdvb: TBS 5580 CI USB2.0 DVB-S/S2/S2X #1 : DVB-S #1 - read() EOVERFLOW
2019-10-20 18:55:59.466 TS: МТС [74.9E]/11800V/FTV UHD: HEVC @ #2402 Continuity counter error (total 1)
2019-10-20 18:55:59.479 tbl-base: pmt: 11800V in МТС [74.9E]: PID 0960 CC error 7 != 4
2019-10-20 18:55:59.479 tbl-base: bat: 11800V in МТС [74.9E]: PID 0011 CC error 12 != 6
2019-10-20 18:55:59.479 tbl-base: sdt: 11800V in МТС [74.9E]: PID 0011 CC error 12 != 6
2019-10-20 18:55:59.479 tbl-pass: pass-pmt: -: PID 0960 CC error 7 != 4
2019-10-20 18:55:59.480 tbl-pass: pass-sdt: -: PID 0011 CC error 12 != 6
2019-10-20 18:55:59.481 TS: МТС [74.9E]/11800V/FTV UHD: AAC-LATM @ #2403 Continuity counter error (total 1)
2019-10-20 18:55:59.500 tbl-base: nit: 11800V in МТС [74.9E]: PID 0010 CC error 10 != 7
2019-10-20 18:55:59.509 tbl-pass: pass-nit: -: PID 0010 CC error 10 != 7
2019-10-20 18:55:59.509 tbl-base: cat: 11800V in МТС [74.9E]: PID 0001 CC error 0 != 12
2019-10-20 18:55:59.512 tbl-base: pat: 11800V in МТС [74.9E]: PID 0000 CC error 0 != 12
2019-10-20 18:55:59.524 tbl-pass: pass-pat: -: PID 0000 CC error 0 != 12

Files

1.jpg (26.4 KB) 1.jpg Vlad Lanetz, 2019-10-20 18:04
2.jpg (28.5 KB) 2.jpg Vlad Lanetz, 2019-10-20 18:04
3.jpg (28.1 KB) 3.jpg Vlad Lanetz, 2019-10-20 18:04

History

#1

Updated by saen acro about 5 years ago

Update to latest, no need to search in "old" "unstable" code something with can be fixed long time ago.

#2

Updated by Luis Alves about 5 years ago

If the 3 cards are the exactly the same and the other 2 behave normally, the issue is probably a faulty card and not related to tvheadend...

But... can you post a screenshot of one of the another cards (#0 or #3) tuning the same mux as card #1 (example: 11920V / MTC) ?

#3

Updated by Joe User about 5 years ago

The last image shows "pid list" set to "all". That is the reason for the high bandwidth. I assume you did the obvious of checking the configuration of all adapters and making sure there is no difference? Check the "maximum pids" settings. You can try to un-check the "Allow all PIDs" setting and see what happens. It may fail in this case, but then we would have to see why tvheadend thinks the maximum pids have been reached and it is trying for all...

#4

Updated by Joe User about 5 years ago

BTW - to test if it is a hardware issue and not driver/software, remove the other 2 adapters and do a test. Or at least remove 1 of the other adapters.

#5

Updated by Vlad Lanetz about 5 years ago

The problem went away after upgrading to the latest version. Closed.

#6

Updated by Pablo R. about 5 years ago

Maybe a dup of #5625

#7

Updated by Vlad Lanetz about 5 years ago

Errors remained, but the bandwith has become normal.
It is most likely in the drivers, as many other possible factors were excluded by the verification method. Errors is only on transponders with SR 45000.

#8

Updated by Jaroslav Kysela about 5 years ago

Note that most USB drivers receive the full mux and the PID filtering is done in the kernel. So with higher SR, there's possibility that something is lost on USB bus / USB kernel stack.

#9

Updated by Vlad Lanetz about 5 years ago

Interestingly, some channels have almost no errors, and some have more than 20 per hour, although the transponder is one.
A few days later, the bandwith is displayed again for 90, it is necessary to restart tvheadend and it is displayed only for 1 channel as everything. Also, when the speed of the entire transponder is displayed, exactly 30 transport errors appear approximately every 15 minutes (they are not displayed in the error counter on the record, only in status > stream).
Maybe someone faced with similar?

#10

Updated by Vlad Lanetz about 5 years ago

I finally found the reason for displaying the bitrate of the entire transponder.
If you first playing muxes and then run the channel on the same adapter, the bitrate of the entire transponder and not the specific channel continues to be displayed. Can this be fixed?

#11

Updated by Flole Systems about 5 years ago

I'm sure this can be fixed, I'm not sure if this is a tvheadend issue though, if the driver doesn't do the filtering anymore (for example because you exceeded the max pids allowed by the driver so it doesn't filter anymore until you stop and start again) tvheadend will receive the entire transponder and show the bitrate of it.

#12

Updated by Joe User about 5 years ago

The only way to "fix" it would be to close the tuner and re-tune with just the single channel - which would definitely cause a hiccup in any streams being watched/recorded. While in your case that small hiccup might be better than the continuous continuity errors you have, for other (most) users, without the problem, it would now cause errors for them they did not have before.

Also, you switch back and forth between "bandwidth" and "bitrate", and while basically the same, in Tvheadend->Status->Stream it shows the "Bandwidth(kb/s" for the ENTIRE tuner, while in Tvheadend->Status->Subscribtions it shows the "input (kb/s)" of each individual "subscription" whether that subscription is a "mux" or an individual channel.

Also available in: Atom PDF