2025-03-30 14:23:19.229 T:24081 warning <general>: AddOnLog: inputstream.adaptive: SaveServiceCertificate: Empty Service Certificate
LPM.setProperty('inputstream.adaptive.server_certificate', certificate_data)
...fehlt scheinbar, deswegen kann ggf. auch bei Android TV ein 403-Fehler auftreten.
Um VMP auszuschließen, realvito hast du das Service-Certificate implementiert?
With some service provider you may need to add the server certificate (see Integration#inputstreamadaptiveserver_certificate).
bei mir dreht sich der Spinner nur ewig und es passiert garnix.
Und wie sieht bei dir die Debug
License server returned failure (HTTP error 403)
Linux wird ja geblockt, insofern ist auch nichts anderes zu erwarten.
Das muss man doch austricksen können, wegen AWS und Bot-Einstufung.
Gewisse Dinge kann man nicht legal austricksen. Wenn der Anbieter nicht will, dass diese Streams auf Linux-Geräten laufen, dann laufen diese Streams dort auch nicht, ohne mit unlauteren Methoden dagegen vorzugehen, was wohl nicht im Sinne von Kodi als legales Mediencenter ist. Denn im Widevine-Request wird wohl auch die Plattform genannt.
Android-Geräte dürften aber zu den unterstützten Devices zählen, und dort dürfte dann die Bot-Geschichte bei Kodi problematisch sein.
Ich habe mal im Issue-Eintrag für Dazn einen entsprechenden Hinweis hinterlassen, mal sehen, ob es etwas bringt, denn dort experimentiert man noch mit Widevine und VMP herum.
Es liegt bereits an der Art und Weise, wie InputStream Adaptive die Anfrage an den Server sendet. Es geht um TLS-Signaturen und JA3-Fingerprints, die normale Browser mitsenden, was aber bei InputStream Adaptive zu fehlen scheint, genauso wie bei den üblichen Python-Packages.
Für Python gibt es ein Package, um solche Signaturen zu imitieren, was auch tatsächlich funktioniert - dahingehend müsste man also InputSteam aktualisieren und mit diesen Features ausstatten. peak3d
Die Art und Weise der strptime-Nutzung ist aber auch gefährlich, da manche Python-Versionen diesbezüglich verbuggt sind - dafür nutze ich immer diesen Workaround:
datetime(*(time.strptime(labelDate, "%d.%m.%Y %H:%M")[0:6]))
Vermutlich werden die Kodi-Systeme wieder mal von AWS/Cloudfront als Bots eingestuft, wie bei Sky CH und Dazn. Da könnt ihr euch bei Amazon bedanken. Unerklärbare Wiedergabeprobleme tauchen nur dann auf, sobald AWS ins Spiel kommt.
Bitte prüfen, ob es hiermit wieder geht. Falls ja, dann schiebe ich die Addon-Version hoch.
Klar, ein Gerät mit Widevine L1-Zertifizierung reicht wohl nicht, ist vermutlich zu alt. ![[ap]](https://www.kodinerds.net/wcf/images/smilies/smiley53.gif "ap"){kind=small}
Dein Problem hat nichts mit der bereits behobenen Störung zu tun, die vermutlich durch die Zeitumstellung aufgetreten ist.
Wieso wechselt nur bei einem Kanal der MPD-Aufbau hin und her? Gibt es dann in der offiziellen App auch mehrere Videostreams zur Auswahl?
... ich glaube eher, dass es was mit widevine zu tun hat.
Das Laden von Bildern und Thumbnails hat mit Widevine nichts zu tun und hat bis zur Behebung des Fehlers auch nicht funktioniert.
Bitte bei Telerising in den API-Settings die Option "Enable ".m3u8"/".mpd" link extension" aktivieren. Dann in tvHeadend die Senderliste neu einlesen lassen und anschließend den Scan starten.
Nun sollte wieder alles funktionieren 
Siehe oben. Die einfachste Lösung wäre die Abschaffung der Zeitumstellung.
Die Adressen können in der tvHeadend-Konfiguration bei DVB Inputs / Muxes angepasst werden.
pipe:///usr/bin/ffmpeg -loglevel debug -re -i "http://192.168.0.69:5000/api/tby/live/310" -ignore_unknown -map 0:0 -map 0:1 -map 0:2? -map 0:3? -map 0:4? -c:a:0 copy -c:a:1 copy -c:v copy -c:s copy -f mpegts -metadata service_name="Arte de" pipe:1
Versuche es bitte nochmal mit -loglevel debug. Scheinbar können die Streams nicht geöffnet werden, aber ffmpeg wird korrekt ausgeführt.
Nur zur Info, Waipu hat seit heute Nacht eine Störung, was Aufnahmen und die Waiputhek-Inhalte angeht - hat nichts mit dem Addon zu tun.
