[emilsvennesson]

@emilsvennesson

Let's say a user didn't install inputstream when installing KODI in Windows.
My add-on requires the helper module.
The helper module dependency breaks on inpustream.
User get's a non helpful dependency error and my add-on fails to install.
Now the user can't use my add-on at all (some streams don't even need widevine).

Vs
User installs my add-on.
Plays normal streams fine.
Goes to play a DRM stream.
Helper module gives a nice "Inpustream addon is not found. blah blah"
Glennguy's module even can go and download the binary add-on for the user.

You could have the dependency as optional - this would be OK.
You still would need to check if the add-on is there in code though.

I think the less dependencies the better.
And a dependency on a binary add-on just seems too risky as these are often not installed via kodi repo.
Keep dependencies to actual Python packages (requests etc) that are pretty much guaranteed to work everywhere.

Also think about that this might in the future not only be for inpustream.
Other binary add-ons could come out that help playback certain content.

so, maybe name it something more generic:
script.module.playback-helper


https://github.com/xbmc-catchuptv-au/scr...mconfig.py
has some legit sources for ARM boards.
Unfortunately, needs to download entire chrome and then pull the widevine from that.

I just up'd them to my github for my own repo just to make it quicker D/L for end users.
I'll remove with first take down notice and switch to the other method.

For the kodi repo add-on, using a "legit source" would of course be needed


I think @glennguy 's module would be pretty much ready to go into the official repo if he wanted to.

Unfortunately, that module is also relying on third party sites (again, which I doubt is legal) which is a big no-no.

I did my own take on this and have submitted the module to the official repository: https://github.com/xbmc/repo-scripts/pull/598.