Project

General

Profile

Bug #5756

High bandwith at one tuner

Added by Vlad Lanetz 29 days ago. Updated 21 days ago.

Status:
New
Priority:
Normal
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 29 days 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 28 days 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 28 days 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 28 days 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 24 days ago

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

#6

Updated by Pablo R. 24 days ago

Maybe a dup of #5625

#7

Updated by Vlad Lanetz 24 days 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 21 days 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 21 days 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?

Also available in: Atom PDF