[Kodi] Allow live streams to be recognized as paused

[quthla]

Allow live streams to be recognized as paused

Description:

Add OnResume event
Fix Pausing live streams not recognized
Fix media_title empty when title is empty but label is set

Related issue (if applicable): fixes #
#14394

Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>

Example entry for configuration.yaml (if applicable):

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

• New dependencies have been added to the REQUIREMENTS variable (example).
• New dependencies are only imported inside functions that use them (example).
• New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
• New files were added to .coveragerc.

If the code does not interact with devices:

• Tests have been added to verify that the new code works.

[emlove]

The concerns from #14403 still need to be addressed.

Is there some property on the API that can distinguish between a player being intentionally paused, versus just buffering?

[quthla]

I can't see how that is related especially to live streams? Every other non live stream could be buffering as well.

Is it even confirmed that speed gets set to 0 when buffering happens? I can't remember having seen that happening yet.

https://github.com/xbmc/chorus2/blob/d4fd81f7648b09287b38c2e1484a00b7d1387b05/src/js/apps/state/kodi/kodi.js.coffee

The official Kodi webinterface determines player state also only by speed == 0 so I think we should stick with that.

[emlove]

Those are valid points, but please don't open new PRs to avoid the review process.

[quthla]

That was never my intention. I made the original PR with the GitHub web editor and was unsure if I could edit that as there was a mistake in it.

[emlove]

Ah, I see. No worries. Sorry I jumped to that conclusion.

[lwis]

Maybe the workaround is no longer needed, if not I'm sure this can be solved in a condition. We should just be aware of a potentially breaking change to behaviour.

[quthla]

As there are no objections, I suppose this can be merged?

[MartinHjelmare]

If this is two or three separate fixes/features, the code change should be provided in two or three separate PRs.

[quthla]

I have updated this PR to just one change now

[emlove]

I'm OK with this if everyone else is.

[quthla]

@armills Can you merge it then?

[lwis]

Thanks! 🐊