[listprovider] Make sure content is always loaded. Fixes #16635

[BigNoid]

Description

Set begin state to INVALIDATED so that dynamic content always gets fetched when the list is loaded, even if content attributes haven't changed.

Motivation and Context

See http://trac.kodi.tv/ticket/16635 for full details.
One side effect of previous behaviour was that a list that had not changed it seemed to load very fast on window load. But in fact that was old content, so could potentially be out of date. Behaviour in this PR is the correct way imo.

How Has This Been Tested?

Runtime tested

Types of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the Code guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the CONTRIBUTING document
• I have added tests to cover my change
• All new and existing tests passed

@phil65 @ronie @HitcherUK

[BigNoid]

jenkins build and merge please

[hudokkow]

jenkins is really temperamental lately. Didn't even started jobs, except for win that failed, again.
jenkins build and merge

[BigNoid]

jenkins failure is unrelated

[tamland]

Can you please explain why this is correct? Setting it to invalidated is the opposite of what is currently done in both initializer and in 'immediate' reset.

[BigNoid]

The job needs to be fired when the list is loaded, regardless if sort, limit and url have changed. CDirectoryProvider::Reset() is called when the list becomes first visible, so setting it invalid there made the most sense to me.

[ghost]

@BigNoid this is causing a strange issue in estuary, if you have videos show up last on list and you go settings then exit out and scroll up to Videos it shows "Playlists" under Video > media sources (usually blank under the media source icons) for a second or two then vanishes.

[BigNoid]

Yeah that is expected. Before that only happened on first window load (and after some specific calls like updated favourites/playback stopped/database update) and the list would never be loaded again. With this change the list will be updated each time the list becomes visible the first time a window is opened. Skins need to check if the list is updating or that is has more than 0 items. So it's visible for a short time while its updating.

[ghost]

@BigNoid ok thanks ill get used to it. sounds like this might also fix when you do a first install and start scanning to library the home page has no files on it until you restart kodi then they show up.

[tamland]

@BigNoid Ok, I've had a look at the directory provider source again and I'm not sure if this is the right approach. Currently, the whole thing is base on being initialised to an empty state; and then, only when ::Update is called changes are detected. The 'invalidated' state was only intended to be used when external changed to the content occurs; that the directory provider cannot know about.

So instead of just throwing in an invalidation, we should find out an understand why this window issue is happening

[BigNoid]

@tamland
Imo the problem is that no matter if OnJobComplete is called the job is considered done and unless sort, limit or url changes (or in case of external changes) ::Update is never called again.
I tried implementing OnJobProgress but I couldn't get that to work.

EDIT: only updating if OnJobComplete wasn't called would be the right approach probably. It would prevent lists loading again with content that only changes on external events, like list of genres for example.

EDIT2:
otoh lists with plugin content would also not be updated on window load with that approach, which may result in old content until the app is restarted or an external event is triggered.

[BigNoid]

@tamland
I've did a few debug sessions and Reset() gets called on window exit. To fix the problem described on trac, but keep functionality as it was before I've now did this: BigNoid@7b7db0b
Would that be the right approach? So it only gets invalidated if OnJobComplete wan't called.