[louis]

Hi ksooo,

please implement a setup option to disable this feature...defaulting to "active" to keep awareness. I'd love to disable it...

Beside the fact that the popup is also annyoing for me, i'm experiencing the additional bug that infrequently the sound is gone after confirming "yes please switch". Stopping and restarting livetv helps then...

Cheers Louis

[louis]

Hm..."Edit" a posting is not working for me...anyway, triple post

[Atreyu]

To which pvr backend does this apply?
I rushed to test with tvmosaic as i would really like the feature, got nothing..

[ksooo]

Sorry, I will not make each and everything user customizable. This would end in a support nightmare and is making the code and the app more complex, to complex for many users, imo.

With every feature there is at least one person that does not like it and I hate to say that, those people either get used to how Kodi works or have to look for alternative "products".

TVMosaic addon should support this feature with the very latest version (code merged yesterday). No idea when this will be available in the addon repos.

[emveepee]

I get it in a future version of pvr.nextpvr  The funny thing it doesn't seem to work as described.  https://youtu.be/saNvlo7vP90 when I would expect it to work.
but it does when I don't https://youtu.be/ed1NpHiwK2A

Martin

[ksooo]

I get it in a future version of pvr.nextpvr  The funny thing it doesn't seem to work as described.  https://youtu.be/saNvlo7vP90 when I would expect it to work.
but it does when I don't https://youtu.be/ed1NpHiwK2A

Martin

We can either continue to write several times a day that there is a problem in combination of Kodi and nextpvr, which will lead to nothing or a dev that can reproduce the issue (you!) starts to work on finding the cause which will lead us to a solution. [emoji848]

[ksooo]

The video tells actually nothing about a bug. I trust you that there is an issue, but the fact alone that after selecting a channel the popup appears could be very well valid if the show running on the selected channel gets currently recorded by the backend. This is also unrelated to cleaning pvr data in Kodi. So, the video does not help a bit, but can easily cause confusion.

[Atreyu]

Thanks for the info @ksooo, didn’t realize this was added. Very nice surprise. I’ll have to update soon!

[emveepee]

I already wrote I will try and do that but getting 3.13 out and but figuring out if Radio skipping works or not is higher on my list so I know whether or not to disable it for release.  MilkDrop issues cost some time too.   After that, I really want to improve the pvr.nextpvr state machine to go with WOL (and I still don't know a good way in the PVR app to trigger WOL on demand maybe entering Recordings and triggering on the drive space calls)  And with this change I also want to fix the implementation after system sleep so it respects disconnected state and doesn't delete the PVR database (which I believe cause the prompt in this thread), allows me to issue WOL, reauthenticate and change to connected state without corrupting threads. After that I want to try and figure out why Recordings take so long to show up to avoid exiting the program.

I am honestly not a bad guy, although perhaps I was a bit overly ticked off when you questioned me earlier today, and there is certainly no reason for either of us to be so adversarial as I really want to help you out with the PVR addon as I want to use it, but there is a steep learning curve.   This thread was meant just as a question about guisettings.xml.    

Martin

[emveepee]

The video tells actually nothing about a bug. I trust you that there is an issue, but the fact alone that after selecting a channel the popup appears could be very well valid if the show running on the selected channel gets currently recorded by the backend. This is also unrelated to cleaning pvr data in Kodi. So, the video does not help a bit, but can easily cause confusion.

 To clear the confusion  Video 1 shows the prompt not coming up when it should for a recording in progress.  Video 2 shows it coming up for last week's show hours before tonight's scheduled recording.  At this point I seem to only get it when the database is cleaned by a reset or by system wake which  why I figure it is related.  For now I will just assume it is a pvr.nextpvr problem and not worry about it.

Martin

[emveepee]

As you seem to be a developer, you could debug "CPVRRecordings::GetRecordingForEpgTag" yourself. There, you will see what goes wrong in your case. 

 Thanks for that.  I have never run Kodi with a debugger so I took this as a learning to build and run it, since you saved me the step of having to hunt down the location.  Basically the problem seems to be based on pvr-nextpvr providing recording time as unix time in seconds and EPG times with ms.  Kodi PVR was smart enough to work  each one but I guess if you compare them things break down.

It is kind of weird to go into the guide click on Switch channel vs Play Recording and then get a second dialog asking me the same question.

Martin

[ksooo]

As you seem to be a developer, you could debug "CPVRRecordings::GetRecordingForEpgTag" yourself. There, you will see what goes wrong in your case. 

 Thanks for that.  I have never run Kodi with a debugger so I took this as a learning to build and run it, since you saved me the step of having to hunt down the location.  Basically the problem seems to be based on pvr-nextpvr providing recording time as unix time in seconds and EPG times with ms.  Kodi PVR was smart enough to work  each one but I guess if you compare them things break down.

It is kind of weird to go into the guide click on Switch channel vs Play Recording and then get a second dialog asking me the same question.

Martin

So, it seems to be a bug in pvr.nextpvr as pvr addon API defines the time format for both epg and recordings UTC time_t. Refer to the respective API header files for details.

[emveepee]

I have been reading the headers and doxygen but since UTC can be expressed in seconds and milli-seconds and even microseconds it is not really a bug. It was certainly odd to find pvr-nextpvr API provided different formats.  Thanks again for the link to the code to check.

Martin

[ksooo]

I have been reading the headers and doxygen but since UTC can be expressed in seconds and milli-seconds and even microseconds it is not really a bug. It was certainly odd to find pvr-nextpvr API provided different formats.  Thanks again for the link to the code to check.

Martin

It is a bug as time_t is defined as seconds since 1/1/70 00:00:00 and all start and end times in the PVR addon API are time_t. And PVR_RECORDING.iDuration is clearly documented as seconds as well.

[emveepee]

Excellent point thanks. 

Martin