Bug #2350
closed
Bug #2365: croned OTA epggrab remains active when invoked on already open subscription
no timeout on eit
Added by alf alfonsius over 10 years ago.
Updated over 10 years ago.
Found in version:
3.9.1741~g078e61b-dirty
Description
i have some streams staying open on epg grabbing from dvb-c, some channels have epg some don't i guess,
is there no timeout for scanning ? they are staying always connected w/o subscription
log says:
Oct 7 14:24:21 iptv tvheadend22724: mpegts: 235.10.10.11 in Tralala - tuning on IPTV
Oct 7 14:24:21 iptv tvheadend22724: subscription: 'epggrab' subscribing to mux, weight: 3, adapter: 'IPTV', network: 'Tralala', mux: '235.10.10.11', hostname: '<N/A>', username: '<N/A>', client: '<N/A>'
....
Oct 7 14:34:36 iptv tvheadend22724: epggrab: EIT: DVB Grabber - data completion timeout for 235.10.10.11 in Tralala
i can see epg in vlc w/o problems
Files
Could you configure a tvh instance with only one channel and provide 'linuxdvb', 'epggrab' and 'eit' trace with a detailed description what does not work ?
oops, i didnt make myself clear. the epg comes from multicast input, not dvb.
here is a trace of eit from latest git with 1 mux/service/channel: http://pastebin.com/N0GcEuMk
and the problem was that the streams stay open w/o subscription thus adding traffic to my lo interface(no prob with 1 stream, but with 200+...) on my installed tvh i got 5 streams staying connected all the time and thats ~20Mbits/sec allready (see pic), or i just got it all wrong bit logfile says:
2014-10-08 11:19:40.000 epggrab: EIT: DVB Grabber - data completion timeout for 235.10.10.30 in Tralala
2014-10-08 11:19:40.000 epggrab: EIT: DVB Grabber - data completion timeout for 235.10.10.35 in Tralala
2014-10-08 11:19:40.000 epggrab: EIT: DVB Grabber - data completion timeout for 235.10.10.6 in Tralala
2014-10-08 11:19:40.000 epggrab: EIT: DVB Grabber - data completion timeout for 235.10.10.11 in Tralala
so i guessed the epggrabbber keeps em open...
anyway, keep up the good work !! :)
OK, I see. The EIT parsing looks good. Could you provide also 'epggrab,subscription,service' traces ? (using one channel <- one service config)..
same config,same service:
2014-10-08 15:39:27.365 [ INFO] mpegts: 235.10.10.11 in Tralala - tuning on IPTV
2014-10-08 15:39:27.365 [ INFO] eit: registering mux 235.10.10.11 in Tralala
2014-10-08 15:39:27.365 [ INFO] subscription: 'scan' subscribing to mux, weight: 5, adapter: 'IPTV', network: 'Tralala', mux: '235.10.10.11', hostname: '<N/A>', username: '<N/A>', client: '<N/A>'
2014-10-08 15:39:27.483 [ TRACE] epggrab: ota 235.10.10.11 in Tralala add new service Tralala/235.10.10.11/VH1 Classic
2014-10-08 15:39:42.000 [ INFO] mpegts: 235.10.10.11 in Tralala - scan complete
2014-10-08 15:39:42.000 [ INFO] subscription: "scan" unsubscribing
2014-10-08 15:39:42.000 [ DEBUG] epggrab: grab done for 235.10.10.11 in Tralala (stolen)
2014-10-08 15:39:43.000 [ TRACE] epggrab: ota - kick callback
2014-10-08 15:39:43.000 [ INFO] mpegts: 235.10.10.11 in Tralala - tuning on IPTV
2014-10-08 15:39:43.000 [ INFO] subscription: 'epggrab' subscribing to mux, weight: 3, adapter: 'IPTV', network: 'Tralala', mux: '235.10.10.11', hostname: '<N/A>', username: '<N/A>', client: '<N/A>'
2014-10-08 15:39:43.000 [ TRACE] epggrab: mux stats - all 1 pending 0
2014-10-08 15:40:28.000 [ DEBUG] epggrab: grab done for 235.10.10.11 in Tralala (timeout)
2014-10-08 15:40:28.000 [WARNING] epggrab: EIT: DVB Grabber - data completion timeout for 235.10.10.11 in Tralala
2014-10-08 15:40:28.000 [ INFO] subscription: "epggrab" unsubscribing
i dumped some minutes of the stream in question
alf alfonsius wrote:
same config,same service:
2014-10-08 15:40:28.000 [WARNING] epggrab: EIT: DVB Grabber - data completion timeout for 235.10.10.11 in Tralala
2014-10-08 15:40:28.000 [ INFO] subscription: "epggrab" unsubscribing
So OTA epggrab requests to unsubscribe the mux when the timeout is reached.. Could you also add 'mpegts' to the trace list ? It looks like an IPTV client code issue..
here you go
btw i could give you access to the streams over udpproxy if it helps
The log seems correct. I think that your issue is similar to 2365 .
Fixed in v3.9-1837-g3f4387b
- Status changed from New to Fixed
Also available in: Atom
PDF