BUG: KODI 17 PVR Add-on Frozen after 6 hours unused

[solomalee]

I've had this issue reported in the PVR Add-on for KODI 17 thread https://forum.dvblogic.com/viewtopic.php?f=66&t=30894, but as there has been little progress and a lot of information collected, I felt a more distinctive and specific thread for this bug is necessary, especially as we are now getting close to a final release of KODI 17.

Problem Description
After the TV and KODI client has not been used for 6-7 hours (Turned off overnight at ~23:30 and turned back on in the morning), navigate to TV, select a TV channel from the channel list, guide, or a recently watched channel and click OK to switch to that channel. The spinning wheel appears and the TV channel never switches and Kodi is frozen. (I notice that the onscreen KODI Debug information is still happily updating on screen at top left)

I have monitored how long it takes before the problem occurs and deduced that Kodi has to be left running unused for 6 hours until the problem appears (This can be replicated during daytime so seems to not be related to an overnight scheduled activity).

Additionally, when choosing the Recorded TV icon from the KODI TV menus, KODI freezes and no list of recordings is shown indicating that there seems to be a "general lost connection" between client and back end DVBlink server.

Problem only affects KODI PVR Addon, other DVBlink clients using the same Synology based DVBlink back end server continue to work perfectly (Tested: Windows MCE, DVBlink for TVOS, iOS & OSX, DVBlink Browser client). I also don't recall seeing this issue with KODI 16 JARVIS.

KODI Clients Tested:

• Apple Mac OSX 10.11.6 / KODI 17 RC-2 / DVBlink AddOn Version 3.3.9 / DVBlink Server 6.0 Build 13314 Synology (Solomalee)
• Raspberry PI3 Libreelec 07.90.010 / KODI 17 Beta 7 / DVBlink AddOn Version 3.3.8 / DVBlink Server 6.0 Build 13314 Synology (Solomalee)

I notice that KODI reports the PVR Back End server is DVBlink Server V5.0 - that is not correct, V6.0 is installed

User Ateryu has reported the same issue affecting Intel NUC / Windows 10 / KODI 17 Beta
http://forum.kodi.tv/showthread.php?tid ... pid2484249

Work Around
Reboot or restart Kodi before selecting a live TV channel or playing a recording if the client hasn't been used for a number of hours.

KODI Log Files for 2 affected RPI clients
https://dl.dropboxusercontent.com/u/144 ... _attic.zip
https://dl.dropboxusercontent.com/u/144 ... m_post.zip

DVBlink LOG Files
https://dl.dropboxusercontent.com/u/144 ... 8-1145.zip
https://dl.dropboxusercontent.com/u/144 ... 9-2232.zip

[debutanker]

Hi solomalee,
with Kodi 17RC3 there seems to be a fix ( https://github.com/xbmc/xbmc/pull/11359 ) which is quite similar to your reported issue - if this really solves your problem i dont know, but its maybe worth trying it out...?!

greetz
debutanker

[solomalee]

Hi Debutanker,

Wow...very technical...not sure what to make of the inked thread (couldn't see anything I could actually do) except wait for the discussed deadlock fix to appear in the next RC version.

I think that this issue is probably different as the PVR Client freezes (after the six hours unused) also when opening the "Recorded Programs" section.

Solo

[debutanker]

Maybe you could do a test run with a Milhouse testbuild which has this fix included (since this version ---> http://forum.kodi.tv/showthread.php?tid ... pid2493363 /Rpi testbuild) ??

[solomalee]

Updated to Libreelec 7.95.1 - problem still exists

[solomalee]

Based on feedback from "the_man", I'll be reaching out more to the Kodi team than the DVBlink team in future...

...below are the key points for support and the Kodi PVR add on...

...As for Kodi - there really a lack of support as since Kodi 14.0 all PVR addons are built by Kodi team...
Anyway We are trying to test the PVR for release Kodi versions...

[beeswax]

Based on feedback from "the_man", I'll be reaching out more to the Kodi team than the DVBlink team in future...

...below are the key points for support and the Kodi PVR add on...

...As for Kodi - there really a lack of support as since Kodi 14.0 all PVR addons are built by Kodi team...
Anyway We are trying to test the PVR for release Kodi versions...

That's not true though is it? I recall not very long ago getting involved with a dvblink/kodi issue on the Kodi forum and whenever it seemed like it was the plugin's fault, ksooo was requesting input from dvblogic on the Kodi github. See the associated ticket here: https://github.com/kodi-pvr/pvr.dvblink/issues/58. This clearly shows dvblogic fixing a bug in the Jarvis and Krypton addons.

Something smells real fishy around here....

[GuiltyNL]

The Kodi Wiki states that the DVBLogic PVR plugin is maintained by DVBLogic and not by Kodi:

DVBLink PVR Client Addon backend client maintained and made available by DVBLogic

Source:

http://kodi.wiki/view/Kodi_v17_(Krypton)_changelog#Live_TV_and_PVR_.28Personal_Video_Recorder.29

[solomalee]

This is really confusing now as "the_man" was very clear in a PM on this subject that DVB Logic don't maintain the DVBlink Haddon for Kodi

@"the_man" can you please clarify?
Shall we all start raining support tickets with DVBlogic?

Solo

[the_man]

This is really confusing now as "the_man" was very clear in a PM on this subject that DVB Logic don't maintain the DVBlink Haddon for Kodi

@"the_man" can you please clarify?
Shall we all start raining support tickets with DVBlogic?

Solo

We will try to check what can be done from our side as much as possible:

At the moment we are adding issues/bugs regarding the PVR for Kodi into ToDo/test list.
During the next week, we will conduct some tests regarding all requests.

If it is possible, please send us(info@dvblogic.com or right here in this thread):
- data about Kodi version/PVR Addon version / platform where Kodi/PVR is running
- a log files from kodi and from the dvblink server right after the issue is played back.
- Also a scenario for reproducing indicated issue.

It will help us to get statistic of reproducing indicated bugs.

PS. We have conducted some tests a few weeks ago, some bugs were reproduced once, but with the same scenario they were not, in a second time. Such float things requires much more times to be allocated.
PPS. The indicated in the title of the thread issue was reproduced as well, also only once, since then PVR and Kodi running for a week, with different idle time(4 / 8 / 12 /24 hours )

[VPN-User]

PPS. The indicated in the title of the thread issue was reproduced as well, also only once, since then PVR and Kodi running for a week, with different idle time(4 / 8 / 12 /24 hours )

I get this issue every day. After each night (where Kodi box was in S3 mode), the first thing I have todo after waking up the box is to restart Kodi to get the DVBLink PVR addon working again. The issue started with using some Kodi 17 beta.

[dvbGuy]

Same here on waking from sleep. I've added a sleep.d file to auto-reboot the NUC when waking, otherwise it's guaranteed to be locked up.
The other NUC and RPi3 don't sleep and lock up in the 4-6 hour idle mark consistently.

[solomalee]

Sorry (but also happy) that I am not alone with this problem...

Still happening to me on all three Pis...even now that I am on LibreElec 8.0.0

Tests for the weekend as follows:
- Scratch rebuild at the weekend with no restore from backup to be sure there is no residual setting issue
- Scratch build on OSX
- If I have time, I'll also build a Kodi 16 and see if that has the same problem

[beeswax]

This was posted by a Team-Kodi member over at the Kodi forums and just in case it contains an important clue, I'm posting it here as it could have been easily missed:

The addon is responsible for handling connections to the backend. I had a brief look into the code of DVBlink and could not find anything that handles reconnecting.

This suggests that the addon needs to have some logic somewhere that checks first that the connection to the back-end is indeed still open and usable before trying to do things.

[solomalee]

Good catch - on the face of it - this seems like a very likely root cause given that the issue occurs only after quite some time unused has passed.

Solo