@MenchenSued Ok. Dann kann das aus dem Quellcode raus, macht es für den Coder einfacher und wenn es als Änderung vermerkt wird kräht auch kein Hahn mehr danach.
Ich benutze dann eben weiterhin die 3.15.1
😉

der 13 Uhr-Lauf wurde wegen dem Release einer neuen Crawler-Version abgebrochen, deshalb gab es die Liste nicht.

@alex ist das beabsichtigt?

Danke dir, werde ich ausprobieren.
Ich habe es mal spasseshalber unter Windows versuchts, und da klappt es reibungslos. Muss ich nicht verstehen…

@DerReisende77, @Nicklas2751 danke für die Erläuterungen!

Beim Paketieren fängt alles in debian/rules mit dem Build-System an. Und die bereits vorhandenen Pakete müssen alles enthalten, damit sie von dem jeweiligen Build-System auch gefunden werden.

Der weitere wichtigste problematische Grund sind die Abhängigkeiten. Aber nicht nur, sondern auch die Abhängigkeiten dieser Abhängigkeiten und, leider, so fort. Klar, dass Projekte sich nicht an die Debian-Einschränkungen halten sollen.

Der bekannte Vorteil von Debian ist der Fakt, dass während des Bauens nichts aus dem Internet heruntergeladen wird. Es kommen nur zuvor gesicherten Quelltext-Archive, die mit einer Prüfsumme versehen sind und bereits vorhandene Debian-Pakete. Viele Pakete können endlich auch reproduzierbar gebaut werden. Damit erlangt man die Überprüfbarkeit, dass das, was gebaut wurde, tatsächlich aus den verwendeten Quelltexten erfolgte. Um das zu erreichen, müssen aber alle Projekte zum Teil aufwändig paketiert werden. Je mehr Abhängigkeiten aktualisiert ein Projekt desto aufwändiger ist es auch bei kleinen eigenen Änderungen das Paket zu aktualisieren. So scheint es offenbar zu sein.

Bei C/C++ Programmen spezifiziert man in der Regel keine genaue Version, wie 1.2.3, sondern es kommt nur darauf an, dass es die Version 1+ ist oder 1.2+. Bei Java wird leider die ganz genaue Version verlangt (und so bei jeder Abhängigkeit?), was den Aufwand unverhältnismäßig in die Höhe treibt. Wie gesagt, kein Projekt muss sich wegen Debian einschränken. Aber gibt es nicht eine Möglichkeit bei maven die Abhängigkeiten weniger strikt zu verlangen oder zumindest in README minimale Anforderungen an alle direkt verwendeten Abhängigkeiten anzugeben?

$ grep -c 'version>[^$]' pom.xml 54

Oh, bei etwa 50 wird es sogar für Entwickler vielleicht nicht so leicht.

@Nicklas2751, danke für die Geschichte über Gradle. Jetzt ist alles klar. Es war also eher Hype und als es ernst zur Sache kam, machte das doch keinen Spaß mehr. Des Weiteren entwickelt sich Gradle schnell weiter (wahrscheinlich ohne Mehrwert für kleine Projekte), so dass man auf die unnötige Wartung verzichten kann.

Ich persönlich bin eher Fan von build from source als Flatpack&Co. Aber für die wenigen anderen Linux-Nutzer wäre das sicherlich eine sehr gute Lösung. Danke, dass ihr daran denkt. Wäre schön, wenn alle Infos/Empfehlungen in z.B. README.Linux zusammengefasst werden könnten.

@Nicklas2751
Danke, der Fehler ist weg. Er scheint sich auch auf meinen zweiten Filter ausgewirkt zu haben, denn nun habe ich bei identischer Filmliste unter “Neu ab 27 Minuten” deutlich weniger Treffer. Scheint aber jetzt alles zu passen. Mal sehen, wie sich die Filter im Alltag machen, es gibt ja im Vergleich zu MV 13.0.6 keinen Schreibschutz mehr und Änderungen am Filter werden automatisch gespeichert.

@DerReisende77 sagte in Beseitigung Issue #290 (50€ Reward):

Wer möchte kann dann gerne für den client und/oder das Programm spenden (Infos dazu findet ihr im About-Dialog des Programms oder hier auf der HP). Ein Reward ist nicht notwendig.

Sorry, @DerReisende77, das musste jetzt doch raus:
Habe gerade zufällig auf eurer HP dieses gefunden!

c9aece16-b671-44e9-92e8-7692dce258f6-grafik.png

In meiner Wahrnehmung ist das auch absolut ok und überhaupt nicht ehrenrührig!

Das war ein Ausschnitt aus dem Log (welches ich erst bemüht hatte, nachdem mir die Wiederholungen im GUI aufgefallen ist) und bei einem 404er ist es eigentlich unsinnig weitere erfolglose Versuche hinter her zuschieben. Immerhin passiert das in 13.5.1 nur noch dann, wenn nach Abschluss der Downloads die fehlerhaften erneut probiert werden. Ansonsten wird bei einem 404er mit dem nächsten Download weitergemacht. Zeigte auch das Log (nicht im Ausschnitt). Das war früher anders. Wobei da die Fehlermeldung auch erst bei endgültigen Abbruch kam.

@Nicklas2751
Danke, die neuen Links sind da. Leider mag mein alter VLC 2.2.8 diese Files nicht und spielt nur die ersten 10 Sekunden ohne Ton. Aber sowohl der aktuelle VLC 3.0.11 als auch ffplay funktionieren tadellos.

@DaDirnbocher sagte: hier lang.

@Fraenki2311: … oder verwende einfach die Version 13.0.6.

@emars sagte in mvnw endet mit [ERROR] Failed to execute goal ... : invalid flag: --release:

Danke, ich hätte erwartet das bei einer zu alten Java Version Probleme mit Javaklassen auftauchen aber nicht ein ordinärer Syntaxfehler.

Hmmm, wer mit Erwartungen “arbeitet”, statt sich mit den Fehlermeldungen auseinanderzusetzen …

Wünsch Dir noch viel Erfolg mit Deinen weiteren Vorhaben.

@styroll sagte in Dateinamenaufbereitung für WDR-Downloads:

Vermutlich hast du die Anpassung nicht überall vorgenommen…

Hallo,
Deine Vermutung war richtig, die Zahl ist weg, danke schön.
Die Unstimmigkeiten bei “Wunderschön” zwischen Thema und Titel und dem Ausrufezeichen sind aber als einzige noch geblieben, sie sind so (teilweise) auch in der Filmliste vorhanden.

Gruß

@Lehmeier sagte in Falsches Betriebssystem ?:

Gibt es ein OpenJDK nicht für 32-Bit ?

Wie gestern geschrieben ist die Frage so für Deine Zwecke zu unscharf formuliert. Eine mE richtigere Fassung der Frage s.u.

Denn, Du benötigst ein OpenJDK

Java 11 oder höher, das auf 32-Bit Windows Version 7 lauffähig ist, und das Java FX mitbringt.

All das zugleich. Und mehrere Punkte dieser Frage sind nicht selbstverständlich zu haben. Bis heute Abend kannte ich z.B. ausschließlich von Zulu OpenJDK überhaupt eine Aussage zur benötigten Windows-Version - und die lautet 32-Bit Windows 8 oder höher. D.h. Zulu ist für Deine Zwecke nicht geeignet.

Ich habe vorhin nochmal gesucht und bin bei Liberica nun doch bzgl. Aussage zur Windows Version fündig geworden.
Aber bei Liberica OpenJDK 11:

https://bell-sw.com/pages/liberica-release-notes-11/

Supported Server and Desktop configurations
Liberica is supported on the following OSes:

[…] Microsoft Windows 2016, Microsoft Windows 2012 R2, Windows 10, Windows 7 (64 bit only)

ist 32-Bit Windows 7 ebenfalls ausgeschlossen.

Ich hab vorhin einfach so noch die Liste für Liberica OpenJDK 13 gelesen, und siehe da:

https://bell-sw.com/pages/liberica-release-notes-13/

Supported Server and Desktop configurations
Liberica is supported on the following OSes:

[…] Microsoft Windows 2019, Windows 2016, Windows 2012 R2, Windows 10, Windows 8, Windows 7 (64 and 32 bit)

Diese Aussage auf der Bellsoft Webseite (die ich weder überprüfen kann noch überprüfen werde!) ist gut für Dich. Denn, Deine o.g. und von mir aus Gründen enger gefasste Frage

Gibt es ein OpenJDK nicht für 32-Bit [Windows 7 mit JavaFX für Java 11 oder höher]?

ist damit mit “laut Hersteller, ja. Und zwar hier: https://bell-sw.com/pages/java-13.0.2/” zu beantworten:

Denke aber bitte nicht, dass Dein Anliegen damit gelöst ist. Die Probleme fangen hier erst an.

Nicht zuletzt dieses:
es gibt für MV 13.3+ von den Helfern im Forum und auch von den Entwicklern keinen Support für 32-Bit Windows.

Mein einziges Angebot an dieser Stelle:
Ich habe einen inoffiziellen Build der 13.5.1 gegen Liberica OpenJDK 13.0.2 erstellt. Möglicherweise funktioniert der -gemäß der o.g. Aussage von Bellsoft auf deren Webseit- eventuell vielleicht unter 32-Bit Windows 7. Ich kann das nicht testen, weil ich kein Windows 7 habe. Also meinerseits ohne jegliche Zusage! Unter 32-Bit Windows 10 startet das Ding zumindest.
Du kannst den Build haben, unter der Vorraussetzung, dass Du akzeptierst: wenn er nicht funktioniert ist es -auch für mich- an dieser Stelle gut. Ach ja, der besagte Build ist bis auf “1x Starten unter 32-Bit Windows 10” praktisch völlig ungetestet.

Meine Empfehlung:
verwende MV 13.0.6 oder installiere Dir ein aktuelles 64-Bit Betriebssystem.

@Lehmeier

Derzeit wird MV 13.4+ mit AdoptOpenJDK ausgeliefert.

bedeutet: MV 13.4+ bringt ein passendes Java selbst mit. AdoptOpenJDK 11u4

@mvtom sagte in Version 13.5.0 stürzt plötzlich ab (Windows 10, 1903):

Beim Start von MediathekView.exe /h startete Mediathekview dann

Ich Nase! Wer lesen kann… da steht es ja eh, schon eingangs: Mit frischem Profil geht alles.
Und ich brauch 3 Posts bis ich dahin komme.

Ich hätte schneller in Richtung MV-Einstellungen denken müssen…
Ich hatte anfangs keine Lösung… habe aber das Problem bewundert

war zugegeben fasziniert von der Fehlermeldung und hab mich von den vielen schön bunten Spielsachen, die einem (Suchmaschine) darauf ausspuckt ablenken lassen von der Java Bugs Datenbank bei ORACLE über die MS Seiten…

@Bonobo Also der Preis ist kein Geheimnis. Das Apple Developer Program kostet 99€/Jahr

ich hab ins Entwickler-Wiki eben eine Seite eingefügt, wie ich einen pull-request erstellt habe. Das hatte ich mir gestern etwas mühsam erarbeiten und zusammensuchen müssen.

Würde ein git-Könner sicher besser erklären als ich - ein solcher war aber grad keiner zur Hand - und noch dazu Willens.
Vielleicht wird sie im Lauf der Zeit besser.

-wie schön, dass das MV Projekt in Eclipse als Maven-Import ohne Fehler kompiliert und gebaut werden kann. Von Maven hab ich gleich noch viel weniger Ahnung als von git… - sofern das möglich ist!