xbmc
[Bug] DAZN VOD and live streams no longer start
Describe the problem
DAZN VOD and live streams no longer start. An error message does not appear. A possible indication of this can be found in the log file.
Possible fix
No response
Steps to reproduce
No response
Debug log
Stream manifest file(s)
No response
Additional info
No response
Operating system(s)
Android
Operating system version(s)
Android 10
InputStream Adaptive version(s)
22.1.12
Kodi version(s)
22 Alpha (Piers)
Logfile from Android Tablet. Kodi version 21.1 - Inputstream version 21.5.9
Could it be that the TLS verifications declined our request? Is there any possibility to deactivate it like with verify=False in requests-libraray of phyton?
Logfile: https://paste.kodi.tv/erepabucoc.kodi
DAZN VOD and live streams no longer start
what means exactly "no longer start"? its a problem limited to v22 or to all kodi versions? or is something like "yesterday" it was working and suddenly "today" not? if so could be also means that dazn has changed something and you need to inspect the website
anyway the attached log file dont contains the video played attempt, the shrinked log shown above here is mostly censured therefore almost useless... the only understandable line is
2025-01-31 20:33:51.856 T:27683 error : AddOnLog: inputstream.adaptive: License server returned failure (HTTP error 401)
maybe missing or wrong headers in the license request, but could be also other
PS. i dont think its SSL problem, anyway you can disable the verify by using inputstream.adaptive.config see wiki docs
It's still working on Windows still with kodi 21. However, since last friday it isno more working via Amdroid. Header looks. For other requests within the addon we had to set verify-false to the requests to make it runable again. This was blocked about 2 weeks ago without. I will try it with inputstream.adaptive.config. Thanks PS: i only censure my access token. ;-)
Unfortunatelly the deactivation of ssl verification at inputstream.adaptive.config did not fix the issue. I do not understand why it's working with Kodi at Windows without any issue and with kodi at android the same addon with the same header information does not work.
The data directly on the dazn website is still the same :-(
https://drm.playback.indazn.com/widevine/v1/license?legacyContentId=prod-live1&contentId=3ozybac4hvk11aaljtsjmeo0r&platform=web&manufacturer=microsoft&model=unknown&appVersion=0.64.0&uid=0012400000jSLLcAAO&accountStatus=ActivePaid&assetId=bodk4sqyawyv7in3u0jux56dd&aexp=1738724400000&tid=3f668a1e-6f70-4684-a9a7-296ffc82c60d&uexp=1738787793414&mediaType=live&mediaId=3ozycad4hvk11bbljtsjmeo0r&metadata=country=de&ftv=false&hash=683a37b0e50ef3d302c47dbbeb8868e0c1d165b417152fdb89c6cc26db7b6523
Same URL is sent to inputstream via License server url
For other requests within the addon we had to set verify-false to the requests to make it runable again.
this doesn't sound good...
however you should try check the network flow generated by the original dazn app or try use dazn website on the android, sound more something changed on the dazn service
I have tried now a lot of difference settings but nothing works on Android, only via Windows.
Kodi-Addon:
`item.LaUrl = 'https://drm.playback.indazn.com/widevine/v1/license?legacyContentId=prod-live1&contentId=247Channel202_catchup&platform=web&manufacturer=microsoft&model=unknown&appVersion=0.64.0&uid=0012400000jSLLcAAO&accountStatus=ActivePaid&assetId=bj5o60qt6uoe1clfdsev239pr&tid=b9e12a7b-f582-4b9f-bca8-b84b0cca6c7a&uexp=1739091958209&mediaType=live&mediaId=247Channel202_catchup&metadata=country%3Dde%26ftv%3Dfalse&hash=4f36d5017349f7ae356d1a7d32aad5ccd51e7f9b0ee79033f00ee55dcac7f3dd' self.user_agent = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/135.0'
listitem = xbmcgui.ListItem() listitem.setContentLookup(False) listitem.setMimeType('application/dash+xml') listitem.setProperty('inputstream', 'inputstream.adaptive') license_headers = 'user-agent={0}'.format(self.plugin.get_user_agent()) drm_cfg = { 'DRM KeySystem': 'com.widevine.alpha', 'License server url': item.LaUrl, 'License headers': license_headers } listitem.setProperty('inputstream.adaptive.drm_legacy', '|'.join(drm_cfg.values())) `
the License server url has the same paramater like sended via Windows. But with Kodi on windows it works, with Kodi on Android it does not.
I always get http error 401 at android.
for me it looks like a bug in inputstream-addon and not in my header. Otherwise, why it should work with windows but not with android?
the License server url has the same paramater like sended via Windows. But with Kodi on windows it works, with Kodi on Android it does not.
I always get http error 401 at android.
for me it looks like a bug in inputstream-addon and not in my header. Otherwise, why it should work with windows but not with android?
the http error 401 is some kind of denied access that come from dazn license server
its not new that video services could use differents behaviours or apis between android and non-android operative systems, this because android have a built-in widevine that's not so equal to widevine "module" library thats used on non-android systems so there is a possibility that dazn has made changes
talking about ISA for kodi 21 nothing is changed on last months about how the license request is done, this from 21.5.0 of near the end of july 2024, so if you think that's an ISA regression you should test each version from 21.5.0 and older versions, or else you can simply test dazn on kodi 20, where ISA source code developments has been stopped over different years
another thing that you can check is via kodi Curl debugging, verify if the license requests contain the right data (i.e. headers, data format) and so check if android app sends the same data to the license server (so it was, to set different formats you need to use "inputstream.adaptive.license_key" post data field or "inputstream.adaptive.drm -> license -> req_data")
talking about ISA for kodi 21 nothing is changed on last months about how the license request is done, this from 21.5.0 of near the end of july 2024, so if you think that's an ISA regression you should test each version from 21.5.0 and older versions, or else you can simply test dazn on kodi 20, where ISA source code developments has been stopped over different years
Hi @CastagnaIT with your advice, I tried the current DAZN addon under Kodi 20.5 (Nexus) on an Android 10 Device and lo and behold, it works without any problems!!! Apparently the problem is related to the current developments within the ISA addon in the subsequent versions after Nexus.
Greetings Weri
then the first thing is that you provide me a kodi full debug log of kodi 20 and 22 with curl debugging enabled possibly without censuring debug info otherwise has no much sense so that i can try compare the differences hoping to see something
i need also that you link here the GH sourcecode of the dazn addon (better the py file that make the video callback to kodi) so that i have a better understanding of variables configured
being, theoretically, a problem that goes back years it probably won't be easy to understand
Indeed, with Kodi 20.5 it's working fine via Android.
Addon available here:: https://repo.kodinerds.net/addons/nexus/zip/plugin.video.dazn/plugin.video.dazn-1.4.9+nexus.1.zip (urllib3 has to be 2.2.3) Interesting file: items.py with inputstream-lines
Here already the logfile with Kodi 20.5 via Android: https://paste.kodi.tv/ufalizagax.kodi
I will try to create the other logs during today evening/night.
"curl debugging enabled" - you mean the normal kodi debugging - or is this something else?
@MRLB It is under Logging - debug loggimg is topmost toggle but debug categories is the toggle below the topmost one and category selection dialog is below that one. Click on that toggle, arrow down and enter the dialog and select cUrl.
19:28:29.316 and 19:51:14.954 are the interessting lines
Could it be an issue that the letters are no longer lower cases? HEADER_OUT: accept-charset: UTF-8,;q=0.8 HEADER_OUT: Accept-Charset: UTF-8,;q=0.8
The only difference what is visible is that the header_output has now capitels letters. Could this be an issue?
Kodi 20 - Android (working)
2025-02-09 19:28:29.316 T:28745 debug
Windows (working):
2025-02-10 16:37:40.396 T:1328 debug
Kodi 21 - Android (not working)
2025-02-09 19:51:14.954 T:14580 debug
next time please use our paste service to post logs https://paste.kodi.tv/ or alternatively attach the log file directly to the text box but never attach logs on github as text message...
The only difference what is visible is that the header_output has now capitels letters. Could this be an issue?
http headers are case-insensitive, so no its not a problem
i noticed that you are using two different android devices, because the logs show differents system id's, are you sure that the playback with kodi 20 works also on the android device used for kodi 21?
another thing, on the items.py source code
for kodi >= v21 the license_headers must be url encoded to make sure that all chars are preserved correctly
code change example:
if self.plugin.get_kodi_version() >= 21:
drm_cfg = {
'DRM KeySystem': 'com.widevine.alpha',
'License server url': item.LaUrl,
'License headers': urlencode(license_headers)
}
listitem.setProperty('inputstream.adaptive.drm_legacy', '|'.join(drm_cfg.values()))
else:
"sure that the playback with kodi 20 works also on the android device used for kodi 21?" Sure. Before I reinstalled kodi 20 I had Kodi 21 on the android device and it did not work there too.
I will test it with urlencode
Change code to following:
from urllib.parse import urlencode
license_headers = {
'authorization': 'Bearer '+self.plugin.get_setting('token'),
'User-Agent': self.plugin.get_user_agent(),
}
if self.plugin.get_kodi_version() >= 21:
drm_cfg = {
'DRM KeySystem': 'com.widevine.alpha',
'License server url': item.LaUrl,
'License headers': urlencode(license_headers)
}
listitem.setProperty('inputstream.adaptive.drm_legacy', '|'.join(drm_cfg.values()))
else:
drm_cfg = {
'License server url': item.LaUrl,
'License headers': urlencode(license_headers),
Windows - Kodi 21: Working Android - Kodi 20: Working Android Kodi 21: Still not working
Same Log-files
Could this be an issue?
Android with Kodi 20:
2025-02-09 19:28:29.314 T:28745 debug
Edit:
Windows with Kodi 21 has the same veriy result, but three additional lines:
2025-02-12 23:31:24.590 T:14968 debug
Android with Kodi 21 has other three extra lines:
2025-02-09 19:51:14.952 T:14580 debug
Android with Kodi 20:
2025-02-09 19:28:29.314 T:28745 debug
"Using HTTP2, server supports multi-use"-lines are missing with Kodi 21 at Android. Using Stream ID: 1 is also missing
Could this be an issue?
2025-02-09 19:51:14.952 T:14580 debug : Curl::Debug - TEXT: SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
no idea http connections are managed from kodi core so nothing that ISA addon can change or try to workaround, the only thing that i know is that ssl cert pem file is updated regularly with each new kodi version (e.g. last kodi 22 nightly has pem cert file more updated than kodi 21) also to be taken into account that log output difference can be slightly different since the version of curl library has been updated in the new versions of kodi
but it could also depend on something else i don't know... for clarification/problems on ssl/curl you need to ask in the kodi (xbmc) repository or forum I don't have such deep knowledge
Hi, I'm following the discussion for a few days now. My mind is still struggeling with the different responses to the POST /widevine/v1/license... requests.
To recap: the working one responds with
HTTP/2 200
content-type: application/octet-stream
content-length: 716
vary: Origin
x-dazn-license-expiration: 2025-03-11T18:28:22.569Z
date: Sun, 09 Feb 2025 18:28:22 GMT
x-cache: Miss from cloudfront
via: 1.1 086613b3103277577d231678b44747c2.cloudfront.net (CloudFront)
x-amz-cf-pop: TXL50-P2
x-amz-cf-id: d1HdvCmST1Q-MoKosazmUFlidgYt2_xw380gU_Ww9e9nLFrcwOAKSg==
whereas the broken one reads
HTTP/2 401
content-type: application/json; charset=utf-8
content-length: 88
vary: Origin
date: Sun, 09 Feb 2025 18:51:14 GMT
x-cache: Error from cloudfront
via: 1.1 7fc97e30af7472a64e5a6feef4dbebba.cloudfront.net (CloudFront)
x-amz-cf-pop: TXL50-P2
x-amz-cf-id: 4RwYZhQ2MqWMEwV21p00wGGNxYZet6d_zWn844CGy_jspf3GNehLRA==
I want to emphasize the response header x-cache: Error from cloudfront – maybe it's already some CloudFront gateway that does not forward the request to the DAZN API in the broken case?
@MRLB already noted that the request headers are lower-case in the working example and upper-case in the broken one; @CastagnaIT already noted that HTTP headers are case-insensitive.
My train of thought:
Let's assume for a moment that HTTP are only supposed to be case-insentive, but the receiving end treats them in a case-sensitive manner. In other words: let's assume that the receiving server violates the HTTP standard.
Let's further notice that the requests are made with a User-Agent header set to something containing "Windows" and that we have the parameter manufacturer=microsoft in the Widewine URL. We all know that Windows is case-insentive in areas where other platforms (e.g. Linux) aren't.
So maybe there is some kind of (new) "request sanity check" at CloudFront: if one advertises as being a Windows agent but sends the headers in some non-Windows way (here: mixed-case), maybe CloudFront treats this as some kind of spoofing and immediately responds with 401 Unauthorized? (Being a backend developer myself, I could implement such a server feature if requested.)
As a last piece of information: my Linux-based browser (in which DAZN is working) sets the Widewine parameter manufacturer to unknown. And it's sending a User-Agent header containing the term Linux. So here we have "consistency" as well.
The conclusion would be: either ensure that headers are sent lower-case all the way, or advertise as Linux (with all headers and request parameters) if you're running in a Linux-like environment. (TBH: I don't know if that would address the ISA addon or the DAZN one, therefore: just my 2¢)
I would like to test it. With Kodi 20.5 and lower-case headers it is still working. With Windows and Kodi 21.2, also with lower-case headers it is also working. Only where upper-case headers are sent it is currently not working. Is there any possiblity to test it with lower-case headers? This is fix implemented in curl with is fix included in the kodi version, isn't it? Therefore, it would be difficult to find a way to test it.
Jumping into the discussion :) Did anyone try capturing official DAZN app / website and see if they specifically use lowercase headers as a primitive form of protection from unofficial clients :)
According to firefox no:
curl 'https://drm.playback.indazn.com/widevine/v1/license?...' -X POST -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0' -H 'Accept: */*' -H 'Accept-Language: de,en-US;q=0.7,en;q=0.3' -H 'Accept-Encoding: gzip, deflate, br, zstd' -H 'Referer: https://www.dazn.com/' -H 'authorization: Bearer xxx' -H 'Content-Type: application/octet-stream' -H 'x-correlation-id: ...' -H 'Origin: https://www.dazn.com' -H 'Connection: keep-alive' -H 'Sec-Fetch-Dest: empty' -H 'Sec-Fetch-Mode: cors' -H 'Sec-Fetch-Site: cross-site' -H 'TE: trailers' --data-raw $'...'
I can't replay it btw
someone can test on kodi 22? and post the log with debug enabled and kodi curl debug enabled? so that i can see if there is something useful on last updated kodi
Kodi 22 (kodi-20250215-cd3f2e08-master-armeabi-v7a.apk)- Android: https://paste.kodi.tv/uhizimunif.kodi
Still:
2025-02-16 14:13:55.003 T:6773 debug <general>: Curl::Debug - TEXT: ALPN: server accepted h2
2025-02-16 14:13:55.003 T:6773 debug <general>: Curl::Debug - TEXT: Server certificate:
2025-02-16 14:13:55.003 T:6773 debug <general>: Curl::Debug - TEXT: subject: CN=playback.indazn.com
2025-02-16 14:13:55.004 T:6773 debug <general>: Curl::Debug - TEXT: start date: Oct 3 00:00:00 2024 GMT
2025-02-16 14:13:55.004 T:6773 debug <general>: Curl::Debug - TEXT: expire date: Oct 31 23:59:59 2025 GMT
2025-02-16 14:13:55.004 T:6773 debug <general>: Curl::Debug - TEXT: subjectAltName: host "drm.playback.indazn.com" matched cert's "*.playback.indazn.com"
2025-02-16 14:13:55.004 T:6773 debug <general>: Curl::Debug - TEXT: issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M03
2025-02-16 14:13:55.004 T:6773 debug <general>: Curl::Debug - TEXT: SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
2025-02-16 14:13:55.004 T:6773 debug <general>: Curl::Debug - TEXT: Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
2025-02-16 14:13:55.004 T:6773 debug <general>: Curl::Debug - TEXT: Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
2025-02-16 14:13:55.004 T:6773 debug <general>: Curl::Debug - TEXT: Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
I am asking because in the urllib3 library an if-statement in the ssl.py-file was changed and with the current version already the request for https://api.playback.indazn.com/v5/Playback fails. Maybe the same issue? see: https://github.com/urllib3/urllib3/pull/3561