Thread Rating:
  • 1 Vote(s) - 5 Average
peak3d development roadmap
Ok I can only speak for Linux/LibreELEC which from 2.0.13 definitely won't need in CDM. This situation is possibly because on Linux when including the add-on as part of the OS (rather than as a user-installed add-on from zip) the shared libraries are installed into /usr/lib/kodi/addons which, prior to 2.0.13, was not being checked. If the shared library (or dll) is installed alongside the addon.xml etc. (as it would be when installing from zip) then will be found, perhaps that's how Windows packages and installs the add-on which explains why it's been working in older versions of inputstream.adaptive?
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Seems it's still a bit "risky" for me to assume.

I'll just keep copying it.
It doesn't hurt if it's there and not needed Smile

My new wvhelper lib:

Now from the video add-on I simply call

if video['type'] == 'widevine' and wvhelper.has_widevine():
    li.setProperty('inputstream.adaptive.manifest_type', 'hls')

elif video['type'] == 'hls' and wvhelper.has_hls():
    li.setProperty('inputstream.adaptive.manifest_type', 'mpd')
    li.setProperty('inputstream.adaptive.license_type', 'com.widevine.alpha')


Any secret to getting HLS working?
I'm trying with a hls m3u8 but it keeps failing to play.
I did look in the m3u8 and it is using EXT-X-KEY:METHOD=AES-128 so maybe that is why?

I also tried, and widevine still won't work in Windows Store Version (17.4).
Here is a log:

I think Windows sandbox stops any DLLs running that are in the sandbox.
SSD_WV is now included so you can see that loads fine.

The location for that is:
C:\Program Files\WindowsApps\XBMCFoundation.Kodi_17.4.0.0_x86__4n2hpmxwrvr6p\addons\inputstream.adaptive

However, when the Widevine lib downloads and installs, it's put here:

I think the sandbox stops any DLLs running from this sandbox environment.
It is also not possible to copy files into C:\Program Files\WindowsApps\XBMCFoundation.Kodi_17.4.0.0_x86__4n2hpmxwrvr6p.
"Dynamically loading and executing code from an external assembly is not supported in a UWP."

I guess it makes sense as if you could just load up DLLS from within the sand-box - it defeats the purpose.
So, UWP KODI will basically be in-compatible with Binary add-ons (unless included in the package)?

Also, appears Android nighties are broken for widevine playback
(Fixed in
(2017-08-25, 01:52)matthuisman Wrote: Any secret to getting HLS working?
I'm trying with a hls m3u8 but it keeps failing to play.
I did look in the m3u8 and it is using EXT-X-KEY:METHOD=AES-128 so maybe that is why?

Hey Matt,
You just need to set a few listitem properties. Earlier in the thread there was this solution:
(2017-08-09, 18:54)eracknaphobia Wrote:
(2017-08-07, 20:06)JinJin Wrote: @enen92
listitem = xbmcgui.ListItem()
listitem.setProperty('inputstreamaddon', 'inputstream.adaptive')
listitem.setProperty('inputstream.adaptive.manifest_type', 'hls')

FYI, If your streams require custom header values use:
headers = 'User-Agent=Some user agent&Cookie=some_cookie'
listitem.setProperty('inputstream.adaptive.stream_headers', headers)

This one tripped me up for quite some time.

but with recent changes the headers for the decryption key download are now specified separately:
listitem.setProperty('inputstream.adaptive.license_key', stream_url + '|' + headers)
Infact it seems you don't need to include the playlist url, just the pipe followed by the headers.

Put these all together and it works quite well, Kodi 17 and 18.

Also Matt, I've made a bunch more changes to drmhelper. You can now select an item to play and go from having no installation of inputstream.adaptive/widevinecdm/ssd_wv to having all 3 installed and playback starting. Rather than installing from a Kodi repo the inputstream.adaptive zip file downloads from a plain file repo, unzips into the addons folder and JSON-RPC asks Kodi to rescan addons. Trying to make it as foolproof and painless for the user as possible. I don't think though that this addon has much of a chance of making the Kodi repo though because of downloading google's binaries.

Yes listitem.setProperty('inputstream.adaptive.manifest_type', 'hls') is what I was using but didn't work.
So I assumed it was because the stream I was testing had AES-128 encryption.

You have any ideas how-to check if KODI is running the Windows store version?
As above - I don't think it will ever work due to the UWP Sandbox.
Maybe it could check the path of the add-on.
If it's in "WindowsApps" then we know it's the store version and make it then un-supported (message = "Use the installer version!")

Regarding a DRM Helper add-on in official KODI repo - would be great.
I can just imagine KODI 18 released + Netflix add-on = hundred of posts in forums with issues installing the DRM.

Unless inputstream is extended to check for the in more places on each OS?
eg. program_files/chrome on Windows, /usr/lib/chrome/widevine on Linux etc.
Sort of like how it can use the Androids lib but on all platforms.
Then it's simply (make sure you have Chrome installed on your platform)
But this won't work for things like OSMC, LibreELEC etc.
An add-on still seems the best way?
AES-128 should work fine, I'm testing with ABC iView (HLS AES-128) and it works well. It will only play master m3u8 files, so if you've given it one of the stream m3u8 urls from within the master that could be why. What does the log say?

I think with Windows store installations the way you've laid out seems best for now.

Addon is still the best way at the moment I think. Inputstream.adaptive trying to find widevinecdm on the disk sounds like too much outside its scope. Plus there's going to be compatibitly issues. AFAIK, the latest versions of widevinecdm bundled with Chrome ( aren't compatible.

Aha - using the master and not substream solved it.
Wow it's fast!

So, my code will check if inpustream version > 2.X.
If so, use inpustream for hls playback.
Otherwise, I will do what is done currently (parse m3u8 getting best quality substream)

Actually, I'll remove the parse m3u8 code - it has always felt a bit hacky.
Most users will be moving to 17.4 and get the inpustream speed.
Otherwise, the speed difference isn't huge (about 1-2 seconds quicker)

Now all we need is someone to update IPTV Simple Client to use inpustream when playing channels.

Or better yet, a PVR Client binary add-on that simply passes the methods down to a Python add-on that returns the required data.

pseudo code:
PVR_ERROR GetChannels(ADDON_HANDLE handle, bool bRadio)
    data = XBMC->RunPlugin(plugin://plugin.module.simpleiptv?func=getChannels&bRadio=bRadio)
    for channel in data:
       PVR_CHANNEL xbmcChannel;
       xbmcChannel.iChannelNumber   = channel.iChannelNumber;
       PVR->TransferChannelEntry(handle, &xbmcChannel);

The settings for this PVR Client add-on would allow you to select when "parser" add-on you want to use.

eg. channel list, epg list, & play. Then the inpustream code could be in python add-on..
It would make it so much easier to extend the functionality (multiple m3u8 lists etc).

I think I may have noticed maybe a bug with the HLS inpustream:

On some live streams, it's returning a duration (eg. 3mins)
Which means KODI gives you the option to "Resume from X"
Selecting this pretty much crashes KODI (endless loading).
Without hls, it works fine (no resume point)
Maybe there is a way to force no resume point?
(and yes - I am setting duration to 0 in the listitem info)
Just wondering what's up with the updates? On Kodi 17.4 the current inputstream adaptive version shows 2.0.10 with no updates available even though github shows Krypton is now on 2.0.15. How do we update?
Install nightly
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe

Kodi in git right now has bumped the kodi.binary.* versions and I think that is preventing installation of or I've done something stupid. In any case, I'm getting errors like:

ERROR: CAddonInstallJob[inputstream.adaptive]: The dependency on version 1.0.10 could not be satisfied.

Do I need an updated build of inputstream.adaptive?
(2017-09-08, 05:08)micahg Wrote: Do I need an updated build of inputstream.adaptive?

OK, rolling kodi back to 5373dc261be77ed49e009aa1b97cfbc50f2b8257 is a workaround.

edit: no it isn't

second edit: compiling everything from source, including inputstream.adaptive works. sorry for wasting a post
Is this the appropriate forum to request help on addon implementations? I'm looking for guidance on working out what license param values I should be setting. Thanks in advance. FYI, I think I'm dealing with a license server, to which I'm provided an oauth token... from there I get lost.
I'll add documentation next week on git wiki page
cool. ty.

peak3d development roadmap51