Abbruch mit Fehlermeldung <<Tag mismatch!>>

[Lichtfaenger]

@styroll

Hallo und Guten Abend ‘Styroll’,

vielen Dank für die zeitnahe Antwort in der Angelegenheit.

Das mit dem Tipp für die Web-Applikation habe ich dann in der Tat ‘überlesen’.

Mea culpa, mea maxima culpa!

Gleichwohl möchte ich nicht schreiben, dass es mich freut, dass 4 weitere User (Schnittmenge!) hier ebenfalls das Problem haben.

Ich habe lediglich gehofft, dass es nunmehr in der Zwischenzeit eine Lösung für die Problematik gibt.

Um ehrlich zu sein: ich habe das Problem schon seit ca. 4-5, 6 Monaten aber nunmehr habe ich den Entschluss gefasst, dies in dem entsprechenden Forum zu kommunizieren.

Vorab Dank für den Hinweis zu Mediathekview-Web.

Grüße und schönen 2. Advent!

Lichtfaenger

[mac-christian]

@lichtfaenger sagte in Abbruch mit Fehlermeldung <<Tag mismatch!>>:

Ich verwende die aktuelle Version von Mediathekview v13.6.0 unter
Windows 10 x64 H2 Build #19042.662
Java 8 v271 (64bit)

Ich dachte, MV 13.6 verlangt Java 14, und eine solche Version werde mitgeliefert, wenn man den Installer fürs jeweilige System runterlädt?

Disclaimer: Ich habe keine Ahnung, aber davon eine ganze Menge!

[Nicklas2751]

@mac-christian Das ist auch so. Es kann natürlich ein anderes Java installiert sein. MV ignoriert das und nutzt sein eigenes.

[Lichtfaenger]

@mac-christian

Hallo ‘mac-christian’,

vielen Dank für Deine Rückmeldung!

Um ehrlich zu sein, war ich (Laie) durch und durch, auch der Meinung, dass mit der Installation von MediathekView alle entsprechenden ‘Bibliotheken’ etc. entsprechend installiert werden und es keinen weiterem Download benötigt.

Allerdings hatte ich in dem thematisierten einen ‘technischen’ Beitrag gelesen, dass zwar Java 14 erforderlich ist, aber habe (Laie) - man möge es mir nachsehen - hier dann (nachdem ich kein JAVA in meinem W10 x64) entdecken konnte, installiert. Grund war hier, dass ich in früheren niemals das Problem hatte, dass ein Download abgebrochen wurde. Nie. Das gab es einfach nicht. Ich habe sogar 2 oder 3 DL gleichzeitig gestartet und gut war. Bei einer Anbindung von 100 MBit ist das jetzt auch nicht sooo das ‘Ding’.

Aber zurück zu JAVA. Die nachträgliche Installation hat keine Besserung der bisherigen Thematik gebracht.

Freundliche Grüße aus der Saar-Pfalz-Region und ebenfalls einen
schönen 2. Advent für Dich und die Menschen, die Dir etwas bedeuten!

Grüße,
Lichtfaenger

[styroll]

@lichtfaenger sagte: Ich habe lediglich gehofft, dass es nunmehr in der Zwischenzeit eine Lösung für die Problematik gibt.

Falls das Problem mit Java selbst zu tun hat, dann bringt vielleicht die NIghtly-Version Abhilfe, da diese eine neuere Java-Version (Java 15) verwendet.

[Lichtfaenger]

@styroll
Die Thematik besteht auch mit der aktuellen Version 13.7.1 immer noch.
Von daher gehe ich nicht davon aus, dass das ein JAVA-Problem ist.

Welche JAVA-Version wird denn in der 13.7.1 verwendet? Innerhalb der Applikation kann ich diese Information leider nicht ersehen.

[alex]

@Lichtfaenger

openjdk version "15.0.1" 2020-10-20
OpenJDK Runtime Environment AdoptOpenJDK (build 15.0.1+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 15.0.1+9, mixed mode)

[DerReisende77]

@lichtfaenger sagte in Abbruch mit Fehlermeldung <<Tag mismatch!>>:

@styroll
Die Thematik besteht auch mit der aktuellen Version 13.7.1 immer noch.
Von daher gehe ich nicht davon aus, dass das ein JAVA-Problem ist.

Darauf würde ich mein Geld nicht setzen: Zum Beispiel dieser SSL-Fehler wird erst mit Java 17 behoben, er existert seit Java 13

Es gibt andere Projekte die auch mit demselben Fehler kämpfen. Es scheint wohl daran zu liegen das der HTTPS-Server Fähigkeiten meldet, die er nicht richtig beherrscht.
Grundsätzlich ist es schwierig bis unmöglich, Fehler die nicht bei mir nachvollziehbar sind zu debuggen und eine Lösung zu finden - meine hellseherischen Fähigkeiten sind leider zu unterentwickelt, ansonsten würde ich damit richtig viel Geld verdienen

Ich habe ab dem nächsten Nightly nach heute 19:17 MediathekView so umgeändert dass er auch “unsicherere” HTTPS-Verbindungen anbietet und akzeptiert. Ob das irgendeinen Erfolg hat kann ich nicht sagen. Von daher solltest Du den nächsten nightly danach mal testen ob die Probleme damit bei Dir beseitigt sind. Wenn nicht: keine Ahnung :man_shrugging_light_skin_tone:

[gerdd]

Mal “ins Unreine” gedacht:

“Tag Mismatch” - das klingt sehr nach einer kaputten XML-Datei. Muss nicht sein, wäre aber einleuchtend. In MV gibt es, glaube ich, nur die mediathek.xml. Die benutzt aber jeder, die ganze Zeit. Wenn es da einen Systemfehler gäbe, hätten ihn nicht nur vier Anwender. Natürlich könnte es sein, dass die vier manuell in der Datei herumeditiert haben und dabei etwas gründlich verbogen haben. Das wäre aber nicht meine Lieblingshypothese …

Auf der anderen Seite - sind nicht etliche der Dateien, die man so von den Mediathek-Servern herunterlädt im XML-Format? Wenn da hin und wieder mal eine “verbogen” wäre, die zu einem Beitrag gehört, den nur wenige Anwender auswählen, dann hätte man eine Erklärung dafür, dass nur wenige Benutzer das Problem haben und dass es wohl nicht um einen Fehler im MV-Code geht.

Ein guter test könnte sein, einen derart fehlschlagenden Download über ein Alternativtool zu versuchen - meine erste Wahl hierfür wäre youtube-dl, weil es sich recht ausführlich zu seiner Vorgehensweise und eventuellen Fehlern äussern kann. (Ich wäre nicht überrascht, wenn im Log von MV ähnlich viel Information angesammelt würde, aber das findet der Laie eher nicht so schnell.)

Vorschlag daher: Wenn mal wieder ein konkreter Beitrag mit der Fehlermeldung scheitert, die genauen Daten hier ablegen. Und dann den Beckenbauer: “Schaun’mer mal, dann seh’n mer schon.”

Mit einer Fehlerbehebung in MV rechne ich aber eher nicht, da der Fehler vermutlich irgendwo bei einem Sender liegen dürfte.

(Bleibt noch die Frage an die Entwickler: Die fragliche XML-Datei müsste nach meiner Theorie ja vom Client bearbeitet werden, nicht von einem Crawler. Gibt es so etwas überhaupt?)

[MenchenSued]

@derreisende77 sagte in Abbruch mit Fehlermeldung <<Tag mismatch!>>:

Ich habe ab dem nächsten Nightly nach heute 19:17 MediathekView

Nur noch mal der Hinweis, dass es derzeit keine Nightlies mehr gibt. Siehe hier.

[DerReisende77]

@gerdd Der Aufbau und das Aushandeln einer verschlüsselten HTTPS-Verbindung hat überhaupt nichts mit XML und MediathekView zu tun.

@MenchenSued Ja, ist mir danach auch wieder bewusst geworden und ich habe @alex animiert, sich darum zu kümmern.

[gerdd]

@derreisende77

Pardon, aber ich habe mich auhc nicht auf deinen SSL-Fehler bezogen, sondern auf den “Tag Mismatch” des O.P. Und Tags finde ich eher in XML als in SSL …

[DerReisende77]

@gerdd Der OP bezieht sich auf Download-Probleme und es wird in diesem Thread auf diesen Thread verwiesen. Und dort ist sogar die Exception zum Thema Tag mismatch beim Download abgebildet:

javax.net.ssl.SSLException: Tag mismatch!
at sun.security.ssl.Alert.createSSLException(Alert.java:133) ~[?:?]
at sun.security.ssl.TransportContext.fatal(TransportContext.java:320) ~[?:?]
at sun.security.ssl.TransportContext.fatal(TransportContext.java:263) ~[?:?]
at sun.security.ssl.TransportContext.fatal(TransportContext.java:258) ~[?:?]
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:129) ~[?:?]
at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1183) ~[?:?]
at sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1153) ~[?:?]
at sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:828) ~[?:?]
at okio.InputStreamSource.read(Okio.kt:102) ~[MediathekView.jar:?]
at okio.AsyncTimeout$source$1.read(AsyncTimeout.kt:159) ~[MediathekView.jar:?]
at okio.RealBufferedSource.read(RealBufferedSource.kt:41) ~[MediathekView.jar:?]
at okhttp3.internal.http1.Http1ExchangeCodec$AbstractSource.read(Http1ExchangeCodec.kt:352) ~[MediathekView.jar:?]
at okhttp3.internal.http1.Http1ExchangeCodec$FixedLengthSource.read(Http1ExchangeCodec.kt:389) ~[MediathekView.jar:?]
at okhttp3.internal.connection.Exchange$ResponseBodySource.read(Exchange.kt:279) ~[MediathekView.jar:?]
at okio.RealBufferedSource$inputStream$1.read(RealBufferedSource.kt:438) ~[MediathekView.jar:?]
at java.io.InputStream.read(InputStream.java:213) ~[?:?]
at mediathek.controller.ThrottlingInputStream.read(ThrottlingInputStream.java:31) ~[MediathekView.jar:?]
at mediathek.controller.MVBandwidthCountingInputStream.read(MVBandwidthCountingInputStream.java:45) ~[MediathekView.jar:?]
at mediathek.controller.starter.DirectHttpDownload.downloadContent(DirectHttpDownload.java:191) ~[MediathekView.jar:?]
at mediathek.controller.starter.DirectHttpDownload.run(DirectHttpDownload.java:299) [MediathekView.jar:?]
Caused by: javax.crypto.AEADBadTagException: Tag mismatch!
at com.sun.crypto.provider.GaloisCounterMode.decryptFinal(GaloisCounterMode.java:623) ~[?:?]
at com.sun.crypto.provider.CipherCore.finalNoPadding(CipherCore.java:1116) ~[?:?]
at com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1053) ~[?:?]
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:941) ~[?:?]
at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:491) ~[?:?]
at javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:779) ~[?:?]
at javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730) ~[?:?]
at javax.crypto.Cipher.doFinal(Cipher.java:2503) ~[?:?]
at sun.security.ssl.SSLCipher$T12GcmReadCipherGenerator$GcmReadCipher.decrypt(SSLCipher.java:1639) ~[?:?]
at sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecord.java:262) ~[?:?]
at sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:190) ~[?:?]
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) ~[?:?]
… 15 more

Was man hier ganz leicht erkennen kann sind die Schlagworte SSL, Crypto, javax.crypto.AEADBadTagException mit “Tag mismatch”.
Es hat immer noch nix mit XML, Mediathekview-Dateien etc zu tun. Und Tags findet man auch an ganz vielen anderen Stellen.