-
Seit der Version vom 26.09. gibt es unter Ubuntu 18.04.3 ein Problem mit dem Debian-Paket MediathekView-13.5.0-linux-2019-09-26.deb
Diese Version lässt sich problemlos installieren per apt, aber nicht starten.
Fehlermeldung:
Exception in thread "main" java.lang.ExceptionInInitializerError at mediathek.tool.notification.NotificationFactory.createNotificationCenter(NotificationFactory.java:24) at mediathek.config.Daten.setupNotifications(Daten.java:245) at mediathek.config.Daten.<init>(Daten.java:106) at mediathek.config.Daten.getInstance(Daten.java:147) at mediathek.Main.setupPortableMode(Main.java:147) at mediathek.Main.main(Main.java:255) Caused by: java.lang.NullPointerException at mediathek.tool.ApplicationConfiguration.getConfiguration(ApplicationConfiguration.java:113) at mediathek.tool.notification.NotificationFactory.createNotificationCenter(NotificationFactory.java:24) at mediathek.config.Daten.setupNotifications(Daten.java:245) at mediathek.config.Daten.<init>(Daten.java:106) at mediathek.config.Daten.getInstance(Daten.java:147) at mediathek.tool.ApplicationConfiguration$TimerTaskListener.onEvent(ApplicationConfiguration.java:204) at mediathek.tool.ApplicationConfiguration$TimerTaskListener.onEvent(ApplicationConfiguration.java:190) at org.apache.commons.configuration2.event.EventListenerList.callListener(EventListenerList.java:298) at org.apache.commons.configuration2.event.EventListenerList.access$200(EventListenerList.java:55) at org.apache.commons.configuration2.event.EventListenerList$EventListenerIterator.invokeNextListenerUnchecked(EventListenerList.java:422) at org.apache.commons.configuration2.event.EventListenerList$EventListenerIterator.invokeNext(EventListenerList.java:362) at org.apache.commons.configuration2.event.BaseEventSource.fireEvent(BaseEventSource.java:234) at org.apache.commons.configuration2.AbstractConfiguration.setProperty(AbstractConfiguration.java:790) at mediathek.tool.ApplicationConfiguration.createDefaultConfigSettings(ApplicationConfiguration.java:151) at mediathek.tool.ApplicationConfiguration.loadOrCreateConfiguration(ApplicationConfiguration.java:138) at mediathek.tool.ApplicationConfiguration.<init>(ApplicationConfiguration.java:105) at mediathek.tool.ApplicationConfiguration.<clinit>(ApplicationConfiguration.java:93) ... 6 moreNun habe ich heraus gefunden, dass die Version vom 24.09. funktioniert und weiter getestet.
Mir ist dann aufgefallen, dass die Versionen vom 26.09. und 27.09. nur dann funktionieren, wenn ich zuerst die ältere funktionierende Version vom 24.09. installiert habe und dann die neue Version drüber installiere.
Nach meinen Tests liegt es an dem Ordner .mediathek3 im Homeverzeichnis. Existiert der Ordner samt Inhalt aus einer funktionierenden Installation z.B. vom 24. 09. , dann lassen sich auch die nachfolgenden Versionen problemlos starten, existiert der Ordner .mediathek3 nicht oder ist leer, dann starten die Versionen vom 26. und 27.09. nicht mit obiger Fehlermeldung. -
@Ubunux ich hatte neulich auch ein Problem mit einem nightly Build und ich glaube, Probleme zu nighlies sind am besten in der Forumskategorie für nightly builds aufgehoben…
ggfs. Beitrag CUT & Paste ins andere Forum?
-
@rubikon
dann habe ich diesen Satz falsch verstanden:@Nicklas2751 sagte in [Aufruf] MV Installer:
Meine Bitte an euch: Bitte testet die entsprechenden Installer & Archive bei euch und gebt mir hier konstruktives feedback.
-
@Ubunux sagte in [Aufruf] MV Installer:
@rubikon
dann habe ich diesen Satz falsch verstanden:Ich möchte Deine Frage konstruktiv beantworten, indem ich ihr völlig ausweiche:
ich habe mir den aktuellen Code gezogen (develop) und das Verzeichnis
.mediathek3
in meinem (Windowsnutzer-) Profil umbenannt.Wenn ich nun selbst compiliertes MV (develop) aus eclipse heraus starte, erhalte ich dieselbe Fehlermeldung.
D.h. die o.g. Fehlermeldung kommt auch- unter Windows und auch
- wenn man MV nicht mittels Installer, sondern z.B. über git und Java-Compiler auf den Rechner bringt.
-
@rubikon ok schaue ich mir an
-
@DerReisende77
… :winking_face: -
@rubikon fix ist in develop. Kannst Du das mal bitte testen?
-
@DerReisende77 aber sicher. Hab’s gezogen. Hab’s gestartet. Ist jetzt ne ziemlich technische Geschichte
–> Ich hoffe die Nachricht als Chat im MV Forum ist lesbar für Dich? -
@DerReisende77 ich hab mir das
Problem von ApplicationConfiguration mal angeschaut.
Ein möglicher Ansatzpunkt um es zu durchbrechen ist, wenn ApplicationConfiguration eine bzgl. ourInstance null-safe Funktion hätte, um getBoolean Parameter abzurufen (den als Parameter übergebenen default Wert zu holen.)Das wird an zwei Stellen gebraucht.
NotificationFactory.createNotificationCenter und
MVSenderIconCache KonstruktorDas hab ich mal als pull request geschickt.
Es gibt vermutlich andere, elegantere Methoden für das bootstrapping… Ich kenn mich in der Welt dieser Bibliotheken exakt null aus. Das hier ist also nur ein Vorschlag von jemand ohne Kenntnis der Materie. -
jetzt dann doch hier weiter?!
dann => feedback zu den win-Versionen 24 + 27-09 (jeweils die .zip):
(1) 13.5.0_24-09, portable mit Fehler wie vor, also der Version vom 12-09 vgl. vorige Seite, beide anderen win-exe ok, kein Problem aufgefallen. Ob mit vorhandenem User-Vz oder alles neu, egal, funktioniert.
(2) anders die 13.5.0 vom 27-09, alle drei .exe machen Probleme bei ‘nacktem’ Start, also ohne jeden Nutzerordner. error.log
_
nimmt man nun statt blank ein bestehendes user-Vz entsprechend mit hinzu (‘.mediathek3’), dann starten alle 3 .exe fehlerfrei. Für DL orf muss nur die ffmpeg.exe in \bin ausgetauscht werden. -
@nayrun
@Nicklas2751 und auch ich haben gestern die Ursache für das Problem beim “nackten Start” identifiziert und eine Behebung des Fehlers von Nicklas ist in den aktuellen develop-Code eingeflossen. Inzwischen ist das als nightly Build verfügbar.Ich habe auf meinem Windows10 19.03 Laptop dieses nightly installiert und konnte erfolgreich einen “nackten” Start durchführen. Auf meinem Desktop dasselbe für mein “selbst gebautes” MV, gestartet aus der Entwicklungsumgebung.
Aus meiner Sicht ist die verwendete Fehlerbehebung der Art, dass sie nicht nur das Problem einer Windows Installation behebt, sondern sollte plattformübergreifend funktionieren.
Danke @Nicklas2751 für den Tipp mit Future<?> :thumbs_up_medium-light_skin_tone:
Um mich selbst an eine asynchrone Lösung dieses Problems zu wagen hab ich mich nicht ausreichend in den Code eingelesen. -
Aus meiner Sicht ist die verwendete Fehlerbehebung der Art, dass sie nicht nur das Problem einer Windows Installation behebt, sondern sollte plattformübergreifend funktionieren.
Danke für das verschieben und Danke für die prompte Fehlerbehebung!
Ich kann bestätigen, dass es nun auch unter Ubuntu 18.04.3 wieder funktioniert.
-
@rubikon
…Ursache für das Problem beim “nackten Start” identifiziert und eine Behebung des Fehlers von Nicklas ist in den aktuellen develop-Code eingeflossen. Inzwischen ist das als nightly Build verfügbar.
die win-Version (28-Sep-2019) probiert, auf win8.1-64 - e voila: alles tutti.
funktionuckelt. Supi, & besten dank.
portable und normale .exe (Einstellungsordner dann im BenutzerVz \Users…mediathek3) probiert, “nackt”, beides funktioniert.
Das einzige, was noch auffällt, mit der enthaltenen ffmpeg 28.09.2019 Größe 100.196.414 funktioniert der DL-Orf nicht. Erst ein Austausch gg zB. die frühere Version 4.1.3_x32 behebt das. Auch die aktuelle Version 4.2.1 (ffmpeg-20190927-0485865-win32-static) funktioniert. Wobei mir nicht ganz klar ist, ob die x32 oder die x64 ffmpeg genommen werden sollte(?!).
Zum Schluss, zur Orientierung wäre es vlt nicht verkehrt, die DL-Adresse (download.mediathekview.de/unstabil/) zu den nightlies oben zu erwähnen - weil die ja anscheinend jetzt hier behandelt werden? -
@nayrun sagte in Exception bei aktueller nightly ohne bestehenden Config Ordner:
Das einzige, was noch auffällt, mit der enthaltenen ffmpeg[…]
Danke. Das betrifft nach meinem Empfinden weniger “Fehler bei nicht vorhandener settings.xml” und passt vielleicht ganz gut nach ffmpeg.exe defekt.
Ich bin weder MV-Entwickler noch Forumsmoderator und bitte einfach noch um ein wenig Geduld, bis etwas entsprechend Änderung (commit abb9260f2276bed8349933dba4ed1c0124117170 von Nicklas) aus dem master-branch in den develop-branch und damit in die nightlies integriert wird.
-
Wurde heute Morgen bereits getan. Der aktuelle nightly (von heute Morgen) ist bereits korrekt und enthält FFmpeg wieder ohne Fehler.
