Dis90
Can not login
I tried all the login methods but still failed
-
https://discoveryplus.com/link always replies "The code you entered doesn’t match, please try again by generating another code from your TV"
-
Use Chrome "Get cookies.txt" to get the file play.discoveryplus.com_cookies.txt then turn on "Use cookie.txt file". Open Discovery+, Kodi reports error: "It looks like you are not logged in to Discoveryplus ..."
-
Use cookie name "st" in Chrome Dev Tools then replace the value of "st" in cookie_file. I don't see cookie name "st" in "Get cookie.txt" so I have to get the cookie in Dev Tools, but the value of st in Dev Tools is much longer than the value of cookie st in cookie_file
Can anyone help me log in to Discoveryplus?
I can confirm this behaviour. If you are already loged in, you can browse but not play any content (search, search search, break up with no message and a HTTP400 error of inputstream.adaptive in the log). If you try to renew the cookie, none of the methods is working. Seems the authentification of the addon is broken by an API change of discovery+
I confirm the behavior, too. Browsing is working but no video playing. License server respond with HTTP 400. I made a fresh installation and register the add on by register the code (which was working) but streaming still not working.
I still can watch videos. But it depends on the date of the video. I use D+ to watch cycling. All content until 11/04 has no problems adn is still watchable, everything later, from 12/04 on gets this
2025-04-19 15:40:29.358 T:7280 error <general>: CCurlFile::Open - <https://busy.any-any.prd.api.discomax.com/drm-proxy/any/drm-proxy/drm/license/widevine?keygen=playready&drmKeyVersion=1&auth=eyJhbXXXXXXXXXXXXXXXXXXXXXXXXX&x-wbd-tenant=beam&x-wbd-user-home-market=emea> Failed with code 400: {"errors":[{"code":"vmp_platform_not_verified"}]
In the browser on the same machine everything is working fine. Don't know if it's a problem in this plugin or inputstream.adaptive. Will report it there too.
Discovery+ is no longer available in the country I live in so unfortunately I can't help fix this issue.
Well, that's very bad to hear if the main developer has no acces to D+ anymore. Damned big company politics…
But I really think it's more a issue that needs to be solved via inputstream and /or widevine, since I'm still able to play everything older than April 12th, then their key changed. Though I haven't logged out yet and I won't try that, for sure. Anyway, thanks fore your very helpful plugin ;-)
Discovery+ is no longer available in the country I live in so unfortunately I can't help fix this issue.
Do you think VPN will help? If so I can provide credentials.
I don't know if the following sheds some kind of light, but I'll share my debugging analysis anyway.
I compared the DRM parameters for a working stream (olympics channel, before 2025-04-12) and a non-working stream, extracted from requests made to {api_url}/playback/v3/videoPlaybackInfo. The relevant sections in the responses are (identifiers mangeled):
{
"data" : {
"attributes" : {
"streaming" : [ {
"cdn" : "akamai_olympics_dplus_eu",
"fallback" : false,
"playbackProfile" : "h264-dash-fmp4-fhd-sdr-widevine-cenc",
"protection" : {
"clearkeyEnabled" : false,
"drmEnabled" : true,
"drmProvider" : "conax",
"drmToken" : "[...]",
"schemes" : {
"widevine" : {
"certificateUrl" : "https://discovery-eur.conax.cloud/widevine/certificates/conax",
"licenseUrl" : "https://discovery-eur.conax.cloud/widevine/license"
}
}
},
"provider" : "gps",
"streamMode" : "VOD",
"type" : "dash",
"url" : "https://dplus-sport-vod-olympics-discovery.akamai.prod-live.h264.io/primary/5/[...]/[...]/hdntl=exp=1748639718~acl=/primary/5/[...]/[...]/*~data=hdntl~hmac=[...]/[...]/index.mpd?aws.manifestfilter=audio_codec:AACL;video_codec:h264;video_dynamic_range:sdr;video_height:1-1080&hdnts=exp=1748639718~acl=/primary/5/[...]/[...]/[...]/index.mpd%3Faws.manifestfilter%3Daudio_codec%3AAACL%3Bvideo_codec%3Ah264%3Bvideo_dynamic_range%3Asdr%3Bvideo_height%3A1-1080*~hmac=[...]"
} ],
"userInfo" : {
"packages" : [ "Free", "Registered", "OlympicsChannel", "Fta", "SimulcastEntertainment", "OlympicsVod", "LiveEventEntertainment", "CMore", "Bbc", "VodSport", "OlympicsLiveLinear", "Liiga", "VodEntertainment", "LiveEventSport", "SvtSe", "CMoreFi", "SimulcastSport", "OlympicsLiveEvent", "Allsvenskan", "FtaFi" ]
},
"viewingHistory" : {
"viewed" : false
}
},
"id" : "[...]",
"type" : "videoPlaybackInfo"
}
}
(working stream) versus
{
"data" : {
"attributes" : {
"streaming" : [ {
"cdn" : "cloudfront_dplus_eu",
"fallback" : false,
"playbackProfile" : "h264-dash-fmp4-fhd-sdr-widevine-cenc",
"protection" : {
"clearkeyEnabled" : false,
"drmEnabled" : true,
"drmProvider" : "boltv1",
"drmToken" : "dummy",
"schemes" : {
"widevine" : {
"certificateUrl" : "",
"licenseUrl" : "https://busy.any-any.prd.api.discomax.com/drm-proxy/any/drm-proxy/drm/license/widevine?keygen=playready&drmKeyVersion=1&auth=[...]&x-wbd-tenant=beam&x-wbd-user-home-market=emea"
}
}
},
"provider" : "gps",
"streamMode" : "VOD",
"type" : "dash",
"url" : "https://dplaydk-cloudfront.prod-vod.h264.io/bolt-glo-prod/[...]/x-discovery-token=Expires=1748670644&KeyName=primary&Signature=[...]/packager-mp4-cenc/main.mpd?mfs=[...]"
} ],
"userInfo" : {
"packages" : [ "Free", "Registered", "OlympicsChannel", "Fta", "SimulcastEntertainment", "OlympicsVod", "LiveEventEntertainment", "CMore", "Bbc", "VodSport", "OlympicsLiveLinear", "Liiga", "VodEntertainment", "LiveEventSport", "SvtSe", "CMoreFi", "SimulcastSport", "OlympicsLiveEvent", "Allsvenskan", "FtaFi" ]
},
"viewingHistory" : {
"viewed" : false
}
},
"id" : "[...]",
"type" : "videoPlaybackInfo"
}
}
(non-working stream)
The obvious changes are:
- changed DRM provider ("conax" vs. "boltv1")
- missing Widevine certificate URL in boltv1
- "dummy" DRM token in boltv1
As DiscoveryPlus works in Firefox for me, I compared the requests made to the boltv1 license server URL. On Kodi I have the following request/response pair:
POST /drm-proxy/any/drm-proxy/drm/license/widevine?keygen=playready&drmKeyVersion=1&auth=[...]&x-wbd-tenant=beam&x-wbd-user-home-market=emea
Host: busy.any-any.prd.api.discomax.com
User-Agent: Kodi/21.2 (X11; Linux armv7l) LibreELEC/12.0 App_Bitness/32 Version/21.2-(21.2.0)-Git:21.2-Omega
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Charset: UTF-8,*;q=0.8
PreAuthorization: dummy
Content-Length: 1773
Content-Type: application/x-www-form-urlencoded
[actual request content is unknown]
HTTP/2 400
date: Fri, 30 May 2025 [... GMT
content-type: application/json; charset=utf-8
access-control-allow-credentials: true
access-control-allow-methods: OPTIONS, POST
access-control-allow-origin: *
traceparent: 00-[...]
content-encoding: gzip
vary: Accept-Encoding
whereas the request/response pair in Firefox reads
POST /drm-proxy/any/drm-proxy/drm/license/widevine?keygen=playready&drmKeyVersion=1&auth=[...]&x-wbd-tenant=beam&x-wbd-user-home-market=emea
Host: busy.any-any.prd.api.discomax.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: */*
Accept-Language: en-GB,en;q=0.7,de;q=0.3
Accept-Encoding: gzip, deflate, br, zstd
Content-Length: 1728
Origin: https://www.discoveryplus.com
DNT: 1
Sec-GPC: 1
Connection: keep-alive
Referer: https://www.discoveryplus.com/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
[...]
HTTP/2 200
date: Fri, 30 May 2025 [...] GMT
content-type: application/octet-stream
content-length: 792
access-control-allow-credentials: true
access-control-allow-methods: OPTIONS, POST
access-control-allow-origin: https://www.discoveryplus.com
traceparent: 00-[...]
access-control-expose-headers: date,x-wbd-ace,x-wbd-refresh,x-wbd-session-state,x-wbd-transport
X-Firefox-Spdy: h2
[...]
Interestingly enough, the (mangeled) auth request parameter seems to be a JWT which contains of 3 sections: header, payload, verify signature (see https://jwt.io for details). In my case, the header and payload parts were identical whereas the verify signature was different. But as the value for auth is part of the licenseUrl – which in turn is extracted from the videoPlaybackInfo request – I suppose that this detail should not matter.
So, what else do we have that is different in the two requests:
- User-Agent header
- PreAuthorization header
- payload(?)
@vitusson You wrote:
Don't know if it's a problem in this plugin or inputstream.adaptive. Will report it there too.
Did you actually report an issue against inputstream.adaptive?
@vitusson You wrote:
Don't know if it's a problem in this plugin or inputstream.adaptive. Will report it there too.
Did you actually report an issue against inputstream.adaptive?
Nope, since I watched this issue (and others mentioning widevine and license problems) and I hoped the Dis+ problems would be solved with widevine and inputstream.adaptive updates. Which unfortunately didn't happen. https://github.com/xbmc/inputstream.adaptive/issues/1801
Since the new IA release solved the problems for other services/plugins, I assume it has to be solved here.
Your debugging analysis basically the same as mine. What is still working at content after 12-04-25 are the shorter daily Highlights of Giro D'Italia, they seemed to be encoded with a still working key, whereas all live content and replays of whole stages post 12-04-25 failed to work.
@vitusson wrote: What is still working at content after 12-04-25 are the shorter daily Highlights of Giro D'Italia, they seemed to be encoded with a still working key, whereas all live content and replays of whole stages post 12-04-25 failed
I just confirmed: the Giro d'Italia streams are still provided by Akamai using Conax DRM protection. That's why they are still working.
The challenge is probably to get a decryption key for BoltV1 (and to forward it to Inputstream Adaptive). In contrast to Conax, there's no certificate URL being advertised. (At least not in an obvious fashion.)
In general teams: I guess what we are observing here are the first signs of the Discovery+ to MAX transition. @Dis90: Do you have a working MAX setup, maybe using the slyguy plugins? Maybe there's something that we can learn from there?
They are switching to proxied license requests. You can compare the DAZN plugin which has been changed to support it: https://github.com/Maven85/plugin.video.dazn/commit/b60536be7c70a944f74d06cffa33dff0e5ead694
Out of curiosity, I tried to make an add-on for MAX but VMP (Verified Media Path) became a problem. I tried to investigate Matthuisman's MAX add-on but no luck. There's some proxy handling license request in his add-on.
@Dis90 I'm already in the middle of analyzing Matthuisman's work and how it could be integrated into your plugin. What I've found out so far:
The "proxy handling" does not seem to be a network proxy kind of thing. To me it seems to be some kind of generic "request/response interception framework" - with network proxies probably being the original use case. (However, I can only guess on that.)
If you look at the play method (https://github.com/matthuisman/slyguy.addons/blob/master/slyguy.max/resources/lib/plugin.py#L451), you see that a "proxy" of type "middleware" is registered, which boils down to the method mpd_request in the same file (https://github.com/matthuisman/slyguy.addons/blob/master/slyguy.max/resources/lib/plugin.py#L348).
I've already ported this method to your plugin, and hooked it into the request cycle. In essence, it seems to manipulate some cenc:pssh values in the MPD manifest returned by the /playback/v3/videoPlaybackInfo endpoint.
My current question is: what would I do with the modified MPD manifest? (Currently I have it somewhere on disk just for comparison with the original.) That's something that I've not managed to reverse engineer so far. (I'm stuck at https://github.com/matthuisman/slyguy.addons/blob/master/script.module.slyguy/resources/lib/proxy.py#L85)
but VMP (Verified Media Path) became a problem
How did that became apparent to you? Yet I fail to see any kind of HTTP 403 response's that would be an indication for me. (Of course, working with a "real" MAX services might be a different kind of beast than working with the "DiscoMax" ones.) Therefore I've not given up hope yet...
@Dis90 Could you please archive this repo until (if) this gets fixed? Idk what country you live in, but Warner Bros Discovery are splitting up again back to being Warner Media and Discovery Network. So hopefully Discovery+ will return to you guys soon enough
