Starten von MV ohne den Upgrader zu aktivieren?

[EcksHecker]

@menchensued
Ach so, das meintest du!
Ehe ich das probieren wollte, checkte ich mal die Wirkung und:

java --enable-preview -jar /opt/MediathekView/MediathekView.jar
Fehler: Beim Laden der Klasse mediathek.Main ist ein LinkageError aufgetreten
	java.lang.UnsupportedClassVersionError: mediathek/Main (class file version 59.65535) was compiled with preview features that are unsupported. This version of the Java Runtime only recognizes preview features for class file version 55.65535

Aber danke trotzdem. Und schönen Sonntag!

[MenchenSued]

@eckshecker
Du hast sicherlich noch eine ältere Java-Version (vermutlich Java 11) auf Deinem Rechner. Mediathekview bringt seine eigene mit und die musst Du mit
/opt/MediathekView/jre/bin/java
aufrufen. Mit java --version siehst Du, welche Version installiert ist, für die Version 13.7 wird Java 15 benötigt und das sollte Dir der Befehl
/opt/MediathekView/jre/bin/java --version
auch melden.

[EcksHecker]

@menchensued
Wow! Jetzt sitze ich mitten drin im Wespennest:

Erstmal danke für die Erklärung zur Java-Version. Du hast recht damit, dass meine Version(en) veraltet sind, und dass MV seine eigene verwendet. (Gelegentlich mache ich sicherlich mal eine neue VM in der das Problem nicht mehr auftritt.)
Was ich aber erstaunt beobachten mußte, ist, dass die alternative Java-Version nicht richtig installiert wurde. Denn eigentlich gehört eine solche mit

sudo update-alternatives --config java

ausgewählt, nachdem sie dem System korrekt bekannt gemacht wurde. Die Methode vom MV sieht mir eher nach quick&dirty aus.
Aber sei’s drum, Gott sei Dank ist es bei mir NUR eine VM, und in der kann meinetwegen Einiges seltsam laufen. Also startete ich mal den geänderten java-Befehl und damit MV, aber dann kam gleich eine Beschwerde über fehlenden RAM.
Die 13.7.1 läuft aber sonst problemlos, also habe ich mir mal die fertige Kommandozeile organisiert, die das Script erzeugt hat:

/opt/MediathekView/jre/bin/java -Xmx2G -XX:+UseG1GC -XX:+UseStringDeduplication --enable-preview -Dfile.encoding=UTF-8 -classpath /opt/MediathekView/.install4j/i4jruntime.jar:/opt/MediathekView/.install4j/launcher9ad06d59.jar:/opt/MediathekView/MediathekView.jar install4j.mediathek.Main_MediathekView

Und siehe da: Jetzt gibt es keine Beschwerde über RAM mehr, sondern es heißt: “Configuring for non-portable mode” und es startet wieder der Updater mit seiner nervigen Frage, ob ich auf 13.8.0 gehen möchte.
==> Ende Gelände!
Immerhin haben wir gelernt:
Dieses geniale Programm wird offenbar nur von einem einzigen Entwickler - in seiner Freizeit - bearbeitet, was zunächst einmal ein riesiges Lob verdient, und dass dann solche debian/Ubuntu-Spezifika nicht korrekt gehandhabt wurden, kann ich schon auch entschuldigen.

Leider bedeutet der aktuelle Stand, dass ich noch immer keine Lösung für meinen Wunsch weiß, das Update zu unterbinden. Ich habe schon mal über iptables nachgedacht, um die Verbindung zum Server evtl selektiv zu unterbinden.

Und ich werde mir mal den Tiny-media-Manager genauer ansehen. Vielleicht erlöst mich das ja mittelfristig von meinem Leiden.

[styroll]

@eckshecker sagte: Leider bedeutet der aktuelle Stand, dass ich noch immer keine Lösung für meinen Wunsch weiß, das Update zu unterbinden.

Das Problem ist bekannt – und ich weiss jetzt nicht, wieso der Moderator als Linux-User dem Problem nicht mal selbst auf den Grund geht (okay man kann auch den ganzen So hin und her zu schreiben…).

Aus dem oben verlinkten Thread lässt sich (spekulativ) ableiten, dass die Deaktivierung der Updatesuche über die Einstellungen (GUI) möglicherweise nicht funktioniert, gemäss dem OP aber sehr wohl, wenn man eine Settings-Datei manuell editiert.

[MenchenSued]

@styroll
Ich bin nur Moderator, kein Entwickler. Also verlange von mir nicht, jede beliebige alte Version am Laufen zu haben. Meine Anregung war ja nur, auf den Installer zu verzichten und MediathekView direkt zu starten. Aber solange .install4j in der Startzeile auftaucht, hat der TE das noch nicht gemacht.

[EcksHecker]

Oh, je!
Entschuldigung, falls meine ungeschickte Kommunikation hier Störungen auslöste. Das wollte ich nicht.
Danke für den Link auf die settings.xml-Datei.
Ich habe prompt nach gesehen, und die Updates standen bereits auf false.

Es ist richtig, dass ich (noch) keine MV.desktop-Datei gebastelt habe, weil bereits von der Kommandozeile aus der betreffende Befehl scheitert. Entweder wegen fehlender Angaben (zu wenig RAM) oder, wenn ich die komplette Zeile samt Argumenten und so mitnehme, erscheint wieder der Update-Dialog.

Nein, ich erwarte von Niemandem, eine veraltete Version am Laufen zu halten. Dass ich diesen schlimmen Hack (auf eigenes Risiko) gegangen bin, ist meine eigene Wahl und Entscheidung. Aber wenn wir schon dabei sind, die Dinge beim Namen zu nennen, ich finde nicht abzuschaltende automatische Updates extrem übergriffig und eher im Stile von solch Ehr-verletzenden Firmen wie Google oder Microsoft.

Ich selbst habe solches Vorgehen bislang nur einmal verwendet, und zwar um eine Art Botnetz unbemerkt zu verbreiten. Damit will ich sagen: “So etwas tut man nicht, wenn man ein anständiger Entwickler ist.”

Und nur durch die bei mir im Einsatz befindliche Virtualisierung konnte ich einigermaßen einfach wieder auf eine ältere Version zurück gehen, nachdem mir aufgefallen war, dass mir nach dem Update die Abfragemöglichkeit für die Mediensammlung fehlte.

Aber bitte, meine (als ehemaligem Entwickler geschuldeten) hohen ethischen Berufs-Standards sollen hier niemanden kränken oder einschränken. Sie haben mir nur ein ganzes Berufsleben lang sehr gute Dienste erwiesen.

Ich finde es toll, dass sich mal jemand meiner Sorgen angenommen hat, denn ich kam schon eine ganze Weile nicht mehr voran, und das, obwohl ich ein echter “Spielratz” bin.

Love, Peace & Happiness

[alodeu]

@eckshecker Ich würde in der HOSTS Datei am Rechner wo das Programm läuft einfach die IP-Adresse, die für den Update verwendet wird auf 0.0.0.0 setzen, dann findet er keine Information über ein neues Update und gibt eine Ruh! Ich weiss leider nicht wonach er sucht, vielleicht weiss das wer.

[styroll]

@alodeu sagte: einfach die IP-Adresse, die für den Update verwendet wird auf 0.0.0.0 setzen, dann findet er keine Information über ein neues Update und gibt eine Ruh!

Ist dann halt bloss ein Workaround:

@menchensued sagte: Ich bin nur Moderator, kein Entwickler. Also verlange von mir nicht, jede beliebige alte Version am Laufen zu haben. Meine Anregung war ja nur

Du musst gar nichts. Das war auch nur eine Anregung, um effizienter vorzugehen.

Um eine alte Version zu installieren und das Problem zu verifizieren bzw. Schritt um Schritt für die Reproduktion des Fehlers genau zu beschreiben, muss man aber kein Entwickler sein.

Ich hab in der Vergangenheit schon zig mal eine alte Version installiert, um ein Problem zu verifizieren. Die Installation und Deinstallation und das Backup der Einstellungen benötigt (auf macOS und Win) gerade mal 2–3 min. Das mag auf Linux etwas länger gehen, wenn man noch sicherstellen muss, dass die korrekte Java-Version verwendet wird, aber sicher immer noch weniger Zeit als um einen ganzen Thread zu füllen.

Und in ähnlicher Sache habe ich da vor kurzem gerade ein Issue erstellt, die auch sofort von @alex gelöst wurde.
Wenn ein Problem genau beschrieben wird und auch einfach zu lösen ist (wie ziemlich sicher auch das hier vorliegende Problem), dann reagiert das MV-Team eigentlich immer sehr schnell.

[MenchenSued]

@eckshecker
Ich hatte heute (da Feiertag in Bayern) die Version 13.7.1 lokal installiert und getestet. Beim Aufruf vom Skript MediathekView kommt die Abfrage nach einem Update, nicht aber beim Aufruf durch die Zeile
jre/bin/java --enable-preview -Xmx2G -jar MediathekView.jar
Erstell Dir doch ein Skript oder einen Starter mit dieser Befehlszeile im Ordner /opt/MediathekView.

[EcksHecker]

@menchensued
Stürmischen Dank! Ja!!! Das funktioniert hier auch, und ich bin sehr glücklich.