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
I do hope this helps, but again I'm almost always wrong.