[MatthewLundberg]

Kodi caches EPG data by default.  Starting up, it will usually display the last-known data.

But it also will call PvrGetEPGForChannel for the time frames that it already knows.  The calls to this function always seem to indicate the entire time window that the PVR layer is configured to show, even if the EPG data is already known.  Is this intentional behavior?

[ksooo]

Is this intentional behavior?

Yes, as data on server might have changed since last call.

The local epg db is purely for speeding up pvr startup. Directly after startup, the data get fetched from the server to sync local with backend state.

But there are ways for the add-on to asynchronously notify Kodi about epg changes and to ignore the synchronous epg data fetch calls from Kodi. This is what pvr.hts does when "async epg transfer" is activated in the add-on settings.

[MatthewLundberg]

Thanks for the response.  I have a few questions on this.

Is there a way for the PVR to determine what entries have been cached?  I could slow the retrieval for these entries.
When using the async call EpgEventStateChange, what's the significance of the "state" attribute?  Should the PVR send the EPG_EVENT_MODIFIED when it sends the same channel/timeslot data twice in the same session?  Or back to question 1, is there a way to determine if it's changing an existing entry upon startup?  What's this flag really do?

And one more, is it possible for the PVR to inform Kodi to not cache the data?

[ksooo]

Is there a way for the PVR to determine what entries have been cached?  I could slow the retrieval for these entries.

And one more, is it possible for the PVR to inform Kodi to not cache the data?

I assume by "the PVR" you mean the global instance you can use in your addon to communicate with Kodi PVR core, for example to trigger a recordings update?

No, addons have no way to determine which entries have been cached. This is by design. An addon should and must not know about any Kodi implementation details, like existence of an epg cache or not.

Not sure what you mean with 'slowing down retrieval of cached entries'.

pvr.hts basically does nothing(!) in its implementation of GetEPGForChannel. It pushes all epg events thru EpgEventStateChange callback whenever tvheadend server notifies any changed/deleted/updated epg events. On startup of the adon, after connecting to the backeend server, all available events will be pushed as NEW, afterwards there are UPDATEs and DELETEs.

When using the async call EpgEventStateChange, what's the significance of the "state" attribute?  Should the PVR send the EPG_EVENT_MODIFIED when it sends the same channel/timeslot data twice in the same session?  Or back to question 1, is there a way to determine if it's changing an existing entry upon startup?  What's this flag really do?

For UPDATED and NEW the state is used to speed up updating/extending existing data in kodi pvr core.
For DELETED it's the trigger to remove an event from pvr core's epg data.

[MatthewLundberg]

For "Slowing down" I mean throttling the retrieval in the PVR itself.  If there's nothing in the cache, the user would want the guide filled out faster.  If the cache is full, the user might want to throttle the requests, to save on network bandwidth.

But it sounds like there's nothing to check, which is a fine answer.  Retrieving the full guide with each startup and pushing through EpgEventStateChange is by far the simplest code, so that's what I will do.

[ksooo]

But it sounds like there's nothing to check, which is a fine answer.  Retrieving the full guide with each startup and pushing through EpgEventStateChange is by far the simplest code, so that's what I will do.

Yeah that should do the trick.

EDIT: will you PR this for pvr.hdhomerun?

[MatthewLundberg]

My code is so far diverged from the current pvr.hdhomerun that a PR would not be easy at all.

[ksooo]

My code is so far diverged from the current pvr.hdhomerun that a PR would not be easy at all.

Hmm, this is not what I want to hear, tbh. It is also "not easy at all" for me to find the time (my free time - I'm not getting paid for this) to support you. Nevertheless, I do it.

[MatthewLundberg]

My code is so far diverged from the current pvr.hdhomerun that a PR would not be easy at all.

Hmm, this is not what I want to hear, tbh. It is also "not easy at all" for me to find the time (my free time - I'm not getting paid for this) to support you. Nevertheless, I do it.  

 I should have been more forthcoming in my response.  I am going to submit this code for consideration, once I have integrated the DVR code.

It started with a refactor of the existing pvr.hdhomerun, to clean up the code and to properly support multiple devices.  The author rejected my PR (https://github.com/kodi-pvr/pvr.hdhomerun/pull/48).

"Not easy at all" here would mean completely re-writing the code to fit into the current base.