2018-06-10, 12:35
Hi
today I've tested the latest IPTV Simple Client on Ubuntu and I think I've found a problem in the implementation. Perhaps this problem is already for a long time in the code, because it sounds similiar to the old problem with the Rytec-XML-Downloads
I wanted to connect the xmltv-epg from my enigma receiver with a m3u source on my ubuntu client. If I download the xmltv-file with wget -O and import the downloaded file in IPTV Simple, everything works as expected. Problem starts, if I configure the URL as source in IPTV Simple and let IPTV Simple download the file. The xmltv file is generated on the fly and a receiver has not a powerful desktop cpu. On my ARM based receiver, file generation lasts about 2 min, but on a MIPS based receiver or a export of all channels it could even last longer. If I look at the log, I see entries like
11:35:01.766 T:139963152709376 DEBUG: CurlFile::Open(0x7f4ba4003a00) http://dcube/web/epgxmltv?bRef=1:7:1:0:0...0:&lang=de
11:35:22.051 T:139963152709376 ERROR: CCurlFile::FillBuffer - Failed: Timeout was reached(28)
It seems, that IPTV Simple times out after 20 sec (because the file could not be generated in this short time), but the export on the receiver is still running. After IPTV Simple times out, it retries the download 2 times, so the receiver is bombed with 3 concurrent running file generations. Even worse, after 5 mins, IPTV Simple restarts this procedure (with 3 concurrent running "2 min-exports", the files are not ready after 5 mins) and starts exports 4 to 6, ...
I think this behaviour is very problematic, not only for a slow receiver as source, but also for epg hosters. The dynamic generation and download of a big xmltv file could last more than 20 secs and if KODI bombs their servers with more download requests than needed, it's only a matter of time until KODI gets blocked (as happened with Rytec a few years ago). And if KODI bombs their servers in an endless loop, that's even more dramatic.
At least a setting for a higher epg download timeout should be integrated. 20 secs are OK for the streaming urls, but epg could take a lot longer. And a setting for max retries should also be added, because this endless loop could also be very problematic
Debug-Log
https://paste.ubuntu.com/p/CfrZSkJryD/
today I've tested the latest IPTV Simple Client on Ubuntu and I think I've found a problem in the implementation. Perhaps this problem is already for a long time in the code, because it sounds similiar to the old problem with the Rytec-XML-Downloads
I wanted to connect the xmltv-epg from my enigma receiver with a m3u source on my ubuntu client. If I download the xmltv-file with wget -O and import the downloaded file in IPTV Simple, everything works as expected. Problem starts, if I configure the URL as source in IPTV Simple and let IPTV Simple download the file. The xmltv file is generated on the fly and a receiver has not a powerful desktop cpu. On my ARM based receiver, file generation lasts about 2 min, but on a MIPS based receiver or a export of all channels it could even last longer. If I look at the log, I see entries like
11:35:01.766 T:139963152709376 DEBUG: CurlFile::Open(0x7f4ba4003a00) http://dcube/web/epgxmltv?bRef=1:7:1:0:0...0:&lang=de
11:35:22.051 T:139963152709376 ERROR: CCurlFile::FillBuffer - Failed: Timeout was reached(28)
It seems, that IPTV Simple times out after 20 sec (because the file could not be generated in this short time), but the export on the receiver is still running. After IPTV Simple times out, it retries the download 2 times, so the receiver is bombed with 3 concurrent running file generations. Even worse, after 5 mins, IPTV Simple restarts this procedure (with 3 concurrent running "2 min-exports", the files are not ready after 5 mins) and starts exports 4 to 6, ...
I think this behaviour is very problematic, not only for a slow receiver as source, but also for epg hosters. The dynamic generation and download of a big xmltv file could last more than 20 secs and if KODI bombs their servers with more download requests than needed, it's only a matter of time until KODI gets blocked (as happened with Rytec a few years ago). And if KODI bombs their servers in an endless loop, that's even more dramatic.
At least a setting for a higher epg download timeout should be integrated. 20 secs are OK for the streaming urls, but epg could take a lot longer. And a setting for max retries should also be added, because this endless loop could also be very problematic
Debug-Log
https://paste.ubuntu.com/p/CfrZSkJryD/
