Bug #5569
high bandwith during epg grab
0%
Description
I have just noticed that the status - subscriptions screen in the webinterface reports
very high input bandwidtsh on transponders used only for epggrab. see attached picture:
-one live channel uses 2 Mbit/s
-one epg grav uses 40 kbit/s
-two epg grabs use 70 MBit/s each
Either the reported numbers are wrong, or no pid filters are applied or pid filtering goes wrong.
If the reported bandwidth is correct, it could partially explain why epggrab causes a lot of problems
in 4.3.
Files
History
Updated by Jaroslav Kysela almost 6 years ago
You can track the subscribed PIDs for linuxdvb using '--trace linuxdvb'. The received MPEG-TS stream is passed to mpegts_input_recv_packets(), so you can check what's received from the hardware, if the subscribed PIDs are correct. I've not seen this behaviour in my environment (SAT>IP).
Updated by Deep Thought almost 6 years ago
Is there a way to trigger OTA epg on a specific transponder
(without tuning a specific channel)? It would help the debugging.
I am running the tests right now, with 4 epg grabs on 4 tuners.
Most of the, everything is normal. The bandwidths are relatively
low. I did notice one transponder on astra 2 with huge bandwidth, but was not fast enough to write down which one. It may be the
skyuk transponder (117778V).
One thing which is definitely strange: the "stream" screen and the "subscriptions" stream show very different bandwidths.
Subscription seems to be much higher (3-4 times?)
Updated by Deep Thought almost 6 years ago
I cannot reproduce this right now with the following test
-no subscriptions
-epg grab using 4 tuners
And also not with the following
-tune live stream to pick (as in first report)
-epg grab using remaining tuners
The largest bandwidth is for 11778V - sky uk
This is 21 MBit/second according to the stream screen
and (input) 43Mbit/s according to subscriptions
This is still much lower than in the first report.
I do not see problems on 23.5E as in the first report.
Nothing has changed in my setup, but I did correct a few transponders which failed to scan (Had dvb-S instead of dvb-S2)
I guess I will just have to wait for the next occurrence.
Updated by Jaroslav Kysela almost 6 years ago
I think that you have probably turned on (by default) the option "Allow all PIDs", so the scan might force this situation (more PMT PIDs than the limit). TVH uses unfiltered input stream in this case (full mux). I don't think that it's a bug.
Updated by Deep Thought almost 6 years ago
I do not think this is the problem, because then the problem would
be easily reproducible, and it is not.
I have now turned this option off. We will see what happens.
Updated by Jaroslav Kysela almost 6 years ago
It should be visible when you force the new scan for a mux with many services. If the number of PMTs is above the "Maximum PIDs" settings, tvh forces the full mux from the driver (without possibility to switch back to the hardware assisted filtering mode - it didn't work for some drivers).
Updated by Deep Thought almost 6 years ago
What I tried to try and reproduce the problem was "trigger OTA epg grabber". I observed in the webinterface (took a long time of looking!) that the high bandwidth problem did not occur. This was still with the default "Allow all PIDs=true" settings.
This behaviour is very different from what was mentioned in the
start of this bug report: same settings, but high bandwidth for two
subscriptions. If you look at the screen dump of the web interface, you can see that the high bandwidth relates to two epggrabs and that they have each subscribed to the pids 0,1,16,17,18 on two different
transponders. So no long list (certainly not above the
limit 32). Each stream uses 70MBit/second.
I will have to wait until the next time this problem occurs.
It could be a driver problem or a tvheadend problem. Not sure.
PS. The idle scan settings are all set to "new muxes" only