How to handle subscription conflicts?

[Glenn-1990]

This is causing me headaches for ages now.

Scenario: I'm watching live tv, but a recording is starting or another client is tuning a channel. Now my livestream get's aborted with the message 'no free adapter' (depending on the number of adapters in machine, number of livestreams and recordings, etc)

Currently there is no way to know which recording you need to abort if you want to keep watching.
If my livestream was aborted by another client's livestream, then there is no way to do something about this within kodi.

First I was thinking of some kind of conflict management within the kodi pvr API calls, but other backends might handle this different than tvheadend. Tvheadend only needs to change the subscription weight to handle this, so it could actually be done with a simple dialog which is already present in the api.

So I played a bit with the code to get something testable:
Glenn-1990@5d78935

screenshots:

I'm now parsing "subscriptionError", in this way we can also translate the error codes (i.e. scramble, no signal, no free tuner, ...)

Recordings with no tuner assigned to are now displayed as conflict instead of active.

Actually I implemented 2 types of dialogs:

dialog #1:
Showed to user if the livestream suddenly gets aborted because of a higher weight subscription.
User is asked to increase the weight to get a tuner back and keep watching.

dialog #2:
Used when a channel could not be started from the beginning because of a higher weight subscription.
This is showed after 15s on that channel, this to prevent for the dialog popping up on every channel switch when zapping.
User is asked to increase the weight to get a tuner back and keep watching.

@ksooo @Jalle19
Does this have any potential or do we need an PVR API function for this, your opinions please?

[Jalle19]

I like the idea. I have a feeling that not that many backends support reacting to a lost stream in any way so this could be one of those things where we just have to do our own thing.

@ksooo what do you think? @Glenn-1990 can you rebase on master (e.g. SendWeight() has been implemented) and make a PR, then we'll continue the discussion there?

[Jalle19]

Closing in favor of the actual PR.