@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.

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

@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.

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. ;-)

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!

cat /opt/MediathekView/MediathekView.desktop 
#!/usr/bin/env xdg-open
[Desktop Entry]
Type=Application
Name=MediathekView
Exec=/bin/sh "/opt/MediathekView/MediathekView" %U
StartupWMClass=install4j-mediathek-Main_MediathekView
Icon=/opt/MediathekView/.install4j/MediathekView.png
Categories=Network;FileTransfer

und dort könnte ich die Exec-Zeile so abändern, dass nicht das Script MediathekView sondern direkt das jar-Archiv gestartet wird.
Exec=jre/bin/java --enable-preview -jar MediathekView.jar

## $INSTALL4J_JAVA_PREFIX exec "$app_java_home/bin/java" "-Xmx2G" "-XX:+UseG1GC" "-XX:+UseStringDeduplication" "--enable-preview" "-Dfile.encoding=UTF-8" "-DexternalUpdateCheck" $INSTALL4J_ADD_VM_PARAMS -classpath "$local_classpath" install4j.mediathek.Main_MediathekView  "$@" ## so war es ursprünglich
$INSTALL4J_JAVA_PREFIX exec "$app_java_home/bin/java" "-Xmx2G" "-XX:+UseG1GC" "-XX:+UseStringDeduplication" "--enable-preview" "-Dfile.encoding=UTF-8" $INSTALL4J_ADD_VM_PARAMS -classpath "$local_classpath" install4j.mediathek.Main_MediathekView  "$@"
return_code=$?

Allerdings half auch diese Veränderung nicht. Wie gesagt: Ich bin nicht mehr ganz frisch im Kopf und heillos überfordert. Sonst hätte ich nicht um Hilfe gefragt.