[epg] start epg container asynchronously

[xhaggi]

As the title said this adds asynchronously start of the EPG container which do not block the entire PVR manager startup and results in a really fast resumption of playback for the last played channel if you enable "continue last played channel" in TV settings.

@opdenkamp or @Jalle19 ping

[AlwinEsch]

Have checked, does not work.

The

bool CPVRManager::CreateChannelEpgs(void)
{
  ...
  m_bEpgsCreated = m_channelGroups->CreateChannelEpgs();
  ...
}

returns false and on

void CEpgContainer::Process(void)
{
  ...
  if (!InterruptUpdate() && bUpdateEpg && g_PVRManager.EpgsCreated() && UpdateEPG())
  ...
}

the "UpdateEPG" becomes never called.

EDIT: Was occurred after database reset and also if database was deleted before.

[FernetMenta]

there are issues when starting playback on a channel which has no valid epg. info shown on OSD seems to get not updated when there is a valid egp.
imo this should be fixed before.

[xhaggi]

@AlwinEsch thanks for pointing this out, it's now fixed.
@FernetMenta i don't have any issue with what you said.

[FernetMenta]

@xhaggi have you ever tried not to store EGP in the db? probably not or you would have observed this issue. Not storing EPG in pvr db is default scenario for vnsi because vdr has its own db for EPG and startup is much faster this way.

[xhaggi]

@FernetMenta sure and that's why I want to load the epg data from the database async because IMO this shouldn't block the PVR manager startup.

@AlwinEsch sorry my fix won't work :(

[FernetMenta]

it would cause a regression for vnsi which already starts up very fast. I am not opposed to this but the issue mentioned should be fixed first.

[xhaggi]

I don't want to change the way how we get clients epg information into kodi. After a second look we should think about the way we load the data from our database. IMO we should load the client data first and later the data we stored in our database (async). If the related epg data already exists in memory we can skip it from being created from our database data. Currently we load the epg from our database first and later the epg data from the client and decide if we need to update the epg data in our database which is IMO not the right order.

[FernetMenta]

In case of VNSI the db is never used so what is loaded first does not matter. The point is that when a channel is started some data is pulled from EPG container which never gets updated during playback. start a channels with no EPG, then trigger EPG update for the channel playing.
btw: there are a couple of other things not working properly, i.e. EPG tags on channels in pvr window. Sometimes they get updated when moving the curser away and disappear when moving the cursor on the item. This occurs when Kodi is started with no EPG and EPG is updated while running triggered by the backend.

[xhaggi]

In case of VNSI the db is never used so what is loaded first does not matter.

Fine for VNSI then. This PR ( if it works ;o) ) addresses all backends which relies on kodi's database.

The point is that when a channel is started some data is pulled from EPG container which never gets updated during playback.

Yep i know this issue. We can look into it in the next few weeks, where we can't push new stuff.

[FernetMenta]

Yep i know this issue. We can look into it in the next few weeks, where we can't push new stuff.

This should be fixed before this PR goes in. Otherwise it makes things worse for vnsi.

[xhaggi]

@FernetMenta with the changes I've done in #7667 now the async startup of the epg container does not introduce any regression. It will speed-up things a lot. I would prefer to merge this after #7667 goes in.

@opdenkamp @ksooo @Jalle19 any objections

[FernetMenta]

very nice and thank you very much! Now epg gets visible right after vnsiserver requests an update.

[xhaggi]

ah does it mean you've tested #7667 on top of this?

[FernetMenta]

I merged both for the test.

[xhaggi]

great, thanks :)

[ksooo]

No objections from my side. Not runtime tested, but code changes are looking straight forward to me.

[xhaggi]

jenkins build this please

[ryangribble]

this seems to have broken things for me, my EPG is never loaded (no calls to GetEpgForChannel() are ever made).

I have tried with "do not store EPG in database" option enabled and disabled but am getting the problem in both cases.

If i hardcode the bAsync variable in EpgContainer.Start() to false, my EPG loads fine again, which is why I think it is this change. Any advice on how to further troubleshoot?

[xhaggi]

please provide some more information:

• debug log
• version information (system info)

[ryangribble]

My debugging leads me to
https://github.com/xbmc/xbmc/blob/master/xbmc/pvr/channels/PVRChannelGroupInternal.cpp#L335

CPVRChannelGroupInternal::CreateChannelEpgs()
{
    if (!g_EpgContainer.IsStarted())
        return false;

The function is exiting at this point because EpgContainer is not started, so it never proceeds on to call CreateChannelEpg()

When I set bAsync to false in EpgContainer::Start(), EpgContainer.IsStarted() is false at this same point, and thus this method does not exit here and then goes on to load the Channel Epg's

Debug Log

Version Info: Im running this branch which is the #7626 [PVR] API 3.0.0 Changes PR rebased on top of latest kodi master (commit fb174d6)

[xhaggi]

@ryangribble could you please move g_PVRManager.TriggerEpgsCreate(); from

https://github.com/xbmc/xbmc/blob/master/xbmc/epg/EpgContainer.cpp#L174

to

https://github.com/xbmc/xbmc/blob/master/xbmc/epg/EpgContainer.cpp#L187

and try if this will fix the issue. If so I'll create a PR asap.

[ryangribble]

OK so that made the Epg load however it loaded each channel EPG about 11 times back to back before it finally stopped :)

debug log

[xhaggi]

I can't reproduce the issue. I've added a debug log to CPVRChannelGroupInternal::CreateChannelEpgs(bool bForce); and it only appears twice in my log, one for TV and one for Radio before everything is loaded.

[xhaggi]

please checkout the current master without anything else. we need the same version for testing things.

[xhaggi]

@ryangribble see #7734