Mediathekview 13.5.0 hängt nach Start bis Filme, reagiert nicht auf Maus

[Franz47]

Windows 10 64 bit mit 24 GB RAM
MV 13.5.0
Openjdk version 13 2019-09-17
Openjdk Runtime Environment Adoptopenjdk (build 13+33)
Openjdk 64-bit server VM Adoptopenjdk (build 13+33, mixed mode, sharing)

Seit gestern(?): MV startet, heutige Filmliste ca 2 Stunden alt, ist angegeben, Aboseintragen wird angezeigt, danach Filme-Liste sichtbar, 31 Downloads, 0 gestartet, es passiert nichts mehr. Mausaktionen ohne Reaktion. Auch Schließen des Fensters über Klicken auf Kreuz rechts oben nicht mehr möglich. Einzige erfolgreiche Methode ist, über den Task-Manager zu killen. Mediathekview.exe belegt laut Eintrag im Task-Manager dabei ca. 45% der CPU-Leistung, 1100 MB, und hat „hohen Stromverbrauch“. ? Das dauert an, wenn man das nicht killt.

Doch jetzt – nach ewig langer Zeit ist der Reiter Download und Inhalt sichtbar – Gesamtdownloads 31, 23 Abos, 8 Downloads, davon 31 fehlerhaft. An den Werten im Task-Manager hat sich aber nichts geändert.

Habe einmal .mediathek3 umbenannt, danach startet MV, macht ein neues .mediathek3-Verzeichnis und kann auch geschlossen werden, allerdings fehlen da natürlich alle Abos und sonstigen Einträge.
Habe wieder die alte .mediathek3 Version in Verwendung genommen, damit hängt wieder alles. Neuinstallation von heutigem Download ändert auch nichts.

Ich kann meiner Meinung nach dadurch auch kein LOG-file erstellen lassen.

Was kann ich tun, das zum Laufen zu bringen, ohne die Einstellungen zu verlieren?
Ich habe tägliche Backups seit 31.12.2019, kann also auch Dateiversionen früherer Tage dort bei Bedarf rausholen.

[Ein ehemaliger Benutzer]

@Franz47 sagte in Mediathekview 13.5.0 hängt nach Start bis Filme, reagiert nicht auf Maus:

Openjdk version 13 2019-09-17
Openjdk Runtime Environment Adoptopenjdk (build 13+33)
Openjdk 64-bit server VM Adoptopenjdk (build 13+33, mixed mode, sharing)

Hast Du Maßnahmen ergriffen, um MV 13.5 ausdrücklich mit dieser Java Version zu starten? Ansonsten wird bei Verwendung des Startprogramms mediathekview.exe das mitgelieferte AdoptOpenJDK 11u4 verwendet. - Aufschluß gibt das LOG-file .mediathek3\mediathekview.log. Bei mir:

INFO  2020-01-04 14:32:33,217  [main] mediathek.Main (Main.java:156) - Portable Mode: false
DEBUG 2020-01-04 14:32:33,542  [main] mediathek.Main (Main.java:234) - === Java Information ===
INFO  2020-01-04 14:32:33,545  [main] mediathek.Main (Main.java:235) - Programmstart: 04.01.2020 14:32:33
INFO  2020-01-04 14:32:33,548  [main] mediathek.Main (Main.java:237) - Version: 13.5.1
DEBUG 2020-01-04 14:32:33,549  [main] mediathek.Main (Main.java:240) - maxMemory: 4068 MB
DEBUG 2020-01-04 14:32:33,549  [main] mediathek.Main (Main.java:242) - Java:
DEBUG 2020-01-04 14:32:33,549  [main] mediathek.Main (Main.java:245) - Vendor: AdoptOpenJDK
DEBUG 2020-01-04 14:32:33,550  [main] mediathek.Main (Main.java:245) - VMname: OpenJDK 64-Bit Server VM
DEBUG 2020-01-04 14:32:33,550  [main] mediathek.Main (Main.java:245) - Version: 11.0.4
DEBUG 2020-01-04 14:32:33,550  [main] mediathek.Main (Main.java:245) - Runtimeversion: 11.0.4+11

Ich kann meiner Meinung nach dadurch auch kein LOG-file erstellen lassen.

Benenne die Datei .mediathek3\mediathekview.log um nach .mediathek3\mediathekview.txt - diese Datei kannst Du hier hochladen (das Forum erlaubt Dateiendung.log nicht…)

Was kann ich tun, das zum Laufen zu bringen, ohne die Einstellungen zu verlieren?

Deine Programmsets, Abos etc. stehen in der Datei .mediathek3\mediathek.xml und werden zusätzlich zu Deinen persönlichen Sicherungsmaßnahmen automatisch rollierend gesichert nach .mediathek3\mediathek_copy[12345].xml

Du kannst mal versuchen, ob durch entsprechende Umbenennungen

• aktueller Datei .mediathek3\mediathek.xml -> .mediathek3\mediathek_problem.xml und
• .mediathek3\mediathek_copy[12345].xml nach .mediathek3\mediathek.xml

MV für Dich wieder besser funktioniert. Wenn es seit gestern (?) aufritt, versuch es zuerst mit der Kopie von vorgestern (?)

Mediathekview.exe belegt laut Eintrag im Task-Manager dabei ca. 45% der CPU-Leistung, 1100 MB

Belegung von ~1 GB RAM ist bei MV 13.5. ganz normal. Es hält bei Rechnern mit genug verfügbarem Arbeitsspeicher die Filmliste mit ~320k Einträgen im Hauptspeicher, nicht in einer Datenbank. Dadurch kann es viel schneller arbeiten.

[styroll]

@Franz47 sagte: Habe einmal .mediathek3 umbenannt, danach startet MV, macht ein neues .mediathek3-Verzeichnis und kann auch geschlossen werden, allerdings fehlen da natürlich alle Abos und sonstigen Einträge. […]
Was kann ich tun, das zum Laufen zu bringen, ohne die Einstellungen zu verlieren?

Wenn der Vorschlag von @rubikon nicht geholfen hat, kannst du – wie von dir beschrieben – mit neuen Einstellungen starten und dann via “Datei/Importieren” die Aboeinstellungen (und andere Einstellungen) aus der Datei mediathek.xml (aus einem Backup) importieren. Die 3 unten markierten Dateien kannst du davor (wenn sie dir auch wichtig sind) – MV muss beendet sein – aus einem Backup kopieren (diese Dateien sollten nicht korrumpiert worden sein):

@rubikon sagte: Hast Du Maßnahmen ergriffen, um MV 13.5 ausdrücklich mit dieser Java Version zu starten?

Kaum, denn eigentlich weiss der OP (von dir), dass es keine eigene Java-Installation braucht. Die Leute geben die Java-Version wohl an, da das erstens in früheren Versionen relevant war und die Maske zum Melden von Problemen nicht angepasst wurde…

[Booker23de]

@Franz47 Ich hatte ähnliche Probleme mit 13.5.0 unter Win10 64bit. Ich fand in einem andern Thread den Tipp die damals neuste Nightly, MediathekView-13.5.1-win-2019-12-28, zu testen.
Es hat mir geholfen. Es dauert zwar immer noch länger als früher bis MV komplett gestartet ist. Das laden der Filmliste und das verarbeiten der Abos sowie der Blacklist dauern etwas länger. Aber dann funktioniert als wie gewohnt.

[Franz47]

Vielen Dank einmal an alle, die sich die Mühe genommen und geantwortet haben!

Ich war nicht sicher, ab wann alles nicht mehr normal funktionierte, ich wußte auch nicht, ab wann z.B. die 3 zu kopierenden Dateien sicher intakt sind, da ich die Videos an einer anderen Stelle im Heimnetz streame und Mediathekview auf dem PC dauernd im Hintergrund meist ohne ein Zutun läuft. Allerdings mußte ich irgendwann (??) in letzter Zeit den PC aus dem Lauf abwürgen, da er eingefroren war. Vielleicht ist dabei Mediathekview zu Schaden gekommen.

Ich habe daher einfach die Verzeichnisse .mediathek3 aus verschiedenen Tagen in den Backups ausprobiert, die Version vom 3.1. 2020 hat funktioniert, danach habe ich sicher an den Abos nichts geändert. Das Eintragen der Blacklist dauert zwar auch überraschend lange, aber vielleicht ist mir das früher nie aufgefallen.

Jedenfalls bin ich wieder einmal froh, daß ich täglich automatisch Backups machen lasse. Hat mich schon einige Male gerettet.

[Ein ehemaliger Benutzer]

@styroll sagte in Mediathekview 13.5.0 hängt nach Start bis Filme, reagiert nicht auf Maus:

Kaum, denn eigentlich weiss der OP (von dir), dass es keine eigene Java-Installation braucht.

Oi! Das hatte ich erfolgreich verdrängt, dass ich es ihm ebd. erklärt hatte.

Die Leute geben die Java-Version wohl an, da das erstens in früheren Versionen relevant war und die Maske zum Melden von Problemen nicht angepasst wurde…

Es ist meiner Meinung nach nach wie vor relevant und mir wäre lieber, es bleibt in der Maske bis auf Weiteres noch so.

MV 13.5 ist nicht 100% fix auf AdoptOpenJDK 11u4. z.B. kannte ich bis vor ein paar Tagen den Trick nicht, dass man im Anwendungsverzeichnis in .install4j/pref_jre.cfg auch mit den neuen Anwendungsstartern aus install4j selbst einstellen kann, welches JRE man verwenden möchte. Das mitgelieferte oder eben ein anderes. Zulu, Oracle, wasauchimmer. - Ist aber eher ein exotischer Fall und wohl nicht mehr täglich Brot. Ich vermisse diese alte Zeit auch nicht (Ich habe die Einfühung von 13.3 im Forum gesehen… JRE, JDK ohne FX, Java 8 und was da alles schief ging.).

Die Angabe “Java 13” hätte ich dem OP erst mit Verweis auf die config-Datei oder mit einem log-File geglaubt - und es bis dahin zumindest nicht völlig ausgeschlossen.

In der Maske zum Melden von Problemen steht die Bitte, die Java-Version mit anzugeben meiner Meinung nach aber auch heute noch (im “Zeitalter des Installers”:thumbs_up_light_skin_tone: :thumbs_up_light_skin_tone: :thumbs_up_light_skin_tone: ) vollkommen zurecht. Denn bei der -für einige Betriebssysteme wie Win 32 Bit und für JavaFX-Allergiker- empfohlenen Version 13.0.6 muss sehr wohl in vielen Fällen der Nutzer selbst sich um die Installation von Java kümmern. Das derzeit letzte Ticket aus der Ecke MV 13.0.6 ist noch keine 2 Wochen zurück… - ich find es daher durchaus noch aktuell, danach bereits im Template zu fragen.

edit: 1x muss zu viel weg

[styroll]

@rubikon sagte: Es ist meiner Meinung nach nach wie vor relevant und mir wäre lieber, es bleibt in der Maske bis auf Weiteres noch so.

Du siehst ja selbst, was passiert, wenn man sich an die Anleitung hält: User geben genau das an, was eben “java -version” liefert; in der Mehrheit der Fälle also eine Angabe, die sich nicht auf die mit MV verwendete Java-Version bezieht. Das ist dann eine völlig irreführende Information, die genau zu weiteren Nachfragen (wie von dir) statt zum Ausschluss von gewissen Fehlerquellen führt.

Und es versteht sich von selbst, dass man die Java-Version angeben muss, wenn man eine eigene verwendet (das trifft auch auch bei der Verwendung der MV-Version 13.0.6 zu, welche zumindest unter Linux und Windows kein Java gebundelt hatte). Java musste man sich dafür ja auch mal selbst installieren/einrichten.

Die Angabe zur Java-Version macht auch bei der Anleitung zum Melden von fehlenden Sendungen keinen Sinn, denn wenn man eine Filmliste laden und Sendungen suchen (aber nicht finden) konnte, ist mit MV und Java alles okay…

[Ein ehemaliger Benutzer]

@styroll Also beim Melden von fehlenden Sendungen bin ich ganz bei Dir: da ergeben auch für mich Angaben zur Java-Version keinen Sinn.

Ich sehe es auch ebenfalls so, dass das Ausführen von java -jar inzwischen, also mit den neuen Startern, keine brauchbare Information mehr liefert.

Leider weiß ich grad keine pauschal gültige Methode zum ermitteln der von MV verwendeten Java Version.

MV 13.0.6 und MV 13.2.1 schreiben es in die Shell bzw. zeigen es in Hilfe -> Über dieses Programm an … und MV 13.3+ dann nur noch im log-File.

Jedenfalls besteht in der genannten Anleitung zum Ermitteln der von MV verwendeten java Version auch mE Verbesserungspotential.