Beiträge von forrester

Zitat von rols1

Bei Punkt 2 würde ich den ersten Satz nur so umformulieren:
Addons können verschiedene python-libraries nutzen, ohne diese Proxy Konfiguration beachten zu müssen.
Bei Punkt 3 würde ich "durch python korrekt verarbeitet" ersetzen durch "durch Kodi korrekt verarbeitet" (Grund: Kodi nutzt C++-Quellen).

Mir fallen jetzt noch die Downloads ein: die nutzen urllib.urlretrieve für Python2 + 3, sollten nach unseren bisherigen Ergebnissen auch funktionieren.
/R

Deine Korrekturvorschläge habe ich gerne übernommen.

Ich habe unterschiedliche Downloads ausprobiert, wie du erwartet hast, haben sie ohne Probleme funktioniert, sowohl mit inputstream.adaptive-Addon als auch ohne.

Zitat von rols1

Das und auch das Ergebnis bei den Einzelauflösungen passt zu meiner Vermutung, dass Kodi beim Zugriff auf die HLS-Substreams am Proxy scheitert. Bei "Sofortstart aus" ermittelt das Addon die Streamadressen der einzelnen Auflösungen und übergibt nur die ausgewählte Adresse an Kodi. Beim MP4-Format entfallen Substreams - dort wird nur die Adresse des MP4-Streams übergeben, womit Kodi direkt den Player füttern kann.

Das passt zu den weiteren Tests, die ich mit "Sofortstart-Aus" mal tabellarisch zusammengefasst habe.

Zeit für mich mal zusammenzufassen, was ich bisher verstanden habe.

1. 
   Die Proxy Konfiguration im Kodi-Menü gilt zunächst mal nur für Kodi selbst.
2. 
   Addons können verschiedene python-libraries nutzen, ohne diese Proxy Konfiguration beachten zu müssen.
   Die Auswahl der Library spielt bei korrekter Benutzung keine entscheidene Rolle bezüglich des Problems.
   Grundsätzlich funktioniert damit ein url-Aufruf über ein in Kodi definierten http-Proxy.
3. 
   Es gibt aber bestimmte Situationen, bei denen die Proxy Konfiguration nicht korrekt verarbeitet wird.
   Diese könnten durch http-redirects verursacht sein, sollten aber eigentlich auch durch Kodi korrekt verarbeitet werden können.
   vgl. https://proxiesapi.com/articles/the-r…python-requests
4. 
   Viele dieser "Problem-Aufrufe" lassen sich dennoch durch Aktivierung des "inputstream.adaptive Addons" erfolgreich durchführen, bei sonst identischer Konfiguration.
   Konkret auch mit: "Sofortstart-Ein HLS-auto". Die Unterschiede in der Verarbeitung sind uns im einzelnen nicht bekannt.
5. 
   Aber auch mit aktivem "inputstream.adaptive Addon" gibt es spez. in der ZDF-Mediathek noch einige Aufrufe z.B. in der Rubrik "Unsere Spielfim Highlights", die mit der Einstellung "Sofortstart-Ein HLS-auto" eine direkte Kommunikation am Proxy vorbei initiieren und damit scheitern.
   In diesen Fällen kann aber nach Umschaltung auf "Sofortstart-Aus" und Einzelauflösung noch eine mp4-Datei (wenn angeboten) abgespielt werden.

6. 
   Bei allen funktionierenden Aufrufen unter Punkt 4 gibt es offensichtlich Unterschiede zu denen unter Punkt 5. Hier liegt wahrscheinlich der entscheidende Knackpunkt. Die genaue Ursache ist nicht erkennbar.

   
   

Bisheriges Fazit:

• Ist das "inputstream.adaptive Addon" deaktiviert und "Sofortstart-Ein", gibt es ein generelles Abspielproblem, da die Proxyfunktion mit dem HLS-auto nicht richtig funktioniert.
• Ist das "inputstream.adaptive Addon" aktiviert und "Sofortstart-Ein", funktionieren die meisten Filme korrekt, nur einige Filme aus der ZDF-Mediathek machen noch Probleme.
  Diese lassen sich aber durch "Sofortstart-Aus" beheben, sofern eine mp4-Datei angeboten wird.
• Gleichgültig ob das "inputstream.adaptive Addon" aktiviert ist oder nicht, kann man mit "Sofortstart-Aus" den Film abspielen, oder auch einen Download durchführen, sofern eine mp4-Datei angeboten wird.

Zitat von rols1

auch wieder akamei, ev. betrifft es die Substreams. Wie sieht es mit MP4 aus (Kontextmenü: Sofortstart AUS)?

Anbei nochmal ein tcpdump-logfile. Aufgerufen wird: ZDF-Mediathek-Startseite-Filme-"Unsere Spielfilm Highlights"-Kaengeruh-Film.

Erster Abschnitt mit "Sofortstart EIn" zeigt wieder das bekannte Verhalten, direkter IP-Zugriffsversuch nach dem Serverwechsel von "zdfvod.akamaized.net" zu "a1948.dscw4.akamai.net" mit DNS Abfrage.

Zweiter Abschnitt nach Umschaltung per Kontextmenü auf "Sofortstart aus". In den Zeilen 1891-1893 und 1930-1932 sieht man, dass die http-connects ohne neue DNS-Anfrage korrekt über den Proxy laufen.

Ausgewählt habe ich eine niedrige Auflösung einer mp4 Datei, die auch abgespielt wurde.

Ich hatte vorher noch vergeblich versucht die vorherige Version des inputstream.adaptive-Addon zu installieren. Geht das überhaupt, das man eine ältere Version instaliieren kann? Bei meinen Versuchen wurde weiterhin die aktuelle Versionsnr angezeigt, obwohl gleichzeitig eine Aktualisierung angeboten wurde. Habe dann mit aktuellen Version getestet.

Zitat

Dann sollte das Addon mit dem Proxy auch ohne inputstream.adaptive-Addon zurechtkommen können

Das probiere ich dann gerne aus.

Zitat

ich mache es kurz: Glückwunsch - das war doch (für uns beide) eine ziemlich harte Nuss. Für mich hat es auch etwas gebracht

Ich habe dabei ebenfalls viel über Libreelec, kodi und osmc gelernt. An dieser Stelle nochmals vielen Dank für deinen Support!

Aber es gibt wohl noch weitere Problemstellen.

Den Fehler beim ZDF-Film habe ich auch unter Librelec bekommen, sowohl mit der Testversion, als auch jetzt mit der aktuellen Version aus dem Repo. Bei fast allen Filmen die ich in der Rubrik "Unsere Spielfilm Hightlights" ausgewählt habe, gibt es Fehlermeldungen beim abspielen.

Die folgenden Logs und Aussagen beziehen sich auf:

- libreelec 12.0

- ardzdf 5.0.8 aus Repo mit aktualisiertem Einzelupdate vom 01.08.24

- aktualisiertem inputstream.adaptive-Addon Version 21.5.0.1

kodi.log mit debug=on zeigt:

2024-08-01 17:47:11.365 T:1109     info <general>: VideoPlayer::OpenFile: plugin://plugin.video.ardundzdf/?action=dirList&
dirID=ZDF_getApiStreams&fanart=https://www.zdf.de/assets/die-kaenguru-chroniken-104~840x280?cb=1693492072477&thumb=https:/
/www.zdf.de/assets/die-kaenguru-chroniken-104~840x280?cb=1693492072477%26fparams%3D%7B%27path%27%3A%20%27https%3A//zdf-pro
d-futura.zdf.de/mediathekV2/document/die-kaenguru-chroniken-102%27%2C%27title%27%3A%20%27Die%20K%C3%A4nguru-Chroniken%27%2
C%27thumb%27%3A%20%27https%3A//www.zdf.de/assets/die-kaenguru-chroniken-104~840x280%3Fcb%3D1693492072477%27%2C%27tag%27%3A
%20%27Dauer%3A%2001%3A28%20Std.%20%7C%20FSK%3A%20ohne%20%7C%20GEO%3A%20ohne%20%7C%20%5BB%5DVerf%C3%BCgbar%20bis%20%5BCOLOR
%20darkgoldenrod%5D13.09.2024%2001%3A59%5B/COLOR%5D%5B/B%5D%20%7C%20%5BB%5Dab%3A%2014.06.2024%5B/B%5D%20%7C%20%5BB%5DSpiel
film-Highlights%5B/B%5D%20%7C%20ZDF%27%2C%27summ%27%3A%20%27Wie%20reagiert%20man%2C%20wenn%20pl%C3%B6tzlich%20ein%20K%C3%A
4nguru%20ungefragt%20bei%20einem%20einzieht%3F%27%2C%27scms_id%27%3A%20%27SCMS_a6cc4172-e100-4fa5-9def-fb30d6455e44%27%7D
2024-08-01 17:47:11.380 T:3787     info <general>: Creating InputStream
2024-08-01 17:47:11.430 T:3787     info <general>: Creating Demuxer
2024-08-01 17:47:11.956 T:3783     info <general>: ARDundZDF --> check_seekTime 0.0, video_dur 0.0
2024-08-01 17:47:12.456 T:3783     info <general>: ARDundZDF --> Dict: store
2024-08-01 17:47:12.456 T:3783     info <general>: ARDundZDF --> Dict: Rekurs_check
2024-08-01 17:47:12.456 T:3783     info <general>: ARDundZDF --> Dict: <class 'str'>
2024-08-01 17:47:12.457 T:3783     info <general>: ARDundZDF --> dictfile: /storage/.kodi/userdata//addon_data/plugin.vide
o.ardundzdf/Dict/Rekurs_check
2024-08-01 17:47:12.457 T:3783     info <general>: ARDundZDF --> Subtitles: wait_for_Player(5 sec), sub_path: /storage/.ko
di/userdata/addon_data/plugin.video.ardundzdf/subtitles/F1026330_hoh_deu_Die_Kaenguru_Chroniken_261221.sub|https://utstrea
ming.zdf.de/mtt/zdf/21/12/211225_1730_sendung_fis/14/F1026330_hoh_deu_Die_Kaenguru_Chroniken_261221.vtt
2024-08-01 17:47:13.457 T:3783     info <general>: ARDundZDF --> player_isPlaying: 1 sec
2024-08-01 17:47:13.457 T:3783     info <general>: ARDundZDF --> Player_Subtitles: off
2024-08-01 17:47:13.457 T:3783     info <general>: ARDundZDF --> player_detect: True, live: 
2024-08-01 17:47:13.457 T:3783     info <general>: ARDundZDF --> leave_PlayVideo
2024-08-01 17:47:16.738 T:3787    error <general>: OpenDemuxStream - Error creating demuxer
2024-08-01 17:47:16.739 T:3787     info <general>: CVideoPlayer::OnExit()
2024-08-01 17:47:16.762 T:1109     info <general>: CVideoPlayer::CloseFile()
2024-08-01 17:47:16.762 T:1109     info <general>: VideoPlayer: waiting for threads to exit
2024-08-01 17:47:16.762 T:1109     info <general>: VideoPlayer: finished waiting

Zeitgleich zeigen die FW-Logs wieder geblockte Zugriffe auf : 23.2.13.218:443.

Zitat von rols1

Edit: das hätte ich beinahe vergessen: hat sich denn nach Umstellung auf requests überhaupt etwas verbessert?
/R

Eigentlich nicht.

Die unteren Menüebenen konnte ich auch vorher schon aufrufen und der Fehler taucht auch nach der Umstellung direkt beim Aufruf der Filme auf. Ich glaube auch nicht mehr das die Auswahl der requests-Bibliothek einen Unterschied macht. Meine Vermutung ist vielmehr die, das die Mediatheken von ARD und ZDF beim Filmaufruf einen http-redirect durchführen, um auf die jeweiligen Filmserver zu verweisen. Diese redirects (neue DNS-Abfrage) werden dann nicht korrekt von der python- proxy Bibliothek verarbeitet, vgl. z.B. https://proxiesapi.com/articles/the-r…python-requests

Zitat

Was man noch zum Abgleich ausprobieren könnte (ohne tcpdump):
- für Livestream-Tests: inputstream.adaptive-Addon installieren + in ARDundZDF freischalten. Ich kenne zwar nicht die Server-/client-Kommunikation bei der Initialisierung der Verbindung, aber insgesamt kommt inputstream.adaptive besser mit dem Streaming zurecht
- für Videotest: umschalten auf Einzelauflösungen statt Sofortstart (im Kontextmenü) und eine der mp4-Links starten. Beim ct-uplink-Addon ist mir aufgefallen, dass nur mp4-Videos verwendet werden.

Jetzt zum Positiven!

Das inputstream.adaptive-Addon war noch nicht installiert, die Freischaltung war bereits aktiviert. Videoformat bei Sofortstart ist "HLS", qualität ist "auto". Beides habe ich so belassen.

Ergebnis:

Im tcpdump-log sieht man, das nach den Stellen (DNS-Query : A mcdn.br.de CNAME br-stream.trafficmanager.net CNAME mcdn-br.akamaized.net CNAME a1897.dscw4.akamai.net A 23.2.13.200 A 23.2.13.202) kein direkter IP-Aufruf mehr am Proxy vorbei versucht wird, sondern die Kommunikation (Abspielen des Films) weiter über den Proxy läuft.

59   1.052530 kodi-ip → proxy-ip DNS 70 Standard query 0x263a A mcdn.br.de                                                                                                                                                                                   
60   1.052840 proxy-ip → kodi-ip DNS 209 Standard query response 0x263a A mcdn.br.de CNAME br-stream.trafficmanager.net CNAME mcdn-br.akamaized.net CNAME a1897.dscw4.akamai.net A 23.2.13.200 A 23.2.13.202
61   1.055720 kodi-ip → proxy-ip TLSv1.3 353 Application Data
62   1.068660 proxy-ip → kodi-ip TCP 2946 [TCP segment of a reassembled PDU]
63   1.069260 proxy-ip → kodi-ip TCP 7306 8080 → 54680 [PSH, ACK] Seq=8319 Ack=1406 Win=64128 Len=7240 TSval=2183037997 TSecr=47151776 [TCP segment of a reassembled PDU]
64   1.069360 proxy-ip → kodi-ip TCP 2906 8080 → 54680 [PSH, ACK] Seq=15559 Ack=1406 Win=64128 Len=2840 TSval=2183037997 TSecr=47151776 [TCP segment of a reassembled PDU]
65   1.069901 proxy-ip → kodi-ip TCP 1514 8080 → 54680 [ACK] Seq=18399 Ack=1406 Win=64128 Len=1448 TSval=2183037997 TSecr=47151776 [TCP segment of a reassembled PDU]
66   1.076800 kodi-ip → proxy-ip TCP 66 54680 → 8080 [ACK] Seq=1406 Ack=8319 Win=31872 Len=0 TSval=47151797 TSecr=2183037996
67   1.076859 proxy-ip → kodi-ip TLSv1.3 3966 Application Data, Application Data
68   1.082736 kodi-ip → proxy-ip TCP 66 54680 → 8080 [ACK] Seq=1406 Ack=11215 Win=31872 Len=0 TSval=47151801 TSecr=2183037997
69   1.085187 kodi-ip → proxy-ip TCP 66 54680 → 8080 [ACK] Seq=1406 Ack=14111 Win=31872 Len=0 TSval=47151805 TSecr=2183037997
70   1.088628 kodi-ip → proxy-ip TCP 66 54680 → 8080 [ACK] Seq=1406 Ack=17007 Win=31872 Len=0 TSval=47151809 TSecr=2183037997
71   1.088695 kodi-ip → proxy-ip TCP 66 54680 → 8080 [ACK] Seq=1406 Ack=19847 Win=31872 Len=0 TSval=47151809 TSecr=2183037997
72   1.091386 kodi-ip → proxy-ip TCP 66 54680 → 8080 [ACK] Seq=1406 Ack=22743 Win=31872 Len=0 TSval=47151812 TSecr=2183038004

Ich habe in den Tests unter allen von mir gewählten Menüpunkten einen Film abspielen können!

Um verifizieren zu können, dass es keine Abhängigkeiten von der python-proxy-Methode gibt habe ich deine "normale" 5.0.8er Repo-Version auch unter einem aktuellen "osmc" ausprobiert. Hier sind ja noch deine "alten" Proxy-Bibliotheks-Aufrufe aktiv. Gut, "osmc" hat eine kodi Version 20.5 glaube ich und ein bereits integriertes inputstream.adaptive-Addon.

Aber auch hier konnte ich mit den gleichen EInstellungen keine Proxy Probleme feststellen! Alle Test liefen durch.

Bei der Auswahl eines ZDF-Films habe ich nochmal eine Fehlermeldung bekommen, die aber wohl nichts mit der Proxykonfiguration zu tun hat. Hier der entsprechende Auszug aus dem kodi.log von osmc:

2024-08-01 11:56:28.290 T:5127     info <general>: ARDundZDF --> check_AddonXml:                                                                                                                                                                             
2024-08-01 11:56:30.380 T:5127  warning <general>: Skipped 2 duplicate messages..
2024-08-01 11:56:30.380 T:5127  warning <general>: Setting most video properties through ListItem.setInfo() is deprecated and might be removed in future Kodi versions. Please use the respective setter in InfoTagVideo.
2024-08-01 11:56:30.498 T:576      info <general>: VideoPlayer::OpenFile: plugin://plugin.video.ardundzdf/?action=dirList&dirID=ZDF_getApiStreams&fanart=https://www.zdf.de/assets/die-kaenguru-chroniken-104~840x280?cb=1693492072477&thumb=https://www.zdf.de/assets/die-kaenguru-chroniken-104~840x280?cb=1693492072477%26fparams%3D%7B%27path%27%3A%20%27https%3A//zdf-prod-futura.zdf.de/mediathekV2/document/die-kaenguru-chroniken-102%27%2C%27title%27%3A%20%27Die%20K%C3%A4nguru-Chroniken%27%2C%27thumb%27%3A%20%27https%3A//www.zdf.de/assets/die-kaenguru-chroniken-104~840x280%3Fcb%3D1693492072477%27%2C%27tag%27%3A%20%27Dauer%3A%2001%3A28%20Std.%20%7C%20FSK%3A%20ohne%20%7C%20GEO%3A%20ohne%20%7C%20%5BB%5DVerf%C3%BCgbar%20bis%20%5BCOLOR%20darkgoldenrod%5D13.09.2024%2001%3A59%5B/COLOR%5D%5B/B%5D%20%7C%20%5BB%5Dab%3A%2014.06.2024%5B/B%5D%20%7C%20%5BB%5DSpielfilm-Highlights%5B/B%5D%20%7C%20ZDF%27%2C%27summ%27%3A%20%27Wie%20reagiert%20man%2C%20wenn%20pl%C3%B6tzlich%20ein%20K%C3%A4nguru%20ungefragt%20bei%20einem%20einzieht%3F%27%2C%27scms_id%27%3A%20%27SCMS_a6cc4172-e100-4fa5-9def-fb30d6455e44%27%7D
2024-08-01 11:56:30.583 T:5131     info <general>: Creating InputStream
2024-08-01 11:56:30.654 T:5131     info <general>: Creating Demuxer
2024-08-01 11:56:35.865 T:5131    error <general>: OpenDemuxStream - Error creating demuxer
2024-08-01 11:56:35.866 T:5131     info <general>: CVideoPlayer::OnExit()
2024-08-01 11:56:35.882 T:576      info <general>: CVideoPlayer::CloseFile()
2024-08-01 11:56:35.882 T:576      info <general>: VideoPlayer: waiting for threads to exit
2024-08-01 11:56:35.882 T:576      info <general>: VideoPlayer: finished waiting

Den Aufruf könnte man zum Vergleich noch mal unter Libreelec durchführen.

Mein vorläufiges Fazit:

Egal welche Proxy Bibliothek verwendet wird, bei der Form der ARD-ZDF-redirects gibt es die gleichen Probleme, die offensichtlich vom inputstream.adaptive-Addon korrekt verarbeitet werden.

Mich würde mal interessieren, was das inputstream.adaptive-Addon in der Funktionsweise anders macht.

Zitat von rols1

forrester :
pardon, für LibreElec war noch eine Ergänzung notwendig, damit die requests-Bibliothek überhaupt zur Verfügung steht. Das neue Testadon habe ich soeben mit LibreElec 12.0.0 getestet. Neues Testaddon auf gmx - ich drücke die Daumen..
/R

Mit dem aktuellen Test-Addon kommt man wieder in die Untermenüs und kann einzelne Filme auswählen.
Dann folgt wieder der bekannte Zugriffsfehler.

Ich habe mal einen tcpdump mitlaufen lassen und gleichzeitig das Proxy-Logfile betrachtet.
Sehr viel läuft korrekt über den Proxy, aber an den Problem-Stellen wird z.B. nach einer erneuten DNS-Abfrage versucht eine direkte Verbindung dorthin aufzubauen. Das passierte beim Aufruf eines Films aus der ARD-/ZDF-Mediathek und beim TVLivestream, hier z.B BR-Sued.

Anmerkung: Proxy-IP ist bei mir = DNS-Server-IP (Resolver)

Das Einzelupdate funktionierte übrigens einwandfrei, war aber alles bereits aktuell.

Anbei Ausschnitte aus dem tcpdump-log (uploadsnippets.txt). Ich habe die IP-Adressen von kodi und proxy mit Namen überschrieben.
Die Abschnitte sind mit einem Kommentar markiert.

Hier noch eine Liste der von kodi angefragten URL's, die der Proxy während des Testlaufes geloggt hat.

api.ardmediathek.de:443                                                                                                         
api.zdf.de:443
github.com:443
hbbtv.zdf.de:443
kodi.mirror.liteserver.nl:443
mcdn.br.de:443
mirrors.kodi.tv:443
raw.githubusercontent.com:443
releases.libreelec.tv:443
universal-vod.daserste.de:443
update.libreelec.tv:443
www.kodinerds.net:443
www.zdf.de:443
zdf-prod-futura.zdf.de:443
zdfvod.akamaized.net:443

Hilft uns das weiter?

Zitat von rols1

Nutzung der requests-Bibliothek (python3.*) i.Z.m. Nutzung eines Proxies - Testaddon

forrester:
Weiterführende Infos konnte ich keine auftreiben. Eine Kodi-Funktion, die Addons bei direkten Internetzugriffen die in Kodi gesetzten Proxy-Parameter verwenden lässt, hab ich keine gefunden.
Aus den Kodi-Quellen kann ich entnehmen, dass die Proxy-Settings nur für eigene Aufrufe genutzt werden. Falls Du hier selbst weitersuchen möchtest: die Headerdatei ist CurlFile.h mit class CCurlFile . Der Code befindet sich in CurlFile.cpp .
Als Suchstring nach Vorkommen von CCurlFile im xbmc-Repo von Github kann man verwenden: https://github.com/search?q=repo%3Axbmc%2Fxbmc%20CCurlFile&type=code

Also ein neuer Versuch: wir haben die Situation, dass Zugriffe des Addons ardundzdf von der Firewall geblock werden. Dagegen rufen c't uplink und ARDAktuell ihre Quellen problemlos ab. Dabei nutzen sie die requests-Bibliothek, während ardundzdf die Request-Funktionen aus urllib2 (python2) bzw. urllib.request (python3) verwendet. Ich halte es für ausgeschlossen, dass Kodi bei gesetzten Proxy-Settings die Abrufe abfängt, mit Settings impft und dann weiterleitet.
Das Testaddon auf gmx nutzt daher die requests-Bibliothek, wie c't uplink und ARDAktuell.

Sollte damit die Proxy-Nutzung nicht funktionieren, muss ich erstmal passen. Für weiterführende Tests bräuchte es ein identisches Setup - dafür fehlt mir leider die Zeit.
/R

Alles anzeigen

Zunächst mal Danke für die Mühe!

Ich habe die zip-Datei heruntergeladen und nach Deinstallation der bisherigen Version neu installiert. Ich kann noch die erste Menüebene auswählen, also ARD-,ZDF-,Arte-Mediathek usw.. In der zweiten Ebene passiert dann nach der Auswahl eines Menüpunktes nur eine kurze Pause und dann wird der gleiche Bildschirm wieder angezeigt. Das passiert in allen von mir ausgewählten Mediatheken. Die Firewall zeigt während dessen keine geblockten Zugriffe!

Ein Test, ob Einzelupdates funktionieren erbrachte das Gleiche Verhalten.

Nur ein Test unter "TV-Livestream-Regional-BR-Süd" hat wieder die Fehlermeldung gezeigt und entsprechende Logeinträge in der FW erzeugt. In diesem Fall wurde 23.53.40.202:443 geblockt.

Gedanken:

Ich bin kein python Programmierer. Aber in der bisherigen Variante haben einige Internetzugriffe korrekt funktioniert, also muss diese Form des Zugriffs den Proxyaufruf korrekt benutzt haben. Die geblockten Aufrufe müssten demnach die URL's auf eine andere Art aufgerufen haben. Gibt es denn unterschiedliche Formen der URL-Aufrufe in deinem Code?

Zitat von rols1

Danke für die Tests. Im Moment kann ich mir noch keinen Reim darauf machen. Bist du in der Lage, auf dem LE-Gerät ein paar Abrufversuche mit Curl zu machen? Ein einfacher Test wäre der Abruf der master.m3u8-Datei für den DasErste-Livestream:
curl -v https://daserste-live.ard-mcdn.de/daserste/live/hls/de/master.m3u8
Wenn er durchkommt und die Datei mit den #Ext-X-Zeilen ausgibt, wäre die Client-Server-Kommunikation interessant. Die gibt Curl oberhalb der Datei (oder der Fehlermeldung) aus.
/R

ssh root@libreelec um curl im Terminal aufrufen zukönnen:

LibreELEC:~ # curl -v https://daserste-live.ard-mcdn.de/daserste/live/hls/de/master.m3u8
* Host daserste-live.ard-mcdn.de:443 was resolved.
* IPv6: (none)
* IPv4: xx.yyy.zzz.ww
*   Trying 92.223.124.62:443...

Da curl keine Infos zur Proxy Benutzung hat, wird der direkte Zugriffsversuch ebenfalls blockiert. Die env-Variable von root weist keinen Proxy auf.

curl müsste mit dem Environment von kodi gestartet werden, um eine Aussage zu bekommen. Enen User "kodi" kann ich aber unter Libreelec nicht finden.

LibreELEC:~ # pstree |grep kodi
        |-kodi.sh---kodi.bin-+-{AESink}
        |                    |-{kodi.bi:disk$0}
        |                    |-2*[{kodi.bin}]

LibreELEC:~ # ps ax |grep kodi
1086 root      0:00 {kodi.sh} /bin/sh /usr/lib/kodi/kodi.sh --standalone -fs --audio-backend=alsa+pulseaudio
1101 root      3:12 /usr/lib/kodi/kodi.bin --standalone -fs --audio-backend=alsa+pulseaudio

Zitat von rols1

OK, dann bitte nochmal zwei Versuch mit arte. Ich meine nicht den Stream in TV-Livestreams, sondern das LIVE-Menü im Modul arte (ev. noch in den Settings Allgemein freischalten), s. erstes Bild:
nach dem ersten Versuch den Sofortstart umschalten und das LIVE-Menü erneut anwählen. Bei ausgeschaltetem Sofortstart sollte der Button für den HLS-Stream erscheinen, s. 2. Bild.

Hintergrund: bei der zweiten Variante wird der Stream über xbmcplugin.setResolvedUrl() an Kodi übergeben. Wenn meine Vermutung stimmt, sollten dabei die gesetzten Proxy-Parameter greifen und das Abspielen klappen.
/R

Leider ist das Ergebnis bei beiden Varianten gleich.

Bei ausgeschaltetem Sofortstart bekomme ich zwar den Button für den HLS-Stream, aber wenn ich diesen auswähle wird ebenfalls ein Direktzugriff vorgenommen mit der gleichen Fehlermeldung.

Zitat von rols1

die beiden Adressen gehören zu 1&1, vermutlich deren DNS-Server.

Die Anfragen an die beiden IP-Adressen kommen drekt von LibreElec.

Auch nach Deaktivierung aller Addons werden die Anfragen direkt nach dem Start von LE gesendet und dienen wohl einem online status check.

In der Datei /etc/connman/main.conf steht:

# Urls (IPv4 and IPv6 respectively) used during the online status check.
# Please refer to the README for more detailed information.
# Default values are http://ipv4.connman.net/online/status.html and
# http://ipv6.connman.net/online/status.html respectively.
# OnlineCheckIPv4URL= http://ipv4.connman.net/online/status.html
# OnlineCheckIPv6URL= http://ipv6.connman.net/online/status.html

Kann man auch abschalten:

# Enable use of http get as on online status check.
# When a service is in a READY state, and is selected as default,
# ConnMan will issue an HTTP GET request to verify that end-to-end
# connectivity is successful. Only then the service will be
# transitioned to ONLINE state.
# If this setting is false, the default service will remain in READY state.
# Default value is true.
# EnableOnlineCheck = false

Die Anfragen an die beiden IP-Adresen haben also nix mit Addon-Proxyproblem zu tun.

Zitat von rols1

die beiden Adressen gehören zu 1&1, vermutlich deren DNS-Server.

die beiden Adressen gehören zu akamaitechnologies, also einer der möglichen Videoserver.

Neben dem Zugriff auf Github für Updates funktionieren offensichtlich auch weitere Zugriffe, denn bis zum (misslingenden) Videostart sind eine Reihe von api-Abfragen notwendig.
Ich hatte mir im Vorfeld schon ein paar Gedanken dazu gemacht und mir auch ct-uplink und ardaktuell angesehen:

Die Proxy-Einstellungen von Kodi spielen m.E. für Video-Addons nur eine Rolle beim Start des Players, wo das Addon das Listenobjekt (mit Videourl) mit der Funktion xbmcplugin.setResolvedUrl() an Kodi übergibt. Der Weg zur Ermittlung einer Videoquelle kann aber mehrstufig sein und mehrere http-Abrufe erfordern. Diese macht das Addon direkt und verwendet dafür eine der Request-Bibliotheken von python, abhängig von der benutzten python-Version. Oder das Addon verwendet ein spez. Modul (z.B. feedparser für die RSS-Quellen). Dieses benutzt dann seinerseits eine (i.d.R. aktuelle) Request-Bibliothek.

ardaktuell verwendet die requests-Bibliothek von python für den Abruf von Quellen
ct-uplink verwendet für den Abruf seiner rss-Datei das python-Modul feedparser. feedparser hat laut Github letztes Jahr vom eigenen http-Client-Code zur requests-Bibliothek gewechselt.
Mein Addon verwendet aus Kompatibilitätsgründen die Request-Funktionen aus urllib2 (python2) und urllib.request (python3).
Dort könnte eine Ursache liegen. Ich kann mir aber auch vorstellen, dass der sparsame Umgang mit http-Headern in meinem Addon eine Rolle spielt. Ich verwende sie nur dort und auch nur die benötigten, wo z.B. apiToken erforderlich sind oder spez. Ausgabeformate (z.B. json) gewünscht sind. Daher habe ich nachgefragt, wo der Zugriff nicht funktioniert.

Was in Hinblick auf die verwendeten Header noch getestet werden könnte, wären die Livestreams und die Live-Menüs von 3sat und arte. Ev. wird das Bild dann etwas klarer.
/R

Alles anzeigen

Ja, dass die beiden Adressen zu 1&1 gehören habe ich auch festgestellt. Allerdings wird Port 80 angesprochen und nicht 53.
Ausserdem habe ich weder 1&1 noch irgendwo deren Nameserver konfiguriert.
Sollten diese Adressen in einem der Addons bzw. in Kodi/Librelec fest einprogammiert sein?

Wenn ich aus der arte bzw. 3sat-Mediathek einen Livestream auswähle, erhalte ich die gleiche Fehlermeldung und der Zugriff auf Port 443 folgender Ip-Adressen wird direkt versucht:

3sat
104.83.4.139:443
104.83.4.144:443

arte
23.38.123.201.443
23.38.123.231.443

Zitat von rols1

Bevor ich mir Unterschiede zu den genannten anderen Addons ansehe: funktioniert kein einziger Zugriff oder sind nur einzelne Module oder nur Livestreams betroffen?
/R

1.

Nach dem Start von Libreelec/Kodi werden direkt Syn-Anfragen an folgende Adressen gesendet:
82.165.8.211:80
212.227.81.55:80

Welches Addon diese Verbindungen aufbauen möchte kann ich nicht erkennen. Die beiden Adressen werden aber immer wieder während des (passiven) Betriebes von Kodi angesprochen.

2.

Das Addon lässt sich starten, die Auswahl eines Menüpunktes z.B ZDF... oder TagesschauXL ist möglich und deren Unterpunkte werden ebenfalls angezeigt und sind auch auswählbar.
Erst wenn eine Sendung zum Abspielen ausgewählt wird, erscheint die Fehlermeldung:
"Wiedergabe nicht möglich. Allgemeiner Fehler bei der Wiedergabe".
Zeitgleich wird versucht eine direkte IP-Verbindung z.B. nach:
23.50.131.31:443
23.53.41.81:443
aufzubauen .

3.

Interessant ist, dass ein Einzelupdate des Addons ohne Probleme funktionierte.

Hallo rols1,

Ich benutze LibreElec 12.0 mit Kodi 21.
Ich habe das Kodi-Addon-ARDundZDF Version 5.0.8 installiert.

Ausserdem sind auch folgende offiziellen Kodi-Video-Addons installiert: c't uplink, Media.ccc.de und ARDAktuell.

Die Firewall Regeln des Routers lassen nur authentifizierten Traffic über den Proxy ins Internet.

In den Kodi-Einstellungen ist die Benutzung eines authentifizierenden HTTP-Proxy's aktiviert:
- Use Proxy Server
- http-proxy
- IP-Adresse des Proxies
- Port des Proxies
- Username
- Password

Die oben genannten offiziellen Addons funktionieren damit einwandfrei, ohne dass in deren Einstellungen explizit auf einen Proxy verwiesen wird. Hier werden offensichtlich die Kodi-Einstellungen implizit übernommen.

Leider funktioniert die Proxy-Einstellung nicht mit dem ARDundZDF-Addon, dieses versucht eine direkte Verbindung zu den jeweilgen IP-Adressen auf Ports 80 bzw. 443 und wird von der Firewall geblockt.
Die Folge ist dann eine Meldung "Videoquelle nicht verfügbar".

Ist es möglich, wie bei den obigen Addons, die Kodi-Proxy Einstellungen zu berücksichtigen, oder eine Proxy-Einstellmöglichkeit im Addon bereitzustellen?