[CiNcH]

A bug in the DVBViewer Recording Service could result in HTTP requests (e.g. timerlist.html, status.html) taking a very long time. The problem with KODI is that this also interrupts the live stream until a timeout occurs:

Code:

ERROR: AddOnLog: DVBViewer Client: Unable to parse timers. Error: Error document empty...
ERROR: CCurlFile::Open failed with code 0 for http://127.0.0.1:8080/api/timerlist.html...
ERROR: CCurlFile::FillBuffer - Failed: Timeout was reached(28)

I then played the UPnP/HTTP stream within VLC and made HTTP requests to the DVBViewer Recording Service using a browser. The response also took very long due to the bug, but the stream was not interrupted, suggesting that KODI does not properly decouple HTTP requests from streaming.

I don't really know whose job it really is, whether it is a "problem" of the Core, the PVR or the PVR Add-On. But I don't think that it is a good idea that the stream is interrupted because of a failing/delayed HTTP request.

I assume that the KODI Core/PVR relies on the circumstance that calls to the PVR Add-On do not block for too long. So maybe retrieving timerlist.html/status.html should be done timer-based in a separate thread, storing the data in some shared memory, where the info can quickly be copied from when being queried by the Core/PVR. The DVBViewer Add-On is leaving the KODI process and maybe even the "client device" (over LAN) and maybe even the LAN (over internet). We should not expect a fast reply.

[manül]

Which platform are you using? On windows and if live shift is enabled, a seperate thread is used for fetching the data from RS. But I don't know if there's some synchronization mechanism further down in Kodi or curl itself.

Is the bug in RS reproduceable? Maybe we should rather get that fixed.

[CiNcH]

Which platform are you using? On windows and if live shift is enabled, a seperate thread is used for fetching the data from RS.

Windows7... I actually do have timeshifting enabled, but I am not 100% sure for the tests I did. Is it also the case when I am in live position? Or only if I am in a time-shifted position? I need to retest.

Is the bug in RS reproduceable? Maybe we should rather get that fixed.

The bug happens only with the experimental UPnP controller in the RS and only under certain circumstances, which we are not really aware about. I have a Windows 7 notebook in the network for which i disabled the UPnP media server. When the RS now starts on another PC, the UPnP controller seems to look for UPnP peers. Now, when the notebook is being shut down, the RS enters some kind of an inconsistent state where the web-interface becomes almost unusable. So theory is that the RS finds the notebook and gets confused when you shut it down afterwards.

UPnP controller in the RS should not be used anyway and hardly anybody does so. Moreover, some other circumstances have to apply (disabled UPnP media server?) for the problem to appear. Still I thought it wasn't good that a HTTP request can block the streaming.

[manül]

Which platform are you using? On windows and if live shift is enabled, a seperate thread is used for fetching the data from RS.

Windows7... I actually do have timeshifting enabled, but I am not 100% sure for the tests I did. Is it also the case when I am in live position? Or only if I am in a time-shifted position? I need to retest.

Yes, always. The process is very simple: A loop in an independent thread fetches the data from RS and writes to the buffer file. Upon request from Kodi the main thread of the PVR reads the requested position from the buffer file.

Now, when the notebook is being shut down, the RS enters some kind of an inconsistent state where the web-interface becomes almost unusable.

How far from live position have you been? In case RS blocked even existing HTTP connections and Kodi tries to read above the current write position (aka the end of the buffer file), the main thread will be blocked until new data is available.
With debug mode enabled you'll see this message: Timeshift: Read timed out; waited <num_secs>

Still I thought it wasn't good that a HTTP request can block the streaming.

Yes, that's definitely not intended. I'm on vacation right now, but I'll take a closer look when I'm back home.

[CiNcH]

How far from live position have you been? In case RS blocked even existing HTTP connections and Kodi tries to read above the current write position (aka the end of the buffer file), the main thread will be blocked until new data is available.
With debug mode enabled you'll see this message: Timeshift: Read timed out; waited <num_secs>

I have always been live. Means, I did not seek... It happens with and without timeshift being enabled. Therefore I also did not spot this error in the log.
CPU usage goes up considerably in the blocking case.

Yes, always. The process is very simple: A loop in an independent thread fetches the data from RS and writes to the buffer file. Upon request from Kodi the main thread of the PVR reads the requested position from the buffer file.

Right. I now checked the code a bit myself. I might join you at some point ...

[Etharr]

I have similar (maybe related) issue with latest version of Recording Service 1.31.0.
After some time of watching TV in Kodi 14.2 I've got timers error.
After that PVR section is unusable - no channels list, no EPG.
I have to clear whole PVR database and enable DVBViewer Addon again to make it work.