Darstellungsfehler und Ausnahmen unter Raspbian auf Raspberry Pi 4

[beta-tester]

hallo,

ich habe einen Raspberry Pi 4 mit 4GB auf dem ich Raspbian Buster installiert habe
(aktuellste version und immer auf dem neusten stand gebracht).

wenn ich dort MediathekView starte, wird die bedienoberfläche von MV zum teil unvollständig/fehlerhaft dargestellt
(MV in aktueller release und auch die latest nightly).

Hardware: Raspberry Pi 4 (4GByte)
OS: Raspbian Buster (2019-09-26)
MV: 13.5.0 & 13.5.1 (latest nightly)

MediathekView-latest-nightly-linux.tar.gz    07-Jan-2020 09:11    117669820

Java:

$ java --version
openjdk 11.0.5 2019-10-15
OpenJDK Runtime Environment (build 11.0.5+10-post-Raspbian-1deb10u1)
OpenJDK Server VM (build 11.0.5+10-post-Raspbian-1deb10u1, mixed mode)

es fehlen elemente (buttons, bilder, texte):

…

oder die ansicht ist komplett kaputt:

…

auf der console kommen einige ausnahme-/fehlermeldungen:
issue_log.txt

händisch hatte ich folgende pakete installiert, um MV auf meinem RPi zum laufen zu bringen:

sudo apt install openjdk-11-jre openjfx

issues_java.txt

auch passiert es, dass das abspielen von videos nicht immer lippensynchron abläuft. downloaden und dann abspielen ist hingegen kein problem.

wenn diese fehler auftreten, weist mein RPi 4 (mit 4GByte)
keine überhitzungen (CPU temperatur ist immer unter 60°C),
keine übermäßige CPU belastung
und keine speicherarmut auf.

sind die probleme Linux spezifisch oder Raspberry Pi 4 / Raspbian spezifisch?
kann ich die probleme irgendwie beseitigen durch installieren von paketen?

[DaDirnbocher]

@beta-tester klingt nach einen 32bit vs. 64bit Problem.

MV 13,5 läuft - de facto - nur mehr unter 64bit-Systemen.

[MenchenSued]

@DaDirnbocher sagte in Darstellungsfehler und Ausnahmen unter Raspbian auf Raspberry Pi 4:

MV 13.5 läuft nur unter 64bit-Systemen.

Gentoo und Manjaro haben bereits Images für Pi 4 in 64-Bit. Raspbian kann man um einen 64-Bit Kernel erweitern, aber ob das schon reicht, kann ich nicht sagen.

@beta-tester : Probier doch mal eins diese Images aus. Wäre schön, wenn Du über Deine Erfahrungen berichten könntest, insbesondere über die Zeiten zum Laden der Filmliste etc. und der Core-Temperatur. Bisher war mir der Pi 3B gut genug um ffmpeg laufen zu lassen, MV braucht da doch zu viel Speicher.

[beta-tester]

MV 13.5.x ist im prinzip auf meinem RPi4 (4GB) und Raspbian nutzbar, wenn man einige abstriche in kauf nimmt.
eben die filter einstellungen sind nicht zu benutzen, weil der dialog komplett kaputt ist - normale suche und blacklist funktionieren.
unterhalb der filmliste habe ich die details ausgeblendet, damit ich dort nicht immer die kaputte ansicht der film beschreibung angezeigt bekomme - details dialog bei doppelklick funktioniert.
der nicht sichtbare button für das ein/ausschalten der blacklist ist ärgerlich, aber dann klick ich halt ins leere, wo der button eigentlich wäre - die funktion ist da.
videos aus MV heraus anschauen mach ich nicht, bzw. nur um mal reinzuschauen, ob der film es wert ist heruntergeladen zu werden, um ihn dann offline und lippensynchron anzushauen…

also alles doch recht verschmerzbare probleme. noch sind die probleme nicht so groß, als dass ich auf ein anderes 64-bit betriebssystem umsteigen würde.

wenn ich MV ohne console öffne, dann sehe ich die vielen ausnahmen und felhermeldungen nicht. es scheint MV nicht zum abstrutz zu bringen.
die anzeige der bandbreitennutzung hat mal MV zum abstrutz gebracht… dann benutz ich die bandbreitennutzungsanzeige halt nicht. davon geht die welt nicht unter.

der start von MV 13.5.x dauert ca 45 sekunden bis die “alte” filmliste angezeigt wird und die CPU wieder in idle runter fährt (ohne nach einer neuen filmliste zu laden/suchen aber mit aktivierter blackliste)
das laden/ suchen nach einer neuen filmliste dauert ca. 40 sekunden (mit eingeschalteter blackliste und die filmliste zuvor war 10 stunden alt)

der speicherverbrauch scheint so um die 1351488KByte zu sein
(MV nur gestartet, und die filmliste manuell geladen mit eingeschalteter blacklist)

$ ps -xla
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
0  1000 31094   995  20   0 1351484 1089184 futex_ Sl ?         4:14 java -jar /media/pi/99-USB/MediathekView/MediathekView.jar

$ sudo pmap 31094 | grep total
 total  1351488K

HW: RPi 4 (4GB)
Kühler: passiv, heatsink case
OS: Raspbian Buster (aktuelle version und aktuelle upgrades)
MV: 13.5.1
CPU temperatur hängt von der kühlung und dem was MV mach ab.
mein RPi 4 ist bei mir passive gekühlt, bei 20°C raumtemperatur: 42°C in idel, 63°C bei dauer volllast im 4,5 stunden dauernden stresstest.
MV filmliste aktualisieren verursacht vollast für ca. 30 sekunden und erreicht CPU temperatur von 60°C.
aber die 100% volllast blockiert nicht die anderen anwendungen oder desktop.

im hochsommer werden die temperaturen natürlich komplett anders aussehen.

PS.: wenn MediathekView nur unter 64bit architektur läuft, wie machen die das mit den MediathekView Add-on für Kodi unter LibreELEC?
das ist ja zur zeit auch nur 32bittig und läuft ohne probleme.
und überhaupt was unter java ist da so architekturspezifisch?

[vitusson]

@beta-tester sagte in Darstellungsfehler und Ausnahmen unter Raspbian auf Raspberry Pi 4:

PS.: wenn MediathekView nur unter 64bit architektur läuft, wie machen die das mit den MediathekView Add-on für Kodi unter LibreELEC?
das ist ja zur zeit auch nur 32bittig und läuft ohne probleme.
und überhaupt was unter java ist da so architekturspezifisch?

MV und das MV-Kodi-Addon sind zwei völlig unterschiedliche Sachen. Das Addon ist auch kein Java-Programm.

[beta-tester]

@vitusson … ups, sorry, da hab ich garnicht nachgedacht… stimmt, da ist alles in python.

[DaDirnbocher]

@beta-tester sagte in Darstellungsfehler und Ausnahmen unter Raspbian auf Raspberry Pi 4:

und überhaupt was unter java ist da so architekturspezifisch?

JavaFX gibts defacto nicht unter 32bit (für die “aktuellen” Javaversionen).

MV verwendet das, Kodiplugin nicht.

[beta-tester]

also dafür funktioniert dann MV 13.5.x noch erstaunlich gut.
also darf ich nicht jammern sondern muss ich richtig froh da drüber sein…

[DerReisende77]

Also das MV überhaupt auf einem Raspi läuft grenzt schon ein Wunder, da die neueren MV Versionen JavaFX benötigen und das freundliche Oracle/OpenJFX Team bis jetzt überhaupt nur offiziell Windows/Linux Intel/macOS supported. Auch der 32bit Support wird als unnötig erachtet.

Das linux nightly jar beinhaltet JavaFX mit 64 bit Intel support. Die Fehlermeldungen in issues.txt könnten durchaus daher rühren.

[beta-tester]

ok, danke… dann erfreue ich mich an dem wunder und nutze das von MV was geht…
und das ist doch eine menge.

[Ein ehemaliger Benutzer]

@beta-tester sagte in Darstellungsfehler und Ausnahmen unter Raspbian auf Raspberry Pi 4:

eben die filter einstellungen sind nicht zu benutzen, weil der dialog komplett kaputt ist.

Sag mal, Du hast aber nicht zufällig einen java.lang.IllegalAccessError in der Klasse RangeSliderBehavior in der Konsole stehen?

Kannst mal posten, was MV 13.5 da so in Deiner Konsole an Exceptions raus haut?

edit: hab gesehen, das hast Du ja schon getan. Sorry! Ist ein anderer Fehler bei Dir.

[beta-tester]

@rubikon sagte in Darstellungsfehler und Ausnahmen unter Raspbian auf Raspberry Pi 4:

Kannst mal posten, was MV 13.5 da so in Deiner Konsole an Exceptions raus haut?

ich habe MV13.5.1 gestartet und auf das filtersymbol geklickt.
dann versuchtden slider zu benutzen. es ging irgendwie anfang und ende zu ändern, aber nicht so wie ich es unter windows getan hatte.

die filmliste ändert sich on-the-fly unterhalb des dialogs, nach dem der slider verändert wurde - also funktioniert der filter im prinzip, nur ist der dialog so nicht wirklich nurtbar, wenn man nicht weiß, was man geändert hat.
es kommt keine zusätzliche felhermeldung während des öffnen des filter dialogs oder der benutzung des sliders.

alle fehlermeldungen kamen schon voher, bevor der filter dialog geöffnet wurde.
issue_log2.txt

der dialog scheint mit irgend ein zeugs überlagert zu sein oder ein refresch/redraw fehlt…
wenn ich den dialog vergrößer, kann ich mehr von einigen elementen sehen oder wenn ich mit der maus über bestimmte stellen drüber fahren werden kurz felder sichtbar.

[Ein ehemaliger Benutzer]

@beta-tester Wie gesagt Sorry. Ich hatte leider schon auf Absenden gedrückt und erst danach gesehen, dass Du die Fehlermeldungen bereits gepostet hattest. Auf Deutsch hätte ich mir dieses vorige Posting einfach besser sparen können und erst g’scheid lesen. Für Bastler -bissl Erfahrung mit CMD und Java vorausgesetzt- ist es Dank des inzwischen für Win32 verfügbaren JDK+FX von Zulu ja vergleichsweise “einfach”, MV 13.5 irgendwie (ohne Support!) zum Laufen zu kriegen.

Aber das hier?!

Für OpenJFX auf 32-Bit Linux/ARM… ist auf ne Minute in Suchmaschine von Wahl noch das “aussichtsreichste”, selber bauen. Riecht -so wie mein Versuch damals, QT5 mal selbst zu bauen- nach Zeitfresser! Und zwar ohne Erfolgsgarantie! Und auch das nur, wenn man “da steht aufs Querlesen nicht ausdrücklich drin, dass man 64-bit braucht” schon als "aussichtsreich auffasst.

Ansonsten war da halt dieses weiter oben von DaDirnbocher und DerReisende77 wohl gemeinte Posting von johanvos und … da ist man bis auf Weiteres voll auf sich gestellt.

Dass man mit “word width mismatch” noch so weit kommt wie Du… Respekt!

[beta-tester]

@rubikon sagte in Darstellungsfehler und Ausnahmen unter Raspbian auf Raspberry Pi 4:

Dass man mit “word width mismatch” noch so weit kommt wie Du… Respekt!

na ich denk die entwickler von MediathekView haben da ordentliche arbeit geleistet und soviel wie möglich an ausnahmen abgefangen/tolleriert um so weit zu kommen wie es geht.

und libprism_es2, libglassgtk3, libjavafx_font_… und libdecora_sse die als 64bit erwartet werden, aber bei mit nur in 32 bit auf meinem system sind, scheinen nur für die kaputte optik/bedienoberfläch verantwortlich zu sein - vielleicht gibt es ja ein notfall fallback.

[DerReisende77]

@beta-tester hast du Erfahrung im Bauen von Java Apps? Ich habe gesehen es gibt Liberica JDK 13 mit OpenJFX 13 für RPi. Dafür müsste man aber wohl das buildfile anpassen und lokal alles bauen.

[beta-tester]

@DerReisende77 sagte in Darstellungsfehler und Ausnahmen unter Raspbian auf Raspberry Pi 4:

@beta-tester hast du Erfahrung im Bauen von Java Apps?

leider nein. wird wohl mehr sein als javac

[Ein ehemaliger Benutzer]

@DerReisende77 Also ist dreiviertelt Off-Topic…

ich hab mir eben eine VM mit Debian stable i586 eingerichtet, also 32 Bit aber halt für ne andere Architektur als Raspberry Pi. (Ubuntu i586 gibt es ja kein aktuelles mehr)

Spoiler: und bin auf der Nase gelandet.

MV 13.5 hab ich per tar.gz eingespielt und das beigelegte jre Verzeichnis gelöscht.
Liberica JDK 11u5 hab ich von hier, und zwar die .deb Variante für Linux x86 32 Bit (zuvor auch 13u1 vom selben Anbieter) und zwar “regular” nicht die “lite” Version, bei welcher dabei steht, dass kein Java FX dabei ist.

Jetzt hab ich in meinem jugendlichen Leichtsinn “einfach” das java executable aus dem o.g. JDK genommen und damit das MV.jar aus dem .tar.gz aufgerufen.

Ähm, nicht gut: issues.txt - es sieht aufs kurz und unaufmerksam Drüberlesen den Fehlermeldungen von @beta-tester sehr ähnlich. architecture word width mismatch und so.

Ich hab dann noch folgendes getestet:

rubikon@debiani586:~$ 
file ~/.openjfx/cache/14-ea/libprism_es2.so 

/home/rubikon/.openjfx/cache/14-ea/libprism_es2.so: 
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked,
BuildID[sha1]=02dfabce1a4de8dd8736c851406572640df9a455, not stripped

Also, ich hab das jetzt nicht näher betrachtet… aber möglicherweise ist das i586 Paket von Liberica mit einem amd64 Java FX unterwegs… und nicht mit einem i586 Java FX.

Das heißt natürlich für die ARM Architektur (?) nix. Aber ich bin gerade nicht zu zuversichtlich. - Die Jungs von nextcloud hatten zuletzt auch ein halbes Jahr lang eiskalt amd64 Windows Binaries auf x86-32 Bit installiert… was natürlich in die Hose ging. “Mogelpackung” wäre jetzt aber ein böses Wort.

ut desint vires, tamen voluntas esse laudendum

Better luck next time
(wenn ich jetzt versuche, auf dem Ding ein OpenJFX nach Anleitung zu bauen, käme -wenn überaupt- i586 raus weil ich von cross-compilern grad nicht genug Ahnung hab. und das i586 hülfe ja auch wieder keinem…)

-Guts Nächtle

[DerReisende77]

@rubikon du kannst das jar nicht nehmen. Das beinhaltet das OpenJFX mit den 64 Bit libs. Auch wenn du liberica nimmst.
Du musst in der Pom.xml die dependency für OpenJFX löschen und das ganze mit liberica neu bauen. Aber es müssen die Module von liberica OpenJFX dem Build bekannt gemacht werden (Stichwort Module-path). Das ist nicht so ohne weiteres trivial und ich hab mir das nicht angesehen. Aber grundsätzlich sollte es dann mit dem Bauen klappen

[Ein ehemaliger Benutzer]

@DerReisende77 sagte in Darstellungsfehler und Ausnahmen unter Raspbian auf Raspberry Pi 4:

du kannst das jar nicht nehmen.[…]

:face_with_head-bandage:
Treffer, versenkt.

Man sollte ein Wort für den Moment erfinden, wenn man dachte, etwas hilfreiches gesagt zu haben wofür man sich meinetwegen sogar Mühe gegeben hat und dann einerseits erkennt, dass ebendieses Gesagte völliger Käse war und man andererseits gleichzeitig sieht, dass man schon vorher darauf hingewiesen worden war und für die meinetwegen sogar deutlichen Zeichen/ ausdrücklichen Worte einfach blind war.

Wahrscheinlich ist der Wurm, der bei mir drin ist aber so groß, dass es dieses Wort längst gibt und ich es nicht mal kenne.

Qemu, Raspbian, Maven… Vor mir liegt grad eine weitere verschlossene Büchse mit der Aufschrift “Pandora”. Ich glaube, ich lass die Mal zu und halte mich insgesamt von solchen Dosen besser fern .

Ich möchte mich dafür entschuldigen, Deine Zeit verschwendet zu haben.

[DerReisende77]

@rubikon naja man sollte die Flinte nicht immer gleich ins Korn werfen. Der Ansatz wäre ja auch sinngemäß anwendbar für deine 32 Bit Versuch, sollte das dortige liberica auch OpenJFX 13 mitliefern. Ggf ist dann auch eine 32 Bit Version von MV realisierbar.

Aber ich gebe zu dass sich Java in den letzten Jahren auf dem Bereich Desktop nicht zum positiven entwickelt hat. Das wird immer mehr ein echt komplizierter Mist. Vorbei sind die Tage „Write once, run everywhere”