Darstellungsfehler und Ausnahmen unter Raspbian auf Raspberry Pi 4
-
Ein ehemaliger Benutzerantwortete auf beta-tester am zuletzt editiert von 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.
-
@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.txtder 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. -
@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!
-
@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.
-
@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.
-
@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
-
@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 strippedAlso, 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
-
@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 -
@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.
-
@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”
-
@beta-tester ich hab noch nie einen Raspberry Pi aus der Nähe gesehen und von dem Teil 0 Ahnung. Außerdem bin ich ein großes Bisschen zu faul, um mich in QEMU einzuarbeiten und den RPi quasi auf meinem PC zu emulieren.:face_with_stuck-out_tongue_closed_eyes:
Daher meine Frage: Sehe ich das richtig, dass das Liberica JDK 11.0.6 für Linux ARM v7 & v8 32 bit HardFloat auf Der Gerät laufen würde?
Weil wenn ja,
dann wäre -mal im Fieberwahn ins Blaue phantasiert- :crazy_face:
:crazy_face: (m)ein Eclipse auf einem amd64 Windows 10,- gesetzt den Fall, es wäre in der Lage, MV 13.6 für Win32 zu bauen…
…es wäre
- mit einem entsprechend gefütterten Maven Repository mit obigem OpenJDK+FX und
- einer halben Zeile Anpassung am MV Maven build-script
dann möglicherweise vielleicht eventuell in der Fieber-Theorie ebenfalls in der Lage quasi als…
…“Cross-Compiler” ist für Bytecode halt das falsche Wort… :face_with_hand_over_mouth:
ein MediathekView.jar
zusammenzupacken mit enthaltenen 32 Bit JavaFX Bibliotheken :thumbs_up_light_skin_tone: für ARM v7 & v8 32 bit - und damit für RPi mit 32 Bit OS ???
Hätte ich so ein MediathekView.jar… für ARM 32 bit :flexed_biceps_light_skin_tone: , vorausgesetzt ich käme zunächst mit dem für mich testbaren Win32 Build durch :crazy_face:
:crazy_face: - dann könnte ich es halt mangels RPI bei ich nicht testen… - und es hätte nichts mit einem offiziellen MV release zu tun. – Ich wüsste nicht mal, wie ich Dir die -keine Ahnung- irgendwas in der Größenordnung von 70 MB oder so Datei zukommen lassen könnte.
Vorausgesetzt, Du wärst bereit auf Verdacht ein paar hundert MB runterzuladen die -und das kann bei Fieberwahn-Phantasien leicht sein!- nichts anderes sein könnten als ein Haufen Nullen und Einsen für die Tonne…
Na, sa leis!
Bobby still! wosch is? -
@beta-tester so weit ich es verstanden habe, hast Du ein 32-Bit Betriebssystem auf Linux-Basis für die ARM v7 oder v8 Architektur. seit MV 13.3 bestehen MV Builds
- für Linux und Windows
- zum einen Teil aus plattformunabhängigen .class Dateien
- aber zum anderen Teil eben aus plattformabhängigen .so Dateien (Linux) bzw. .dll Dateien (Windows)
- Wie gesagt ist der offizielle MV 13.3+ Build für Linux für eine 64-bit Plattform.
Möglicherweise sind die von Dir gezeigten issues und Darstellungsprobleme auf Deinem 32-Bit Gerät hier ihren Ursprung haben. Ich kann Dir nicht sagen, ob die z.B. laut MV maven build script zum Erstellen der MV-Pakete von u.a. org.openfx genommene Archiv zusätzlich einen Konflikt zwischen x86-64 und der ARM Architektur haben.
Für mich klingt das ein bißchen so, als würde man in einen TDI eines Ingolstädter Autobauers einen Ottomotor eines in München ansässigen Motorenherstellers einbauen - muss ja passen, kommt ja beides aus Bayern… Hauptsache es dreht sich was.
Wie Du im obigen Link zu org.openjfx siehst, kriegt man dort nur plattformabhängige JavaFX Pakete. Für Linux und für Windows sind die jeweils nur für 1 Plattform gebaut, und zwar mit 64 Bit (amd64?) Solche fertigen 32-Bit Maven Pakete gibt’s -im Moment- nicht.
Was es inzwischen aber gibt -und ab hier verlassen wir den von den MV-Entwicklern supporteten Bereich!- sind einige OpenJDK, die JDK Installer etc. mit JavaFX für verschiedene Plattformen anbieten. Win32 (i586, i686) und Linux ARM v7&v8 32-Bit gehören inzwischen zum Angebot. So, mit diesen Installern, funktioniert der offizielle Build-Prozess der MV-Pakete aber nicht.
Ja, man kann sich spielen und es anpassen. Nein, dem MV-Entwickler ist nicht langweilig.
Nun habe ich mir in den letzten Tagen -eigentlich für Win32- mal angeschaut, was man machen muss, um MV 13.6 gegen JavaFX 11.0.6 aus diesen Installern von Zulu bzw. Liberica zu bauen. Der Build-Prozess ist erfolgreich und bei mir läuft der Win32 Build. Er ist aber bis auf 1x Durchklicken im Wesentlichen ungetestet.
Ich habe dann auch in meinem Eclipse unter Win64 mit dem Win32 javac von Liberica .class Files erzeugen lassen und das ganze mit den JavaFX Java Modulen (jmod) von Liberica für Linux-arm32 gepackt (also nicht Win32 .dlls sondern linux-arm32 .so in das MediathekView.jar reinschrauben lassen).
Ich kann mir vorstellen, dass für Deinen RPi dieser I-N-O-F-F-I-Z-I-E-L-L-E Build geeignet sein könnte. Daher lege ich es mal, falls Du magst, bis nächsten Freitag hierher. Vielleicht magst Du ja einen Test machen und probierst es einfach mal aus. Bitte rufe das .jar File mit dem Liberica JDK 11.0.6 für linux-arm32 auf.
Unter Win32
C:\OpenJDK\Liberica...\bin\java -Xmx1G --add-exports javafx.controls/com.sun.javafx.scene.control.inputmap=ALL-UNNAMED -jar MediathekView.jar(der Export wird unter Win32 für den Slider im Filterdialog benötigt)
Der Unterschied zwischen meinem damaligen Vorgehen und dem aktuellen ist: das MV.jar wird nun von vornherein gegen die zur Laufzeit verwendeten Bibliotheken gebaut und mit diesen verpackt. Nicht mehr wie früher, mit irgendwas gebaut und mit irgendwas anderem betrieben.
Für linux-arm32 halt die große Unbekannte: genügt es, mit Windows gebaute .class mit den linux-arm32 Binaries zu verpacken. Keine Gewähr - aber wegen meinem Spieltrieb hab ich’s einfach mal versucht.
Danke an @DerReisende77 für wesentliche Tips, so weit zu kommen!
edit: update von 11.0.5 auf 11.0.6
-
hallo @rubikon verzeihung, dass ich mich jetzt erst wieder melde…
ich habe jetzt mal die bellsoft-jdk11.0.6+10-linux-arm32-vfp-hflt-full.deb installiert und deine MediathekView_linux-arm32_11.0.6.jar ausgeführt.
es kommen fast keine darstellungsfehler und fast keine ausnahmen mehr.der einzige darstellungsfehler ist die unlesbar kleine schriftgröße an vielen stellen:
$ dpkg --get-selections | grep java bellsoft-java11-full install$ java --version openjdk 11.0.6 2020-01-15 LTS OpenJDK Runtime Environment (build 11.0.6+10-LTS) OpenJDK 32-Bit Server VM (build 11.0.6+10-LTS, mixed mode)$ java -Xmx1G --add-exports javafx.controls/com.sun.javafx.scene.control.inputmap=ALL-UNNAMED -jar MediathekView_linux-arm32_11.0.6.jar . Portable Mode: false . Programmstart: 21.01.2020 07:03:18 . Version: 13.6.0 . === JavaVM Parameter === -Xmx1G --add-exports=javafx.controls/com.sun.javafx.scene.control.inputmap=ALL-UNNAMED . ======================== . Verzeichnis Einstellungen: /home/pi/.mediathek3 . Konfig wurde gelesen! WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by impl.org.controlsfx.ReflectionUtils (file:/home/pi/Downloads/MediathekView_linux-arm32_11.0.6.jar) to method com.sun.javafx.css.StyleManager.getInstance() WARNING: Please consider reporting this to the maintainers of impl.org.controlsfx.ReflectionUtils WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release (java:7486): Gtk-CRITICAL **: 07:03:29.319: IA__gtk_window_resize: assertion 'height > 0' failed . Liste Filme gelesen am: 21.01.2020, 07:03 . erstellt am: 20.01.2020, 21:59 . Anzahl Filme: 325433 . Die Filmliste ist 543 Minuten alt . MVHttpClient: Proxy not configured . . Alte Liste erstellt am: 20.01.2020, 21:59 . Anzahl Filme: 325433 . Anzahl Neue: 295 . Filmliste laden (Netzwerk) . Filme in Downloads eintragen . ------------------------------------------------------- . Einstellungen sichern . Einstellungen wurden heute schon gesichert . ------------------------------------------------------- . Daten Schreiben nach: /home/pi/.mediathek3/mediathek.xml . Config Schreiben nach: /home/pi/.mediathek3/mediathek.xml startet . Config Schreiben beendet . MediaDB schreiben (0) Dateien : . --> Start Schreiben nach: /home/pi/.mediathek3/mediadb.txt . --> geschrieben! . Liste Filme gelesen am: 21.01.2020, 07:04 . erstellt am: 20.01.2020, 23:59 . Anzahl Filme: 323548 . Liste Kompl. gelesen am: 21.01.2020, 07:04 . Liste Kompl erstellt am: 20.01.2020, 23:59 . Anzahl Filme: 323548 . . Jetzige Liste erstellt am: 20.01.2020, 23:59 . Anzahl Filme: 323548 . Anzahl Neue: 1670 . . Filme schreiben (323548 Filme) : . --> Start Schreiben nach: /home/pi/.mediathek3/filme.json . --> geschrieben! . Write duration: 10546 ms . Filme in Downloads eintragen . Daten Schreiben nach: /home/pi/.mediathek3/mediathek.xml . Config Schreiben nach: /home/pi/.mediathek3/mediathek.xml startet . Config Schreiben beendet . Daten Schreiben nach: /home/pi/.mediathek3/mediathek.xml . Config Schreiben nach: /home/pi/.mediathek3/mediathek.xml startet . Config Schreiben beendet Exception in thread "JavaFX Application Thread" java.lang.NullPointerException at mediathek.gui.bandwidth.BandwidthMonitorController$1.lambda$0(BandwidthMonitorController.java:80) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428) at java.base/java.security.AccessController.doPrivileged(Native Method) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427) at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) at javafx.graphics/com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at javafx.graphics/com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$11(GtkApplication.java:277) at java.base/java.lang.Thread.run(Thread.java:834) . Daten Schreiben nach: /home/pi/.mediathek3/mediathek.xml . Config Schreiben nach: /home/pi/.mediathek3/mediathek.xml startet . Config Schreiben beendet . ################################################################################ . --> Beginn: 21.01.2020 07:03:18 . --> Fertig: 21.01.2020 07:11:28 . --> Dauer: 8.163 min . ################################################################################ich habe mal die offizielle “normale” MediathekView jar ausprobiert und siehe da, die wirft gar keine ausnahme:
$ java -Xmx1G --add-exports javafx.controls/com.sun.javafx.scene.control.inputmap=ALL-UNNAMED -jar MediathekView.jar . Portable Mode: false . Programmstart: 21.01.2020 07:29:52 . Version: 13.5.1 . === JavaVM Parameter === -Xmx1G --add-exports=javafx.controls/com.sun.javafx.scene.control.inputmap=ALL-UNNAMED . ======================== . Verzeichnis Einstellungen: /home/pi/.mediathek3 . Konfig wurde gelesen! WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by impl.org.controlsfx.ReflectionUtils (file:/media/pi/99-USB/MediathekView/MediathekView.jar) to method com.sun.javafx.css.StyleManager.getInstance() WARNING: Please consider reporting this to the maintainers of impl.org.controlsfx.ReflectionUtils WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release (java:11603): Gtk-CRITICAL **: 07:30:02.959: IA__gtk_window_resize: assertion 'height > 0' failed . Liste Filme gelesen am: 21.01.2020, 07:30 . erstellt am: 20.01.2020, 23:59 . Anzahl Filme: 323548 . Die Filmliste ist 450 Minuten alt . MVHttpClient: Proxy not configured . Keine aktuellere Liste verfügbar . Filme in Downloads eintragen . ------------------------------------------------------- . Einstellungen sichern . Einstellungen wurden heute schon gesichert . ------------------------------------------------------- . Daten Schreiben nach: /home/pi/.mediathek3/mediathek.xml . Config Schreiben nach: /home/pi/.mediathek3/mediathek.xml startet . Config Schreiben beendet . MediaDB schreiben (0) Dateien : . --> Start Schreiben nach: /home/pi/.mediathek3/mediadb.txt . --> geschrieben! . Daten Schreiben nach: /home/pi/.mediathek3/mediathek.xml . Config Schreiben nach: /home/pi/.mediathek3/mediathek.xml startet . Config Schreiben beendet . ################################################################################ . --> Beginn: 21.01.2020 07:29:52 . --> Fertig: 21.01.2020 07:31:32 . --> Dauer: 1.668 min . ################################################################################also wenn ich die schriftgröße irgendwie ändern könnte wär alles perfekt, und das ohne eine spezielle version für RaspbarryPi von MediathekView zu benutzen.
-
@beta-tester
GDK_SCALE=2 java -Xmx1G -Djdk.gtk.version=3 -jar…Libgtk3 muss dafür installiert sein und sollte die kleinen Komponenten lesbar hoch skalieren.
-
@DerReisende77
Danke für den tipp mit dem scale, aber das bläst nur die Gtk elemente auf das dopperlte auf, aber die schriften die vorher unlesbar klein gewesen waren, sind immer noch genauso winzig wie ohne dem scale…
EDIT: gibt es einen scale parameter nur für javaJFX ?
-
@DerReisende77
interessant, wenn ich meinen RPi4 auf eine auflösung von 4k (3840x2160 native auflösung des TV) einstelle, und dann MediathekView öffne, dann sind die kleinen schriften zwar immer noch klein, aber dafür gestochen scharf und leserlich…
jedoch auf die entfernung vom sessel aus ist diese auflösung nicht mehr lesbar.
komisch, dass diese schriften scheinbar optisch konstant groß bleiben.
sind diese schriften auf eine bestimmte mm-größe (MilliMeter) eingestellt, statt sich der übrigen skalierung unterzuordnen wie es GTK_SCALE für die anderen elemente tut?EDIT: wenn ich, während MediathekView noch ausgeführt wird, die auflösung (quasi unterm hintern weg) von 3849x2160 zurück auf 1920x1080 stelle, ist alles wie es ein sollte.
die winzigen schriften sind größer und immer noch scharf/gut lesbar
jedoch MV einmal schließen und dann neu öffnen und alles ist wieder unleserlich verschwommen klein
PS.: ich meine die schriften/elemente im filterdialog, dem filtereingabefeld, der unteren statusleiste, …
nicht die anderen schriften wie der filmliste!
ich schreibe das nur, damit nicht jemand meint, ich wäre schwer sehbehindert -
Ein ehemaliger Benutzerantwortete auf beta-tester am zuletzt editiert von Ein ehemaliger Benutzer
@beta-tester sagte in Darstellungsfehler und Ausnahmen unter Raspbian auf Raspberry Pi 4:
ich habe jetzt mal die bellsoft-jdk11.0.6+10-linux-arm32-vfp-hflt-full.deb installiert und deine MediathekView_linux-arm32_11.0.6.jar ausgeführt.
es kommen fast keine darstellungsfehler und fast keine ausnahmen mehr.Na, das sieht doch mal besser aus als die Screenshots im OP. Das oben zum Download verlinkte .jar hab ich aus der cloud genommen. Für mich ist dieses jar wie gesagt ein “Beiprodukt”, entstanden aus meinem Versuch, MV für Win32 zu bauen. - Das, was Dir geholfen hat war wohl dann eher Hinweis von @DerReisende77 auf ein JDK mit JavaFX für linux-arm32… keine Ahnung.
Ich habe für den inoffiziellen Build gegen Java 11.0.6 mit zugepacktem JavaFX gebaut (also JavaFX 11.0.6)
Die MV-Entwickler machen das anders, wie Du am pom.xml siehst (L73-L77). Dort wird mit JavaFX von org.openjfx v14-ea+6 gebaut. Und gerade vorhin hat @DerReisende77 betont, dass für den offiziellen Build aus gutem Grund 14-ea+6 verwendet wird, was -ich übersetZitiere hier- unter anderem mit fehlerhafter Darstellung von Dialogen in KDE zu tun habe.Analog gedacht, eine möglichst hohe JavaFX Version einzusetzen mit möglichst vielen Bugfixes, ist ggfs. Java 13.0.2 einen Schuss ins Blaue wert? Aber ob die auch für JavaFX 14 einen early access build für RPi anbieten, so wie damals für ea 13 4… kann ich nicht sagen.
Ich hatte vor einer Weile für @DerReisende77 auf meinen (amd64) Linux VMs getestet, ob der o.g. GDK_SCALE Vorteile bringt gegenüber dem in der Anleitung genannten Java VM-Parameter uiScale (muss für Linux ganzzahling sein!)… konnte aber keine Vorteile erkennen. Bei meinen Linux amd64 VMs skaliert beides, GDK_SCALE und uiScale die komplette GUI um z.B. 200%. Schrift, Buttons, Swing-Anteile, JavaFX-Anteile - alles. Aber halt mit dem offiziellen Linux-Build von MV.
Ob es auf dem RPi, einem Gerät, das ich nicht habe, jetzt besser ist, ein gefixtes JavaFX (14ea6) für die falsche Plattform (64-bit) einzusetzen oder ein “ungefixtes” JavaFX (11u5 bzw. 13u2) für die richtige Plattform(linux-arm32)… ich bin hier eher raus aus der Nummer/Thread, insbesondere in Bezug darauf, Beiträge mit wenigstens einem Hauch von Ahnung verfassen zu können. - Java hat mir grade heute Vormittag mal wieder -in einem völlig anderen Kontext als MV- eine deutliche Wasserstandsmeldung gegeben, welchen “Kenntnisstand” ich tatsächlich habe. Ich bin mal wieder bedient und lass jetzt lieber die Erwachsenen sprechen.
Danke für den Test des “cross-build” jar (Win32 javac -> linux-arm32 Paket) trotzdem!
-
@rubikon
ich habe jetzt mal die 13’er version ausprobiert - eine 14’er early access version konnte ich nicht für mein RPi finden.
das verhalten von MV ist aber damit das selbe.einen kurzen hoffnungsschimmer hatte ich bei der benutzung von parameter
-Dsun.java2d.uiScale=2.0.
damit hat sich ALLES um den faktor 2 vergrößert - auch die JavaFX sachen.
meine hoffnung war, mit -Dsun.java2d.uiScale=2.0 ALLES zu vergrößern und mit GDK_SCALE=0.5 nur die Gtk elemente wieder auf die ursprungsgröße runter zu skalieren… jedoch versteht GDK_SCALE leider nur ganzzahlige werte…
-
ach ja, mir ist aufgefallen mit der “richtigen” java version (bellsoft-JDK statt openJDK) ist auch das problem mit dem abspielen der videos aus MV heraus beseitigt
(die videos stocken nicht mehr und bild und ton sind nicht mehr so extrem versetzt). -
@beta-tester was hat das mit der “richtigen” Javaversion zu tun? Hint: Das Abspielen erledigt doch eh ein externes Programm.