Das klappt aber nur bis Version 13.0.6. Mit neueren muss man die Instanzen, die parallel laufen sollen, unter verschiedenen Benutzern starten.

Es ist richtig für den GUI-Modus von MV 13.2.1, dass beim Start geprüft wird, ob bereits eine Instanz läuft.

Wenn man die Annahme macht, dass singleInstanceWatcher.isAppAlreadyActive()
(sh. Main.java v13.2.1 L276) die einzige verwendete Methode ist, um ein bereits laufendes MV zu detektieren, dann kann man sich z.B: nach checkout des src von tag 13.2.1 mit grep o.ä. leicht ein Bild davon machen, dass es im MV 13.2.1 src nur dieses 1 Vorkommen dieses Funktionsaufrufs gibt: Beim Start im GUI-Modus.

D.h.: beim besagten Start im Auto-Modus führt 13.2.1 diesen Test nicht durch. D.h. wenn man sich mit der o.g. Annahme begnügt, wäre es laut Quellcode 13.2.1 damit möglich MV 13.2.1 im Auto-Modus gleichzeitig in mehreren Instanzen laufen zu lassen.

Ohne Gewähr auf Richtigkeit / Vollständigkeit.

Ob es sich hier um eine ungewollte Lücke in der Programmlogik oder um eine bewusste Entscheidung handeln sollte, dazu kann ich nichts sagen. :man_shrugging_light_skin_tone:

@JD-Umsteiger sagte in Fehlermeldung "unable to find valid (Java) certification path to requested target":

So realisiere ich zwei völlig unabhängig voneinander laufende “Installationen”, die auch parallel laufen können.

Das klappt aber nur bis Version 13.0.6. Mit neueren muss man die Instanzen, die parallel laufen sollen, unter verschiedenen Benutzern starten.

Da muss ich dich korrigieren. Ich praktiziere dies mit der Version 13.2.1 schon seit deren Erscheinen - allerdings portable. Und es gibt beim nächtlichen Start mit dem Task Scheduler öfter zeitliche Überschneidungen, wenn es mal mehr Filme sind und der erste Durchlauf noch nicht fertig ist. Das ist kein Problem!

Warum sollte es denn deiner Meinung nicht möglich sein?

So realisiere ich zwei völlig unabhängig voneinander laufende “Installationen”, die auch parallel laufen können.

Das klappt aber nur bis Version 13.0.6. Mit neueren muss man die Instanzen, die parallel laufen sollen, unter verschiedenen Benutzern starten.

Ich muss leider die portable Version von MV verwenden, da ich die Filme aus meinem Abo sowohl in HD als auch in SD laden möchte.

Du kannst das so machen, musst Du aber nicht. Darum sagte ich ja vorhin: Es ist möglich, in den Einstellungen (unter “Set bearbeiten”), z.B. durch Duplizieren ein zweites “Speichern” Set anzulegen. Das eine Set nimmt HD auf, das andere SD. Das jeweilige Set kann man beim Anlegen eines Abo zuordnen.

Das aber kann die ‘normale’ GUI-Version von MV nicht in Abos verwalten.

s.o.: Das Abo 1x dem HD-Speichern Set zuordnen, das Abo nochmal anlegen und dieses dann dem SD-Set zuordnen.

Also muss ich zwei MV-“Installationen” verwenden, die aber leider auf dieselben Konfig-Dateien zugreifen würden.

Du kannst das so machen, musst aber nicht. Beim Trennen der Abos in 2 getrennte Konfig-Ordner ginge auch dies: 1 Kopie von MV, die mal die eine und mal die andere Konfig-Datei verwendet
java -jar C:\MV\mediathekview.jar EinstellungenHD/.mediathek3
java -jar C:\MV\mediathekview.jar EinstellungenSD/.mediathek3

Ist aber beides off-topic, sorry. Die im OP gestelllte Frage lautet, warum der SSL-Handshake beim Aufbau der https Verbindung zu liste.mediathekviewweb.de nicht klappt. Das Problem besteht nun offenbar nicht mehr und daher, nur für mich gesprochen, EOT :waving_white_flag:

“c:\Program Files\Java\jre1.8.0_231”\bin\java.exe -Xmx1g -jar C:\MediathekView-13.2.1\MediathekView.jar TestSet/.mediathek3
startet MV mit eigenen Einstellungen im Verzeichnis %USERPROFILE%\TestSet.mediathek3

@rubikon

Das mache ich doch schon seit Jahren so!!
Allerdings geringfügig anders umgesetzt.
Habe ich doch direkt als Hinweis geschrieben:

ZIZAT
java -jar C:\PortableApps\MediathekViewHD\MediathekView.jar Einstellungen/.mediathek3 -auto
ZIZAT ENDE
Und der zweite: (SD-Abo)
java -jar C:\PortableApps\MediathekViewSD\MediathekView.jar Einstellungen/.mediathek3 -auto

Da beide portabel laufen, befindet sich der jeweilige Einstellungenordner im jeweiligen Programmordner.

So realisiere ich zwei völlig unabhängig voneinander laufende “Installationen”, die auch parallel laufen können.

Und ich muss beim Verwenden auf einem anderen PC nur einfach die beiden Programmordner kopieren. Und das Ganze läuft auch vom USB-Stick bei Bedarf.

nämlich jeden Film aus meinem Abo einmal in SD und einmal in HD zu laden.

man kann hier auch das Set “Speichern” duplizieren und eine der beiden Kopien speichert SD, die andere HD. Dann legt man das Abo 1x an zum Set SD-Speichern, 1x zum HD-Speichern.

portablen “Installationen”

Ich verstehe nicht, was mit “portabler Installation” gemeint ist. Muss/will ich auch nicht.
Der Schalter -m tut was anderes, stimmt. Mein Fehler

"c:\Program Files\Java\jre1.8.0_231"\bin\java.exe -Xmx1g -jar C:\MediathekView-13.2.1\MediathekView.jar TestSet/.mediathek3

startet MV mit eigenen Einstellungen im Verzeichnis %USERPROFILE%\TestSet\.mediathek3
ggfs. eine Kopie von settings.xml und mediathekview.xml reinlegen, um nicht völlig von vorn zu beginnen

Hast Du schon in der Anleitung geschaut im Abschnitt “Starten mit zusätzlichen Parametern”. Ich verwende es selbst nicht, aber da wäre ein Schalter -m

-m für maximiertes Fenster…
ich verstehe jetzt nicht ganz, welchen Tipp du mir damit geben willst.
Ich starte ja mit zusätzlichen Parametern und erreiche auch genau das, was ich will:

nämlich jeden Film aus meinem Abo einmal in SD und einmal in HD zu laden.

Aber, wenn das auch einfacher geht, als mit zwei portablen “Installationen”, dann lerne ich gern dazu. Das meine ich so wie ich es sage.

Ich bitte hiermit um Nachhilfe :-)

@JD-Umsteiger

@JD-Umsteiger sagte in Fehlermeldung "unable to find valid (Java) certification path to requested target":

inzwischen ist die Version so alt, dass das geschilderte Problem auftritt

Oh je, gut, dass mein Laptop das mit der Veralten von JRE 8u231 und MV 13.2.1 noch nicht mitbekommen hat. Der hat grade eben vor lauter Schreck vergessen, beim Starten von MV 13.2.1 mit JRE 8u231 dieses Zertifikatsproblem zu melden und aus Versehen MV 13.2.1 ganz normal gestartet :astonished_face:

Du wirst lachen, bevor ich das hier von dir gelesen habe, habe ich nochmals versucht, mir die Meldungen aktuell anzusehen:

Am 09.12. hatte es das letzte Mal funktioniert.
Und seit heute (Nachmittag) ist das Problem nicht mehr vorhanden.
Auf meinen beiden PCs soeben getestet.
Gehe ich in meiner Annahme richtig, dass es an den Servern mit den Filmlisten lag?

Aber da gibt es ja wohl mehrere…
die von MV zufällig ausgewählt werden, oder???

Und/oder hat da einfach jemand das Problem “repariert”?

@JD-Umsteiger sagte in Fehlermeldung "unable to find valid (Java) certification path to requested target":

inzwischen ist die Version so alt, dass das geschilderte Problem auftritt

Oh je, gut, dass mein Laptop das mit der Veralten von JRE 8u231 und MV 13.2.1 noch nicht mitbekommen hat. Der hat grade eben vor lauter Schreck vergessen, beim Starten von MV 13.2.1 mit JRE 8u231 dieses Zertifikatsproblem zu melden und aus Versehen MV 13.2.1 ganz normal gestartet :astonished_face:

@JD-Umsteiger sagte in Fehlermeldung "unable to find valid (Java) certification path to requested target":

Oder wird das Zertifikat des Filmlisten-Servers nicht (mehr) akzeptiert?

Du hast aber meinen Post schon gelesen und den Abschnitt zu Debug SSL… ?:face_with_monocle:
EDIT: hier ist ein Programm, das nur https Request zur Basis URL der Filmliste (L33) macht. Dann bleibt wie gesagt die Konsolenausgabe ohne MV-Spezifisches

@JD-Umsteiger sagte in Fehlermeldung "unable to find valid (Java) certification path to requested target":

Also müssen sie portable sein, denn dann, und nur dann hat jeder Instanz einen eigenen Konfig-(Einstellungen)Ordner.

Hast Du schon in der Anleitung geschaut im Abschnitt “Starten mit zusätzlichen Parametern”. Ich verwende es selbst nicht, aber da wäre ein Schalter -m :thinking_face:

EDIT: das mit -m war Käse von mir

Zum besseren Verständnis:
Ich muss leider die portable Version von MV verwenden, da ich die Filme aus meinem Abo sowohl in HD als auch in SD laden möchte.
Das aber kann die ‘normale’ GUI-Version von MV nicht in Abos verwalten.
Also muss ich zwei MV-“Installationen” verwenden, die aber leider auf dieselben Konfig-Dateien zugreifen würden.
Also müssen sie portable sein, denn dann, und nur dann hat jeder Instanz einen eigenen Konfig-(Einstellungen)Ordner.
Und nun hat man vor geraumer Zeit beim Weiterentwickeln ‘portable’ erstmal gestrichen. Soll (!) irgendwann wieder eingebaut werden.

Und inzwischen ist die Version so alt, dass das geschilderte Problem auftritt :-(

@JD-Umsteiger sagte in Fehlermeldung "unable to find valid (Java) certification path to requested target":

Beide sind von dem (vermutlich abgelaufenen) Zertifikat betroffen.

Ich wundere mich zunächst mal: wenn das Zertifikat abgelaufen ist: warum kein neues?

Ob die nachfolgende Prozedur für abgelaufene Zertifikate klappt, weiß ich nicht. Bei mir ging es um ein völlig anderes, eigenes, Programm, um eine völlig andere Webseite und um ein Problem mit einem aktuell gültigen self-signed Zertifikat.

Damals hab ich ein wenig gesucht und

• mein Programm erst mal über den Java-Schalter

java -Djavax.net.debug=SSL -jar MeinProgramm.jar

gestartet. Da kam dann eine Fehlermeldung in die Konsole, mit der etwas mehr anzufangen war. Da solltest Du wohl sehen können, was das Problem mit dem Zertifikat ist. Zur Not hab ich mal ein Java-Programm zusammengeräubert, welches mit https://liste.mediathekviewweb.de kommuniziert. Dann mischen sich nicht die Konsolenausgaben von MV mit denen des SSL-Debugging. Ich hab eine .jar Datei… und wüßte nicht, wie die ins Forum hochzuladen geht. Bin mir auch nicht sicher, ob das erforderlich ist.

• Ich hab dann eine Anleitung wie diese hier gefunden.

• gemäß dieser Anleitung hab ich mir dann alle beteiligten Zertifikate ausgeben lassen. In meinem Fall hab ich das mit dem Programm openssl gemacht. Ist z.B. im Installationsumfang von git für Windows enthalten, gibt’s aber auch im MSYS Paket oder in cygwin oder ggfs. findest Du anderen Installer - oder eben eine komplett andere Methode. Hab die Anleitung nicht komplett durch, sondern nur einen kleinen Teil.

• mein Aufruf von openssl lautet (editiert: backslash statt cmd prompt, double quotes wg. Leerzeichen im Pfad)

"C:\Program Files\Git\usr\bin\openssl.exe" s_client -connect liste.mediathekviewweb.de:443 >c:\temp\ausgabe.txt

• aus der Datei C:\temp\ausgabe.txt habe ich dann alle Zertifikate ausgeschnitten und das hier

-----BEGIN CERTIFICATE-----
irgendwas in base 64 
-----END CERTIFICATE-----

mit Notepad++ jeweils als meinzertifikat.crt gespeichert.

• dann hab ich zu jeder Java-Installation, die MeinProgramm.jar ausführen soll, die cacerts Datei gesucht. z.B.
  C:\Program Files\Java\jdk1.8.0_201\jre\lib\security\cacerts oder
  C:\Program Files\Java\jre1.8.0_231\lib\security\cacerts
  Und dann hab ich, so wie in der o.g. Anleitung das jeweilige keytool aufgerufen.

• eine CMD Shell als Administrator ausführen,

C:\Program Files\Java\jre1.8.0_231\bin\keytool.exe
 -import -alias meinkram 
-keystore "C:\Program Files\Java\jre1.8.0_231\lib\security\cacerts"
-storepass changeit 
-keypass changeit 
-file meinzertifikat.crt

und dann auf eigene Verantwortung die Frage, ob ich das Zertifikat importieren will, mit Y beantwortet

Das mit den Admin-Rechten für CMD bilde ich mir deswegen ein, weil die cacerts Datei meistens im schreibgeschützten Verzeichnis C:\Programme liegt.
Wenn man es nicht selbst gesetzt hat, dann ist die cacerts per default mit dem Passwort “changeit” versehen.

In meinem Anwendungsfall konnte ich dann -nach Durchführen der Maßnahme für jede benötigte Java-Installation für jeden benötigten Rechner und der jeweiligen cacerts- die https Verbindung zu der anderen Webseite mit meinem Java-Programm erfolgreich herstellen.

Sollte jemand die Prozedur zu kompliziert finden, bitte nicht mich schimpfen - ich kenn mich mit dem Thema eigentlich 0 aus und hab einfach nur ein bisschen gegoogelt und es hier in etwas ähnliches wie Deutsch übersetzt.

Und wie gesagt: ob die Prozedur zum Ziel führt bei abgelaufenen Zertifikaten - keine Ahnung. Da ist ggfs. eine andere administrative Maßnahme bzgl. Stand der Zertifikate mehr sinnvoll.

Noch als ergänzende Info:
Ich starte die Konsolenversion wie folgt

java -jar C:\PortableApps\MediathekViewHD\MediathekView.jar Einstellungen/.mediathek3 -auto

auf einem PC ist Java jre1.8.0_231 (nur 64 bit) installiert,
auf dem anderen PC sind die 64 und die 32 bit-Version jre1.8.0_231 installiert.
auf beiden PCs dasselbe Problem!

@JD-Umsteiger das wird vermutlich hässlich zu beheben…
… Ich kann erst am Abend mehr Details geben.

Oh, das wäre lieb.
Bei mir ist die Meldung erst vor wenigen Tagen das erste Mal erschienen. Davor lief alles jahrelang ohne Probleme: Ich lass einige Abos mithilfe des Task-Planers über Nacht automatisch laden. Läuft auf zwei PCs. Beide sind von dem (vermutlich abgelaufenen) Zertifikat betroffen.

Dann warte ich mal auf deine Instruktionen :-)

Danke schonmal!!!

Ursache war, daß die https Kommunikation nicht zustande kam, weil die Java Installation ein self-signed certificate nicht kannte.

Ich hab dann mit einem speziellen Befehl da Java Programm gestartet und daraus das root-Zertifikat und das intermediate Zertifikat ausgelesen und dieses dann mit dem keytool aus JDK bzw JRE in die cacerts importiert.

Findet man mit bissl googlen. Ich kann erst am Abend mehr Details geben.