Proxy Authentication - Problem mit MediathekView

[bartull]

Systembeschreibung:

Debian 9.6 (stable) und MV 13.2.1 hinter einem Proxy mit Userauthentifizierung, d.h jeder
direkte Verbindungsaufbau ins Internet am Proxy vorbei wird in der Firewall geblockt.
VLC liegt als Debian Paket in der Version 3.0.3 Vetinari vor.

Problembeschreibung:
Kein Download über den Proxy möglich, da trotz Proxykonfiguration versucht wird eine direkte Verbindung zum Internet aufzubauen.

Ich habe folgende Konfiguration ausprobiert:

1. GUI-Proxy-Konfiguration

Unter Einstellungen - Allgemein - HTTP-Proxy : Port , User : Passwort
die entsprechenden Proxy Zugangsdaten angegeben.

• MV startet und aktualisiert die Filmliste korrekt über den Proxy.
• Beim Start wird ausgegeben: Proxy Authentication: not configured
• Filme können weder abgespielt noch downgeloaded werden, da vlc eine direkte Internetverbindung aufzubauen versucht.
  
  

2. GUI-Proxy-Konfiguraion und Proxy-Aufrufparameter

Neben der GUI-Proxy Konfiguration werden in der MediathekView.sh die Proxy-Parameter ergänzt.

if [ -n "$JAVA_HOME" ]; then
  $JAVA_HOME/bin/java -Xmx1G -Dhttp.proxyHost=192.168.1.99 -Dhttp.proxyPort=8080 -Dhttp.proxyUser=tv -Dhttp.proxyPassword=geheim -jar ./MediathekView.jar "$@"
else
  java -Xmx1G -Dhttp.proxyHost=192.168.1.99 -Dhttp.proxyPort=8080 -Dhttp.proxyUser=tv -Dhttp.proxyPassword=geheim -jar ./MediathekView.jar "$@"
fi

• MV startet und aktualisiert die Filmliste korrekt über den Proxy.
• Beim Start wird ausgegeben: Proxy Authentication: (tv).
• Filme können weder abgespielt noch downgeloaded werden, da vlc eine direkte Internetverbindung aufzubauen versucht.
  

3. GUI-Proxy-Konfiguraion und Proxy-Aufrufparameter und Proxy-Environment Variablen

Zusätzlich zu den unter 2. gemachten Angaben werde die Environmentvariablen http_proxy und https_proxy vor
dem MV Aufruf in der MediathekView.sh gesetzt.

export http_proxy=http://tv:geheim@192.168.1.99:8080
export https_proxy=http://tv:geheim@192.168.1.99:8080

Anmerkung: Mir ist für diese vlc-Version keine andere Möglichkeit der http-Proxy Konfiguration bekannt. Lediglich für einen Socks-Proxy gibt die Hilfe aus:

vlc --advanced --help |grep -A3 -i proxy
VLC media player 3.0.3 Vetinari (revision 3.0.3-1-0-gc2bb759264)
   SOCKS-Proxy:
      --socks <Text>             SOCKS-Server
      --socks-user <Text>        SOCKS-Benutzername
      --socks-pwd <Text>         SOCKS-Passwort

• MV startet und aktualisiert die Filmliste korrekt über den Proxy.
• Beim Start wird ausgegeben: Proxy Authentication: (tv).
• Abspielen eines Films mit vlc funktioniert.
• Download startet wird angezeigt, kommt aber nicht zustande, da wieder eine direkter Verbindungsaufbau zum Internet versucht wird, obwohl vorher noch ausgegeben wird, dass eine Proxy angegeben ist. Beim Film-Abspielen erschien diese Ausgabe nicht.

. Proxy Authentication from environment vars: (tv)
. MVHttpClient: Proxy configured from environment variables: (192.168.1.99)

Anmerkung:
Versuche ich den Film über die von MV angegebene https-Adresse mittes wget herunterzuladen, so funktioniert das aufgrund der korrekten Proxyangabe in meiner .wgetrc ohne Probleme. Daher vermute ich das Problem bei der Übergabe der Proxyparameter an vlc.

Fragen:

• Ist dieses Proxy-Auth Problem bekannt?
• Fehlt mir noch eine Konfigurationsangabe?

[styroll]

@bartull sagte: MV startet und aktualisiert die Filmliste korrekt über den Proxy.
Beim Start wird ausgegeben: Proxy Authentication: not configured
Filme können weder abgespielt noch downgeloaded werden, da vlc eine direkte Internetverbindung aufzubauen versucht.

Wenn sich nichts geändert hat, dann dient der Proxy – immer noch – bloss dem Laden der Filmliste via Proxy, was bei dir ja auch funktioniert.

Externe Programme müssen separat konfiguriert werden (FFmpeg, VLC, Flvstreamer), wobei VLC und Flvstreamer für den Download praktisch nicht mehr zum Einsatz kommen. Diesbezügliche Probleme wären also direkt keine Probleme, die MV selbst betreffen.

@bartull sagte: Versuche ich den Film über die von MV angegebene https-Adresse mittes wget herunterzuladen, so funktioniert das aufgrund der korrekten Proxyangabe in meiner .wgetrc ohne Probleme.

Dann kannst du ja ein Set erstellen, welches die Video-URLs aus der MV-Filmliste an wget, aria oder JDownloader übergibt und dann das ganze Proxyhandling diesen Programmen überlassen.

[herbivore]

Hallo styroll,

auch wenn ich nicht der Threadstarter bin, bleiben aus meiner Sicht nach deiner Antwort zwei Punkte offen:

Sollten die Proxy-Einstellungen nicht auch für den Filmdownload direkt in Mediathekview wirken? Oder wirklich nur für den Filmlistendownload? Und wenn nur letzteres, warum diese Differenzierung?

Warum wirken (vorausgesetzt die Beobachtungen von bartull stimmen) die zwei Wege, über die man Proxy-Einstellungen vornehmen kann (Einstellungsdialog und Kommandozeile) unterschiedlich? Klar, die Kommandozeile sollte Vorrang haben, aber anderseits nicht erforderlich sein, wenn man bereits den Einstellungsdialog benutzt hat. Nach “Proxy Authentication:” sollte (wenn ichs richtig interpretiere) in diesem Fall nicht “not configured” stehen.

Möglicherweise kann diese Fragen nur ein Entwickler beantworten.

herbivore

[styroll]

@herbivore sagte: Sollten die Proxy-Einstellungen nicht auch für den Filmdownload direkt in Mediathekview wirken?

Das soll gem. diesem Post in der Version 13.0.6 auch mal funktioniert haben. Hier noch eine weitere Ausführung des Gründer des Projekts, warum die Proxy-Konfig mit MV 4 aus der GUI entfernt wurde.

[DerReisende77]

@herbivore grundsätzlich wird für den Filmdownload derzeit noch die alte integrierte Java Netzwerk Klasse URLConnection verwendet. Diese wird ausschließlich über Umgebungsvariablen konfiguriert. Das hat funktioniert und sollte auch weiterhin funktionieren da nichts geändert wurde. Ich schaue es mir die Tage Mal an bin aber momentan anderweitig unterwegs

[bartull]

Vielen Dank für die interessanten Anmerkungen!

Als absoluter MV-Newbie versuche ich mal zusammenzufassen was ich meine bisher verstanden zu haben:

• die Proxy-Konfiguration in der GUI gilt nur für das Laden der Filmliste
• die Proxy-Konfiguration in der GUI funktioniert auch wie beabsichtigt, gibt allerdings die Meldung Proxy “not configured” aus.
• Lt. styroll kommen VLC und Flvstreamer für den Download praktisch nicht mehr zum Einsatz
• Lt. DerReisende77 (Entwickler) wird für den Filmdownload derzeit noch die alte integrierte Java Netzwerk Klasse URLConnection verwendet.
• Die Proxyparameter in der Kommandozeile sind für die Übergabe an externe Programme notwendig und führen zur Ausgabe “Proxy Authentication: (tv)”
• Eigentlich sollte die alte integrierte Java Netzwerk Klasse URLConnection für den Download über eine Proxy funktionieren, wenn die Proxyparameter gesetzt sind.
• Man kann ein Set erstellen, welches die Video-URLs aus der MV-Filmliste z.B an wget übergibt, welches dann das Proxyhandling selbst vornimmt.

Mein Standardset sah bisher so aus:

Ich habe mir eine Kopie des Standardset als Basis für ein Download-set mit wget erzeugt.
Diese Set habe ich in der Liste nach oben geschoben.

und folgende wget Paramter gesetzt:

Meine Start-Konfiguration ist unverändert wie unter Punkt 3. “GUI-Proxy-Konfiguraion und Proxy-Aufrufparameter und Proxy-Environment Variablen”

Ergebnis:

• Abspielen über vlc funktioniert nach wie vor über den Proxy
• Download mittels neuem wget-Set versucht leider auch eine direkte Verbindung ins Internet aufzubauen und wird geblockt.

. Proxy Authentication from environment vars: (tv)
. MVHttpClient: Proxy configured from environment variables: (192.168.1.99)

. [Download starten, Programmset: Linux Speichern mit wget, Ziel: /dat/dload/mediathekview/ARTE_Concert_-_Pop/ARTE_Concert_-_Pop-ARTE_Concert_Festival-0755654601.mp4, URL: https://arteconcert-a.akamaihd.net/am/concert/079000/079400/079441-001-A_SQ_0_VA_03618009_MP4-2200_AMM-CONCERT-NEXT_wabHSRAUz.mp4, Startzeit: 13:17:14, direkter Download]
  [ ---------- ]   von 1563 MByte / Downloads: 1 / Bandbreite: 0 Byte/s

Fragen:

• Ist meine Zusammenfassung ok?
• Wie, bzw. mit welchem externen Programm wurde im bisherigen Standardset der Download versucht? ffmpeg, intern?
• Ist mein wget-set korrekt?
• Wenn ja, warum benutzt wget nicht die .wgetrc Konfiguration, wenn es mittes MV-set aufgerufen wird, oder wird wget garnicht herangezogen?

Zusatzfrage:

• Wofür steht %z bei den Zielparametern? Habe leider keine Info dazu in der Anleitung auf github gefunden

[styroll]

@bartull sagte: Wie, bzw. mit welchem externen Programm wurde im bisherigen Standardset der Download versucht? ffmpeg, intern?

Du musst nur mal das Speichern-Set anschauen, dann siehst du was Sache ist: http://….mp4 --> Direkt-Download; http://….m3u8 --> ffmpeg. Da siehst du auch, dass wget nicht von MV benutzt wird…

@bartull sagte: Wofür steht %z bei den Zielparametern? Habe leider keine Info dazu in der Anleitung auf github gefunden

Dort gibt’s ja auch keine Anleitung, du kannst via Hilfe-Menü in MV zur Anleitung kommen oder hier direkt. Da die Anleitung nicht mehr à jour ist, kannst du in den Einstellung auch auf den “Rettungsring”-Button /ganz unten rechts) drücken, um Hilfe zu kriegen.

@bartull sagte: Ist mein wget-set korrekt?

Eher nicht (“-i” bei wget?). Du kannst dich mal an meinem JDownloader-Set orientieren.

EDIT:
Du findest hier was zu einem wget-Set und weiter unten zum aria-Set.

[bartull]

@styroll
Besten Dank für deine Links, ich habe MV jetzt wieder ein bischen mehr verstanden!

Mein Set “Speichern mit wget” sieht jetzt so aus:

Der Download funktioniert jetzt auch über den Proxy!

. [Download starten, Programmset: Speichern mit wget, Ziel: /dat/dload/mediathekview/alpha-Campus/alpha-Campus-Zur_Person___Teil_1.mp4, URL: https://cdn-storage.br.de/MUJIuUOVBwQIbtC2uKJDM6OhuLnC_2rc5K1S/_AES/5yN6_yky/a1e5b5e9-f289-4768-b6bd-21d79a770aaa_X.mp4, Startzeit: 14:35:49, Programmaufruf: /usr/bin/wget https://cdn-storage.br.de/MUJIuUOVBwQIbtC2uKJDM6OhuLnC_2rc5K1S/_AES/5yN6_yky/a1e5b5e9-f289-4768-b6bd-21d79a770aaa_X.mp4 -O /dat/dload/mediathekview/alpha-Campus/alpha-Campus-Zur_Person___Teil_1.mp4, Programmaufruf[]: /usr/bin/wget<>https://cdn-storage.br.de/MUJIuUOVBwQIbtC2uKJDM6OhuLnC_2rc5K1S/_AES/5yN6_yky/a1e5b5e9-f289-4768-b6bd-21d79a770aaa_X.mp4<>-O<>/dat/dload/mediathekview/alpha-Campus/alpha-Campus-Zur_Person___Teil_1.mp4]
. =====================
. Starte Array: 
.  -> /usr/bin/wget<>https://cdn-storage.br.de/MUJIuUOVBwQIbtC2uKJDM6OhuLnC_2rc5K1S/_AES/5yN6_yky/a1e5b5e9-f289-4768-b6bd-21d79a770aaa_X.mp4<>-O<>/dat/dload/mediathekview/alpha-Campus/alpha-Campus-Zur_Person___Teil_1.mp4
. =====================
. [Download ist fertig und hat geklappt, Programm ist ein Downloadmanager, Programmset: Speichern mit wget, Ziel: /dat/dload/mediathekview/alpha-Campus/alpha-Campus-Zur_Person___Teil_1.mp4, Startzeit: 14:35:49, Endzeit: 14:35:49, Restarts: 0, Dauer: 0 s, Dauer: <1 Min., URL: https://cdn-storage.br.de/MUJIuUOVBwQIbtC2uKJDM6OhuLnC_2rc5K1S/_AES/5yN6_yky/a1e5b5e9-f289-4768-b6bd-21d79a770aaa_X.mp4, Programmaufruf: /usr/bin/wget https://cdn-storage.br.de/MUJIuUOVBwQIbtC2uKJDM6OhuLnC_2rc5K1S/_AES/5yN6_yky/a1e5b5e9-f289-4768-b6bd-21d79a770aaa_X.mp4 -O /dat/dload/mediathekview/alpha-Campus/alpha-Campus-Zur_Person___Teil_1.mp4, Programmaufruf[]: /usr/bin/wget<>https://cdn-storage.br.de/MUJIuUOVBwQIbtC2uKJDM6OhuLnC_2rc5K1S/_AES/5yN6_yky/a1e5b5e9-f289-4768-b6bd-21d79a770aaa_X.mp4<>-O<>/dat/dload/mediathekview/alpha-Campus/alpha-Campus-Zur_Person___Teil_1.mp4]
  >> ERRORSTREAM [2]: --2018-11-23 14:35:49--  https://cdn-storage.br.de/MUJIuUOVBwQIbtC2uKJDM6OhuLnC_2rc5K1S/_AES/5yN6_yky/a1e5b5e9-f289-4768-b6bd-21d79a770aaa_X.mp4
  >> ERRORSTREAM [2]: Verbindungsaufbau zu 192.168.1.99:8080 … verbunden.
  >> ERRORSTREAM [2]: Proxy-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
  >> ERRORSTREAM [2]: Länge: 19243495 (18M) [video/mp4]
  >> ERRORSTREAM [2]: Wird in »»/dat/dload/mediathekview/alpha-Campus/alpha-Campus-Zur_Person___Teil_1.mp4«« gespeichert.
  >> ERRORSTREAM [2]: 
  >> ERRORSTREAM [2]:      0K .......... .......... .......... .......... ..........  0% 1,29M 14s
  >> ERRORSTREAM [2]:     50K .......... .......... .......... .......... ..........  0% 1,20M 15s
  >> ERRORSTREAM [2]:    100K .......... .......... .......... .......... ..........  0% 1,57M 14s
  >> ERRORSTREAM [2]:    150K .......... .......... .......... .......... ..........  1%  708K 17s
 ...
  >> ERRORSTREAM [2]:  18750K .......... .......... .......... .......... ..        100% 1,44M=14s
  >> ERRORSTREAM [2]: 
  >> ERRORSTREAM [2]: 2018-11-23 14:36:03 (1,34 MB/s) - »»/dat/dload/mediathekview/alpha-Campus/alpha-Campus-Zur_Person___Teil_1.mp4«« gespeichert [19243495/19243495]
  >> ERRORSTREAM [2]: 

Die Ausgabe ERRORSTREAM [2]: verwirrt allerdings, da der Download offensichtlich in Ordnung ist.
Oder gibt es noch einen Fehleinstellung, die ich übersehen habe?

[styroll]

@bartull sagte: Die Ausgabe ERRORSTREAM [2]: verwirrt allerdings

Die Bezeichnung ist etwas unglücklich, da können Fehler ausgegeben werden, ansonsten ist es der normale Output, was das Programm gerade macht. Also alles im Lot.

[Rolf2017]

@bartull sagte in Proxy Authentication - Problem mit MediathekView:

Zusatzfrage:

• Wofür steht %z bei den Zielparametern?

Ohne Gewähr

%Z Hashwert der URL, z.B.: 1433245578

%z Hashwert der URL + Suffix, entspricht also: %Z.%S, z.B.: 1433245578.mp4

[gerdd]

@styroll @bartull fwiw: wenn ich mich recht erinnere, schreibt wget seine Meldungen auf stderr, denn stdout kann man für die Downloaddaten verwenden (per Pipe auf eine Zieldatei schieben.)