[mikeb8591]

With the latest NextPVR Add-On 3.3.12 on Kodi RC5, the Timeshift works much better. But still it hangs sometimes when skipping forward/backward. When it happens Kodi has to be forcefully killed. And quite often skipping takes a long pause, feels like 15 seconds or so. I'm not sure if anyone has reported it. I have the Kodi.log file, quite big (630MB), though, since it took a while to repro this problem. Maybe only the end of the log is of interest. The zipped file is about 35MB. Please advise where I should send it if anyone's interested to take a look.

Thanks !

If it's a debug log, then yes, I'd like to take a look, please put up a link where I can get them.  Which platform?

Thanks!

[blunt]

Yes it's a debug log. It was on Windows 10 x64. The zipped log file can be downloaded from:
https://1drv.ms/u/s!At4zlMm23lvUmlOLaUzej1DMIGiW

Thank you very much !

[mikeb8591]

Yes it's a debug log. It was on Windows 10 x64. The zipped log file can be downloaded from:
https://1drv.ms/u/s!At4zlMm23lvUmlOLaUzej1DMIGiW

Thank you very much !

 No problem.  One thing, please check your back end, and make sure it's set for 'time based' and not 'epg based' time shifting.

Also:

11:52:15.226 T:7144  NOTICE: ADDON: peripheral.joystick v1.4.6 installed
11:52:15.226 T:7144  NOTICE: ADDON: pvr.nextpvr v3.3.11 installed
11:52:15.226 T:7144  NOTICE: ADDON: repository.xbmc.org v3.1.4 installed

It doesn't look like you have 3.3.12 installed.  Please try again with 3.3.12.

Thanks!

[emveepee]

One thing, please check your back end, and make sure it's set for 'time based' and not 'epg based' time shifting.

The parameters on the URL from Kodi control this so no changes on the backend are required.

Martin

[mikeb8591]

One thing, please check your back end, and make sure it's set for 'time based' and not 'epg based' time shifting.

The parameters on the URL from Kodi control this so no changes on the backend are required.

Martin 

That has not been my experience, nor was it the experience @davel appeared to have.

Thanks!

[emveepee]

That has not been my experience, nor was it the experience @davel appeared to have. 

 I'd like sub to weight in on that.  I have epg based as my default, and I definitely get the /live slip file in web.log

Martin

[blunt]

Yes it's a debug log. It was on Windows 10 x64. The zipped log file can be downloaded from:
https://1drv.ms/u/s!At4zlMm23lvUmlOLaUzej1DMIGiW

Thank you very much !

 No problem.  One thing, please check your back end, and make sure it's set for 'time based' and not 'epg based' time shifting.

Also:

11:52:15.226 T:7144  NOTICE: ADDON: peripheral.joystick v1.4.6 installed
11:52:15.226 T:7144  NOTICE: ADDON: pvr.nextpvr v3.3.11 installed
11:52:15.226 T:7144  NOTICE: ADDON: repository.xbmc.org v3.1.4 installed

It doesn't look like you have 3.3.12 installed.  Please try again with 3.3.12.

Thanks! 

The NextPVR add-on version was interesting. I did have it shown up in the Kodi GUI as 3.3.12. I just did an update of the add-on. Enabled log temporarily just to check the version to be 3.3.12. I'll see if that make things better. Thanks !

BTW, I was using EPG-Based Timeshift. I then switched the backend to Time-Based. But it still froze sometimes. I'm gonna play with the newly updated 3.3.12 to see if that works fine.

[davel]

One thing, please check your back end, and make sure it's set for 'time based' and not 'epg based' time shifting.

The parameters on the URL from Kodi control this so no changes on the backend are required.

Martin       

That has not been my experience, nor was it the experience @davel appeared to have.

Thanks!      

While my tests with earlier versions of the add-in showed a marked difference between having NPVR set to EPG/time based, it was only that EPG showed the problem more easily (albeit statistically I'd only done a small number of operations, so take this with a pinch of salt).
I've just set NPVR back to EPG mode and have done the same things I was doing before to reproduce the problem, and from the 5-10 minutes of testing I've done, skipping forward and backward on live TV, the behaviour with the latest NPVR add-in doesn't seem any different regardless of the NPVR mode now. Neither mode has (so far) resulted in hanging playback.

[mikeb8591]

While my tests with earlier versions of the add-in showed a marked difference between having NPVR set to EPG/time based, it was only that EPG showed the problem more easily (albeit statistically I'd only done a small number of operations, so take this with a pinch of salt).
I've just set NPVR back to EPG mode and have done the same things I was doing before to reproduce the problem, and from the 5-10 minutes of testing I've done, skipping forward and backward on live TV, the behaviour with the latest NPVR add-in doesn't seem any different regardless of the NPVR mode now. Neither mode has (so far) resulted in hanging playback. 

While the symptoms may have appeared to be the same from the user perspective, they were markedly different from mine, viewing the debug logs.  Prior to switching (and I thought I'd mentioned this) there were requests for blocks which clearly should have been available from the back end given your slip seconds value, and the amount of time you'd been tuned.  The hang logs didn't make sense, until you switched the backend to time-based.

Thanks!

[emveepee]

While the symptoms may have appeared to be the same from the user perspective, they were markedly different from mine, viewing the debug logs.  Prior to switching (and I thought I'd mentioned this) there were requests for blocks which clearly should have been available from the back end given your slip seconds value, and the amount of time you'd been tuned.  The hang logs didn't make sense, until you switched the backend to time-based.

Thanks! 

I still don't believe this is an issue.  I'd make sure that extended logging in NextPVR and you will see that the slip file is still time-based when you make the requests. You should watch this in relation to the requests that the client makes.  Given davet rather large slip file there could be problems in the protocol itself.   The last log he posted shows a protocol issue not a slip file issue processing a seek while a seek was pending.

Martin

[blunt]

Just to report back on my experience about add-on 3.3.12 after a few weeks uses. I didn't experience any video-hang with this version so far. But skipping forward/backward still often had long pauses of 10 - 15 seconds before it could continue. This sometimes made the timeshift experience quite frustrating. Not sure if it is a known issue here ? If not, I can collect and upload the log file.
Thanks !

[emveepee]

Kodi does do many seeks to pinpoint exact locations.

Martin

[Tauneutrino]

Hi guys,

just did a clean install today with NPVR 4.2.4 190307 and Kodi 18.2 on Windows SERVER 2016. I can confim Kodi stops responding and i have to kill the it. All this happens after switching to a channel and going back with timeshift.

Seems like it does not happen if i change to "extendend timeshift" in the addon options. however I do not like to wait a least 4s before I am able to see something.
With my old Setup on Kodi 17 everything worked fine!

[emveepee]

The API for timeshifting changed in v18 for all addons so change was required.  Many users had problems with timeshifting in v17 and I could easily make it crash.  In v18 another dev improved the timeshifting support but it is still possible for it to crash.  I added extended timeshift to because I felt it could be more reliable, but the server is not open source and I have no control over the file buffering prior to sending to Kodi.    Your options to me are

1) go back to v17
2) if you don't like the wait, live with the hangs or abandon timeshift and go realtime
3) download the source and improve the timeshifting code.

Option 3 is kind of dead end as it won't be supported in v5 of NextPVR.

Martin

[Tauneutrino]

Any Backend working more reliable on v18?