PVR EPG Updates
#1
There is no API to trigger an EPG update for all channels which is how the NextPVR interface operates  Could I request a connection state change to disconnect and reconnect to do this or is it better to triggers potentially 1000's of updates almost at once? 

This trigger would not activate during video playback and NextPVR EPG updates are supposed to be performed in silent hours.

Martin
Reply
#2
Not sure if this would work for you, but I found that supporting both the synchronous and asynchronous EPG functionality worked out to be the "best case" for me.  Here's what I do:

- Keep PVR_ADDON_CAPABILITIES.bSupportsAsyncEPGTransfer set to FALSE
- Continue to implement the synchronous GetEpgForChannel() callback
- Have a secondary update mechanism that invokes CHelper_libXBMC_pvr::EpgEventStateChange() asynchronously as needed when new EPG data is available

NOTE: When I call EpgEventStateChange(), I always provide EPG_EVENT_STATE::EPG_EVENT_UPDATED for newState.  I also just go ahead and resend everything I have to Kodi this way.

I tried to switch to fully asynchronous EPG, but found that operations like "Clear Data" don't work well in that case, since the PVR won't be notified about it and given a chance to respond.  Implementing both types of transfer, with the anticipated code duplication involved, has kept things stable.  I had to switch to a periodic (+/- 24 hours) update cycle for EPG, but I am also able to cache it, which is very helpful.  If GetEPGForChannel() is called, I send what I have.  When the update cycle comes due, I send everything I got from that update cycle with EPG_EVENT_UPDATED.  Been this way for about 4 months now with no complaints or no noted issues.

I'm almost always wrong when trying to help anyone else, so take my comments with a grain of salt, of course.  If you'd like to see what I ended up doing that I'm claiming works well, hit this file and inspect both "GetEPGForChannel" and "update_listings_task".  GetEPGForChannel is the typical synchronous version, update_listings_task is the asynchronous version that gets invoked when I have new EPG data available: https://github.com/djp952/pvr.hdhomerund...rc/pvr.cpp.  I don't like having nearly identical code in two places like this, but so far it's kept everyone happy Smile


I do hope this helps, but again I'm almost always wrong.
Reply
#3
Thanks so you do trigger the update for each channel.  Are there issues on a Prime with many hundreds of channels or do they come in sequentially like a typical startup?

Martin.
Reply
#4
Not that I've noticed.  I don't use TriggerEPGUpdate() anymore, so when I have a bulk load from the XMLTV ready I just blast through it as quickly as possible using EpgEventStateChange().

Ran a test here for you, with 100 channels and 7 days of EPG listings, it took just under .5 seconds to transfer all the entries to Kodi via EpgEventStateChange() [46359 EPG_TAGs in this particular case]:

txt:
2020-03-23 12:25:05.556 T:4516  NOTICE: AddOnLog: HDHomeRun DVR PVR Client: update_listings_task: triggering channel update
2020-03-23 12:25:05.556 T:4516  NOTICE: AddOnLog: HDHomeRun DVR PVR Client: update_listings_task: execute electronic program guide update
2020-03-23 12:25:06.032 T:4516  NOTICE: AddOnLog: HDHomeRun DVR PVR Client: update_listings_task: triggering timer update
2020-03-23 12:25:06.032 T:4516  NOTICE: AddOnLog: HDHomeRun DVR PVR Client: update_listings_task: scheduling next listing update to initiate in 80775 seconds

It takes me around 5 seconds to download and parse the 14-day XMLTV data load into my local SQLite database, the .5 seconds is the time to iterate over all of them from that database and call EpgEventStateChange() for each.  I limit the amount of data I send to Kodi based on the global EPG "number of days"

So I really can't say I see any performance issues with it.
Reply

Logout Mark Read Team Forum Stats Members Help
PVR EPG Updates0