MediathekView 13.3.0 veröffentlicht
von caschy | 68 Kommentare
Sichern von Videoinhalten diverser Sender: Das macht – vereinfacht gesagt – die kostenlose Software MediathekView. Ein alter Bekannter hier bei uns im Blog, der nun in Version 13.3.0 vorliegt. Das Changelog ist sehr lang, denn es gibt ein paar Änderungen, die man wissen sollte – das erspart Ärger. Java 11 ist nun Minimumvoraussetzung. Die Funktionsfähigkeit mit Java 12 wurde getestet, so die Macher. Damit ist MediathekView nur noch auf Systemen mit 64-Bit lauffähig. Die MediathekView App für macOS ist durch Apple digital signiert um eine vereinfachte Lauffähigkeit auf neueren macOS Versionen zu garantieren. Man soll dort keine Dateien innerhalb der App verändern oder ersetzen, für die nächste Version ist auch ein Update-Mechanismus für FFMPEG geplant.
Alternative für den flotten Download von Videos ohne spezielle Software: mediathekviewweb
- Danke Daniel
Wird geladen ...
„Java 11 ist nun Minimumvoraussetzung.“
Das ist nicht wirklich logisch. Java 11 wird nicht mehr explizit als System-weites Runtime Environment zur Installation durch die Anwender unter Windows angeboten, sondern sollten die notwendigen Elemente des Runtime Environment mit in die Anwendung gepackt werden. Die Voraussetzung müssten dann also durch die Macher von MediathekView selbst erfüllt werden und nicht durch die Nutzer. Alternativ müssten die Nutzer das JDK11 installieren und auf die darin enthaltene JRE referenzieren, was nicht wirklich Anwender-freundlich ist.
Mhm, immer noch das Look’n’Feel vom letzten Jahrtausend… aber für mich persönlich viel schlimmer: Seit August ist MediathekView von ARTE gesperrt worden, sprich es kommen erstmal keine neuen ARTE-Inhalte mehr dazu.
Da bleib ich unter Windows 10 doch lieber bei „Meine Mediatheken“ (https://www.meinemediatheken.de/)
Ja, ich verwende seit dem Ende des Supports für Java 8 auch „Meine Mediatheken“ und werde ich auch bei bleiben, denn die Macher von MediathekView erwarten tatsächlich, dass man entweder das JDK oder das JRE von AdoptOpenJDK installiert. Sehe ich nicht wirklich ein. Es ist Java vorgesehen, dass die Elemente der JRE die die App braucht, von den Entwicklern mit in die App integriert werden und nicht, dass Anwender eine JRE extra installieren. Wenn die gegen Java rebellieren wollen, sollen die das ohne mich machen.
„Meine Mediatheken“ hat seinen eigenen Index und nichts mit der Filmliste von MediathekView zu tun. Daher werden dort auch zdf_neo und One separat angezeigt und nicht jeder Inhalt der Ard oder ZDF Mediathek in einen Topf geschmissen.
Soll heißen: Arte geht da immer noch.
Sieht tatsächlich hübscher aus. Hat aber viel weniger Funktionen. Der Zeitfilter funktioniert nicht in der chronologischen Ansicht, jeder Download geht in den gleichen Ordner und das nervigste: keine Anzeige von Film-Infos.
Wenn man viele Filme herunter lädt und nicht nur gelegentlich ein einzelnes Filmchen, ist MediathekView viel funktioneller. Sobald die arte Sperre geklärt ist, gehe ich wieder zurück. Bis dahin ist die „meine Meditheken“ App praktische als die anderen Tools die es so gibt.
Die chronologische Ansicht ist neu, kann ja noch kommen…
Die Film-Infos werden ebenso wie die Senderlogos laut App aus rechtlichen Gründen nicht angezeigt, die wollen sich halt nicht unnötig Probleme schaffen. Gerade in Zeiten des Leistungsschutzrechts wo schon ein paar Sätze als „Vorschau“ Anlass genug für eine Anzeige sein können…
Ansonsten finde ich gerade die Schlichtheit schön. MV ist überladen mit Funktionen für Power-User… aber Geschmäcker sind halt verschieden.
Aber letztlich freut mich, dass es Auswahl gibt. Heute geht Arte nicht MV, nehm ich „Meine Mediatheken“, morgen ist es vielleicht andersrum. 🙂
Ich vermisse bei Meine Mediatheken keine Funktionen. Ich werde in aller Regel immer außerhalb der Mediatheken auf die Inhalte aufmerksam, die ich runter laden will. Da starte ich das Programm nur kurz, gebe den Titel der Sendung ein, lade sie runter und dann bin ich mit dem Programm schon wieder fertig, bis ich die Sendung wieder abspiele. Aber gut, ich bin auch ein Informatik-Nerd, der es gewohnt ist auch schon mal auf ner Konsole unter Linux zu arbeiten. Aber wie Sarina schon richtig angemerkt hat, ist die App ja noch in Entwicklung und wer weiß was noch kommt.
Hmmm, so wie ich das sehe, gibt es da aber keinen HD-Download. :-/ Beispiel „Die Anstalt“ vom 16. Juli 2019:
– MediathekView: 1022 MB in „höchster Qualität“ (1280x720px)
– Meine Mediatheken: 438 MB in „hoher Qualität“in 852x480px^
LG Markus
Kann man nicht pauschal sagen. Gibt durchaus Sender und Sendungen in HD. ARTE beispielsweise, da hat „The Assasin“ vom 05.08 über 2 Gb.
ZDF war früher eigentlich auch mal HD verfügbar. Würde ich ggf. einfach dem Entwickler melden…
Nanu, mein Kommentar kam irgendwie nicht an…?
Dann noch ein Versuch: Es gibt durchaus Sendungen und Sender in HD. „The Assasin“ auf ARTE vom 05.08 hat z.B. über 2 Gb.
ZDF war früher ebenfalls mal in HD verfügbar, ich würde an Deiner Stelle einfach den Entwickler anschreiben…
Danke für den Hinweis. Das ist eindeutig ein Bug. Habe den Entwickler auch gleich mal darauf hingewiesen.
Danke für Eure Hinweise und an Benjamin für das Verfassen des Bugreports 🙂 Dann behalte ich die App mal im Auge 🙂
LG Markus
Der Entwickler hat gleich reagiert. Er war die letzten beiden Wochen im Urlaub, aber ist jetzt wieder dran und wird sich das gleich mal anschauen.
Der Bug ist jetzt gefixt.
Und das ist dann auch gleich das KO-Kriterium: läuft nur unter Windows und somit für mich keine Alternative.
Java 11 und 12? Wenn ich auf die Java-Site gehe, wird mit Java 8 Update 221 als aktuelle Version angezeigt. Was meinen die denn damit?
Anscheinend hat Oracle die JRE entfernt und man muss jetzt das ganze JDK (Entwicklerpaket) runter laden.
Die besser Alternative: AdoptOpenJDK. Dort kannst du eine JRE in Version 11 runter laden.
Ok, aber das JDK kann ja auch nicht schaden. Ich habe mir somit gerade das JDK 12.0.2 installiert und Java 1.8.221 gelöscht. Nun bekomme ich mit dem neuen MediathekView beim Start die Meldung
———————-
This application requires a Java Runtime Environment 1.8.0
———————-
Äh, was? Nun bin ich verwirrt.
Diese Fehlermeldung bekomme ich mit der alten MV-Version. Die neue sagte bei mir zuerst „keine Java Version gefunden“. Ich habe dann die alte JRE 8 deinstalliert und nochmals eine Reparaturinstallation des OpenJDK gemacht. Jetzt geht es bei mir. Vermutlich ist die Path-Variable noch nicht richtig gesetzt bzw. die alte Java-Version noch registriert. Schau mal hier: https://mediathekview.de/faq/#mediathekview-startet-nicht
Danke, hab die Java Path-Variablen manuell angepasst (auf den /bin-Ordner), den MediathekView-Ordner nochmal gelöscht, die neue Version hineinkopiert und den Rechner neu gestartet, nun geht’s 😀
Habe extra nochmal bei den Entwicklern von MediathekView nachgefragt und die erwarten wirklich, dass man entweder das JDK oder das JRE von AdoptOpenJDK installiert, damit man ihr Programm verwenden kann, obwohl das nicht dem entspricht was mit Java 11 vorgesehen ist. Der TV-Browser läuft zum Beispiel auch einwandfrei mit Java 11, ohne dass ich eine JRE installiert habe. Echt schade diese Entscheidung.
„obwohl das nicht dem entspricht was mit Java 11 vorgesehen ist“
In wie fern?
Übrigens: Du musst nicht das ganze JDK installieren, sondern kannst den Punkt „Sourcen“ weg lassen.
Insofern, als dass es eben nicht mehr vorgesehen ist, dass die Endanwender sich eine JRE installieren, weshalb diese für Clients eigentlich auch nicht mehr explizit angeboten wird. Vom Standard ist eigentlich vorgesehen, dass die Apps die Java nutzen, die Teile der JRE, die sie zur Ausführung brauchen selber mitbringen. Das läuft beim TV-Browser super und der mtplayer macht das auch so.
Wieso quält man sich eigentlich immer noch mit dem Javazeugs? Gibt doch viele Webtoools dsbei auch Vavideo, falls man Abos braucht…
Ich quäle mich ja nicht mehr damit „Meine Mediatheken“ ist eine UWP-App die mit Java gar nichts zu tun hat und beim TV-Browser ist es halt mit in der App integriert, sodass ich mich da auch nicht drum kümmern muss. Das könnten die Leute von MediathekView auch machen, aber haben wohl keine Lust ihren Build-Prozess anzupassen.
Wenn man die Teile integriert muss man aber Lizenzgebühren an Oracle bezahlen, als kleines OpenSource-Projekt, was schonmal Probleme hatte, verstehe ich den Schritt.
Das stimmt so pauschal nicht. Das muss man nur, wenn man ein paar bestimmte exklusiv von Oracle zur Verfügung gestellte Klassen nutzt. Wenn man aber von vorn herein seine App nur auf Basis der Java SE Plattform baut, welche unter eine GPL läuft, dann hat man auch nichts mit drin für was man Lizenzgebühren zahlen müsste, schon gar nicht als kostenlos OpenSource-Projekt.
Wenn MediathekView das JDK bzw. die JRE mitliefert, sind sie auch dafür verantwortlich, jedes Sicherheitsupdate für JDK/JRE durch ein Update von MediathekView bereitzustellen. Den Schuh wollen sie sich vermutlich nicht anziehen.
Genauso sind sie verantwortlich jedes Sicherheitsupdate für JavaFX durch ein Update von MediathekView bereitzustellen. Die müssen bei Updates sowieso immer gegen die neue Version testen, ob alles noch rund läuft. Da ist es, wenn man es ordentlich konfiguriert keine große Arbeit mal eben nen Build-Prozess anzuschmeißen der die neue Version rein lädt und auf Github schiebt, wo sie ja als OpenSource-Projekt auch kostenlos hosten können. Diese Verantwortung mal eben auf die Endanwender abzuschieben und diese sich eine Entwicklungsumgebung installieren oder eine angepasste JRE zurecht frickeln zu lassen, erachte ich da als wesentlich schlechter.
MediathekView wurde ja ursprünglich von Xaver W. (wenn ich den Namen noch richtig in Erinnerung habe) alleine entwickelt. Ihm wuchs irgendwann das Projekt über den Kopf, speziell der Support neben der eigentlichen Entwicklung, und hatte deshalb sein Baby der Community zur Weiterentwicklung überlassen, aber irgendwie konnte er es dann doch nicht lassen und hat deshalb vor ca. 2 Jahren ein neues Tool entwickelt:
mtplayer
https://www.p2tools.de/mtplayer/
Es benutzt natürlich die gleichen Serverdaten, aber die Oberfläche seines neuen Tools ist in meinen Augen viel aufgeräumter. Auch fühlt es sich schneller an als MediathekView. Den mtplayer gibt es in den Geschmacksrichtungen mit und ohne Java. 😉 Die aktuelle Version 7 braucht Java 11, die Versionen vorher kamen auch mit Java 8 und größer aus.
Wer oft Filme aus Mediatheken runterlädt, sollte sich das Tool auf alle Fälle mal anschauen.
Danke für den Hinweis. Ich dachte Xaver ist noch immer im MV Team dabei. Zumindest ganz am Anfang klang es nach einer gemeinsamen Weiterarbeit – danach habe ich es nicht mehr verfolgt.
Sieht gut aus und ist mit Java. 🙂
Hm, wollen die wirklich, dass man das Tool nicht mehr nutzt? Java 11 zu installieren bekommt man ja noch hin, aber den Pfad zurechtbiegen zu müssen, ist schon eine Zumutung. Schade.
„aber den Pfad zurechtbiegen zu müssen, ist schon eine Zumutung“
Ich habe die JRE des OpenJDK installiert und musste keinen Pfad zurechtbiegen. Das Setup trägt die JRE ganz normal in die PATH-Variable ein. Danach funktioniert es wie bisher.
Alles ausprobiert. Ohne händisches Anpassen geht bei mir gar nichts, Schade. Aber hat sich ja aufgrund von Befindlichkeiten leider ohnehin erledigt, das Projekt. Auch schade.
Also mir reicht die Website mediathekviewweb.de vollkommen, nutze die sogar im TV Browser.
Einen Mehrwert hätte eine App wo man den Stream per DLNA an den Fernseher schicken könnte.
Kann man bei „Meine Mediatheken“ gegen einen kleinen Obolus dauerhaft freischalten. Streamt auch an Chromecast und FireTV
„Meine Mediatheken“ kann das… Streaming an Chromecast, FireTV und SmartTV (also DLNA/UPnP).
Aber es gibt keine App für Android, oder bin ich blind?
Wenn ich extra dafür den Computer einschalten muss bin ich mit dem TV Browser schneller.
Nein, Du bist nicht blind… von Android hast Du aber ja auch bis eben noch nicht gesprochen. 😉
Falls Du eine Xbox hast, dafür gibts ebenfalls „Meine Mediatheken“. Darüber wärst Du dann ja auch ohne Streaming schon am Fernseher.
Okay, ich bin davon ausgegangen dass man bei App von Android oder Apple ausgeht.
Nein, eine XBox habe ich nicht.
Nein, hier geht es nur um Apps für den PC.
Nachdem „Meine Mediatheken“ aus dem Microsoft Store kommt und sich ebenfalls App schimpft, habe ich jetzt nicht an Smartphones gedacht. Ging ja bislang in der Diskussion auch noch gar nicht darum.
Aber hätten wir dann ja jetzt geklärt. 😉
mediathekviewweb.de im TV-Browser? Das klingt nach einer reizvollen Lösung. Hast Du da eine Anleitung fürs Einbinden?
Einbinden? Ich starte den Browser, die Seite habe ich als Favorit gespeichert, suche nach der Sendung, gehe dann rechts auf das Video Symbol und bei hoher Qualität auf Abspielen. Dann noch das Fenster auf Vollbild, das wars. Klappt mit dem Firefox in meinem Panasonic wunderbar, und mit der Panasonic App auf dem Smartphone ist auch Mauszeiger bewegen und die Texteingabe kein Geduldsspiel.
Achso, dann ging es also gar nicht um den TV-Browser.
Oh Mann, ich wußte gar nicht dass es eine App gibt die so heisst.
Aber sie klingt interessant, danke dafür 😉
Schau es dir mal an. Für meinen Geschmack fehlen mir zu viele Funktionen gegenüber MediathekView.
Da es diverse Tools gibt, die in Java geschrieben sind (z.B. zur GPS-Datenverarbeitung), habe ich ohnehin Java installiert. Seit man Java nicht mehr im Browser nutzen muss, ist das auch sicherheitstechnisch kein Problem mehr. Und außer einer einmaligen Installation sehe ich persönlich keinen Aufwand.
Mit einer einmaligen Installation ist es ja nicht wirklich getan. Man muss schon sehen, dass man selber regelmäßig nach Updates schaut… Sollte ich mal wieder auf der JVM entwickeln, werde ich das wohl auch wieder tun. Aber aktuell sehe ich es als völlig unverhältnismäßig an mir eine JRE zu installieren nur um MediathekView laufen zu lassen. Alle anderen Java-Apps die ich nutze, haben ihre JRE mit an Board, so wie es halt auch seit Java 9 vorgesehen ist. Java 8 war die letzte Version für die explizit eine allgemeine JRE angeboten wurde.
Genau umgedreht sollte es sein! Einmal Java (JRE) installieren, dieses aktuell halten, fertig! Dann können alle auf Java basierten Programme darauf „zugreifen“ und gut ist. Und sollte in der JRE (sicherheitskritische) Fehler gefunden und gefixt worden sein, dann wurde diese eben upgedatet. Also so wie es bis Java 8 war.
Und heute wird mit jedem Programm ein eigenes Java mitgeliefert. Nicht nur, dass man jetzt Java unnötigerweise mehrfach auf dem Rechner hat, sondern man kann als User auch nicht mehr wissen, ob diese verschiedenen Java-Versionen auch auf dem aktuellen sicheren Stand sind. Man muss den Programmhersteller vertrauen. Für mich ist das der falsche Weg und schreckt mich immer mehr ab, java-basierte Programme einzusetzen. Ich benutze zunehmend Alternativen und schaue, komplett davon wegzukommen.
Nein, so sollte es eben nicht mehr sein. Es ist ja eben nicht damit getan mal eben nur eine JRE zu installieren. Der Release-Zyklus von Java wurde verkürzt. Es gibt jetzt wesentlich häufiger neue Hauptversionen. Da setzt die ein App noch auf Java 11 LTS, während dann die nächste auf 12 setzt und die übernächste setzt demnächst schon auf 13. Und da soll der einfache Endanwender den Überblick behalten und die Konfigurationen sauber halten?
Davon mal ab wird die JRE jetzt nicht mehr komplett dazu gepackt, sondern an die jeweilige App angepasst. Bei der Standard-JRE läuft immer eine JVM die alle nur irgendwie im Java-Standard möglichen Befehlssätze unterstützt. Wenn man es jetzt mit dem neuen Java richtig macht, läuft da jetzt jeweils nur noch eine auf die Notwendigkeiten der App beschränkte Version der JRE, die so auch zur Laufzeit das System weniger belastet.
Und last but not least: Wenn Du allen Ernstes deswegen Programmen weniger vertraust, dann benutze am besten gar keine Programme mehr. Wirklich jedes größere Programm bindet irgendwelche Drittpakete ein, wo die Entwickler regelmäßig auf Updates prüfen und diese neu mit einbinden und eine entsprechend neue Version rausgeben müssen. So ist z.B. auch JavaFX nicht mehr Teil des Java-Standards und damit auch nicht mehr im JDK enthalten, sondern wurde in eine extern gepflegte Bibliothek ausgegliedert. MediathekView verwendet JavaFX für die Benutzeroberfläche und muss diese jetzt auch immer gesondert einbinden und Updates davon regelmäßig einpflegen.
Das Problem wäre nicht, wenn die Versionen zueinander kompatibel wären und auch als „FullSet“ ausgeliefert werden würden. Dass jenes und dieses nicht enthalten ist und und und zeigt doch wie kaputt das Konstrukt Java ist!
Auf das eigentliche Thema Sicherheit bist Du ja absichtlich nicht eingegangen und dein letzter Absatz zeigt, dass du es nur verwässern willst. Und dass eben nicht regelmäßig auf Updates geprüft wird, hat die Vergangenheit ja gezeigt. Die heutigen Programmierer, wie sagte der neulich ein Prof am Stammtisch so schön, sind in der Regel Weltmeister im Kopieren und schnell implementieren, aber Sicherheit spielt dabei keine Rolle.
Aber wie schon gesagt, ich gehe weg von Java eben aus diversen Gründen, eine davon ist der Sicherheitsaspekt. Das kannst Du auch nicht schön reden und mit anderen „richtigen“ Programmen vergleichen oder versuchen zu relativieren.
Du hast nicht wirklich viel Ahnung von Software-Enwicklung, oder? Bei den wenigsten Programmiersprachen sind die Major-Versionen zu 100% kompatibel zueinander. Es werden immer mal wieder bestimmte Bibliotheken ersetzt, häufig eben aus Sicherheitsgründen und das geht nicht immer komplett abwärtskompatibel. Manche Bibliotheken werden komplett gelöscht oder extern ausgegliedert, weil die Pflege und das Mitschleppen nicht mehr angemessen ist in Relation zur Häufigkeit der Nutzung oder weil die Bibliothek zu kompliziert geworden ist, als dass sie noch Teil des Standard sein kann. Und es kommen dann natürlich auch immer wieder neue Bibliotheken dazu. Und das ist nicht nur bei Java so ist, sondern auch bei C#, Python und noch vielen Programmiersprachen mehr. Wenn die Laufzeitumgebungen immer zu 100% abwärtskompatibel blieben, würden sie nicht nur immer fetter und fetter, sondern würden eben auch immer wieder Sicherheitslücken mit sich schleppen. Das einzige was hier also kaputt ist, ist deine Erwartungshaltung, weil sie schlicht unrealistisch ist.
Ja, ich bin nicht direkt auf das Thema Sicherheit eingegangen, aber indirekt schon und verwässert habe ich da gar nichts. Wenn man den Anwendern es überlässt die ganzen Laufzeitumgebungen aktuell zu halten, ist es doch viel wahrscheinlicher, dass die auf einer unsicheren Version hängen bleiben, als wenn der Entwickler eines Programms, der sich viel intensiver und bewusster mit den Rahmenbedingungen seines Programms auseinandersetzt und da mehr drauf achtet wovon es abhängig ist, immer die neueste Version einbaut und den Anwender beim Starten mit einem Popup oder dergleichen auf eine neue Version hinweist, damit der sich diese runter lädt. Dass es bei etlichen Projekten leider nicht so gut läuft, ist natürlich wieder eine andere Geschichte, aber Otto-Normalnutzer achtet da noch weniger drauf bzw. weiß auch häufig gar nicht worauf genau er da eigentlich achten muss, wenn nicht irgendwo ein Hinweis kommt, dass er was neu installieren muss. Deswegen machen Firefox und Chrome als wichtige zentrale Schnittstellen der alltäglichen PC-Nutzung das auch automatisch im Hintergrund und haben die Smartphone-Betriebssysteme einen zentralen Store integriert, damit der sich um die Updates so weit wie möglich kümmert, der ja nun auch bei Windows 10 immer mehr Gewicht verliehen bekommt, während so ziemlich alle modernene Spiele ja auch inzwischen über irgendeinen Storelauncher laufen, der sich selber aktualisiert und alle über ihn installierten Programme aktuell hält.
Wie gesagt: Den vermeintlich schlechten Sicherheitsaspekt den Du hier so explizit Java ankreidest, beinhalten sehr viele Programmiersprachen, insbesondere so ziemlich alle Sprachen die in einer JustInTime-Laufzeitumgebung laufen. Du solltest also weder Python, noch JavaScript, noch C#, noch Kotlin oder sonst irgendwas modernes nutzen. Am besten du nutzt gar kein Gerät mehr das irgendwie online geht, denn auch alle Betriebssysteme binden irgendwo Pakete von dritten ein und haben so nach deinem Dafürhalten inakzeptable Sicherheitsprobleme…
Nur 40 Jahre IT und unzählige „Programmiersprachen“, aber darum geht es nicht. Du scheinst aber nicht die Sicht aus dem Blickwinkel der User und der Sicherheit zu verstehen!
Diesen unsäglichen Bibliothekemüll und den daraus resultierenden Folgen hätte man auch alles ganz anders machen können. In allen „Sprachen“! Aber das will ich erst gar nicht diskutieren. Bei Java hat sich Sun bzw. Oracle für diesen in meinen Augen falschen Weg entschieden, den vor allem Enduser auszubaden haben!
Und nein, eine JRE die sich selber meldet, wenn ein Update ansteht ist/war immer besser, als das, was die unzähligen „Programmentwickler“ jetzt verbrechen! Es hat tadellos funktioniert! Software an einer Stelle sicher gepflegt, das sollte das Ziel sein, alles andere ist und bleibt Murks. Ob in Java oder in allen anderen „modernen“ Programmiersprachen! Und wenn nur ein „Programm“ keine Updates liefert, haste schon ein Problem. Und noch viel schlimmer, Du als Enduser kannst es selber auf einfachem Wege erst gar nicht ermitteln!
Wie schriebst Du so schön:
„Dass es bei etlichen Projekten leider nicht so gut läuft, ist natürlich wieder eine andere Geschichte,..“ – nein, genau das ist das Hauptproblem! Und wie github (oder war es source forge) in einer Studie Anfang des Jahres gezeigt hat, sind ~80% aller benutzen Bibliotheken in Projekten veraltet! Und die Herren Entwickler bleiben eben lieber bei alten Libs, weil das Testen und eine mögliche Inkompatibilität eben zu schnell zu viel Aufwand führt. Ob Unwissenheit, Faulheit, Zeitmangel, …. spielt keine Rolle!
Und Java ist nun mal weit verbreitet. In meinen Augen ist/wird nach Flash und PDF nun Java das neue Einfallstor. Und genau aus diesem Grund vermeide I C H wo es geht Java und ersetze es durch sichere Alternativen! Damit klinke ich mich jetzt auch hier aus, denn das kann jeder handhaben wie er will und Du wirst mich auch nicht überzeugen! Ich kenne sämtliche Argumente.
Ich will Dich gar nicht überzeugen. Ich mag ja selbst Java nicht mal sonders, obwohl ich damit ursprünglich mal angefangen habe zu programmieren. Ich wollte nur einigen Deiner doch recht unrealistischen Aussagen etwas entgegen setzen. „Nur 40 Jahre IT und unzählige „Programmiersprachen““ bist dann wohl im gestern hängen geblieben. Wir leben nicht mehr in der Zeit wo C und Lisp oder dergleichen den Ton angegeben haben. Wir haben auch nicht mehr nur wenige Mainframes und PCs bei Profis wo Programme laufen. Die Ansprüche haben sich geändert und die Entwicklung ist wesentlich schlechter geworden. Ich sage nicht, dass alles toll läuft. Ja, das mit den vielen ungepflegten Programmen ist Mist. Aber so wie Du es beschreibst kann es halt auch nicht funktionieren. Java war zu den schnelleren Releasezyklen gezwungen, weil es immer mehr hinterher hing und immer mehr Leute zu C#, Kotlin oder sonst einer Alternative greifen. Wenn man mit Java nicht diesen Schritt gegangen wären, wäre es noch viel eher vom Fenster verschwunden und die JVM wäre irgendwann das einzige was noch nennenswert an diese Sprache erinnert, während sie von anderen Sprachen dominiert wird.
Ich wollte eigentlich schreiben, dass die Entwicklung schneller geworden ist. Ich sollte mich an solchen Diskussionen nicht beteiligen, wenn ich eigentlich viel zu Müde bin mich mit solch Gefasel aus dem Gestern auseinander zu setzen.
Das ist ja echt blöd. Habe ach meinem neuen Rechner extra kein Java instaliert und jetzt soll ich das, nur um das ansonsten gute Programm benutzen zu können? Nee, dann verwende ich jetzt erst mal die Altenativen. So oft benutze ich pers. das Tool nicht. Finde ich aber schade., Ging ja bisher auch…
es geht auch portabel!
mit der openjdk hat es nicht funktioniert, aber mit der entpackten jdk-12.0.2_windows-x64_bin.zip von Oracle schon.
Als Startparameter dann
„%homepath%\Downloads\Mediathekview\Java\bin\java“ -Xms128M -Xmx1G -jar „%homepath%\Downloads\MediathekView\MediathekView.jar“ %public%\Videos\.mediathek3
In den Ordner „\Downloads\Mediathekview\Java\bin\java“ habe ich alle entpackten Ordner und Dateien von JAVA platziert, die -XMS und XMG Parameter weisen Speicher zu. Ggf. muss die Aufrufzeile noch entsprechend angepasst werden. Bei mir funzt es jedenfalls. Evtl. kann ich bei Anfrage noch weiterhelfen
Wenn man sich die Kommentare im Forum von MediathekView ansieht, gibts da ganz viel Probleme mit der neuen Version: https://forum.mediathekview.de/category/4/fragen-hilfe-kritik
Scheint nur was für Bastler zu sein, keine einfache out-of-the-box Installation für normale 0815-Anwender.
Ich hab die 13.3.0 heute morgen installiert und der einzige Aufwand war, das Java 8 und OpenJFX wieder wegzubekommen. Ich habe SuSE Tumbleweed installiert und das liefert aktuell ein OpenJDK 12 mit (Oracle Java dürfen sie wohl nicht mehr anbieten, kann man aber natürlich im privaten Umfeld manuell selbst installieren). Die neue MediathekView lief zumindest beim 1. Test ohne Probleme und vor allem deutlich schneller.
Ich sagte ja nicht, dass es generell nicht funktioniert, nur dass es nichts für den Otto-Normal-Anwender zu sein scheint (bei denen mit Blick ins Forum es wohl doch zu zahlreichen Probleme kommt).
Denn der Standard-Nutzer hat wahrscheinlich weder Ahnung was Suse Tubleweed überhaupt sein könnte noch weiß er ob er zufällig ein JDK vorinstalliert hat. Das ist schon eher ein advanced user. 😉 Ein einfacher DAU will einen Installer ausführen und hofft dass es dann sofort und immer klappt. In der Linux-Ecke gibts per se schon weniger DAUs, macht es für den großen Rest der DAUs aber nicht einfacher…
Da gab’s doch mal Java-Compiler. Kenne ich von ProjectX (Demuxer für mpg) und man konnte gegen Spende über Oozoon.de eine kompilierte Version erhalten, die keinerlei Java zusätzlich brauchte. Wenn das für MV möglich wäre??
Da gab’s doch mal Java-Compiler. Kenne ich von ProjectX (Demuxer für mpg) und man konnte gegen Spende über Oozoon.de eine kompilierte Version erhalten, die keinerlei Java zusätzlich brauchte. Wenn das für MV möglich wäre??
Der Compiler hat auch nichts anderes gemacht, als eine JRE mit dazu zu packen, wie es auch jetzt mit Java 11 vorgesehen ist. Es wäre also für MediathekView nicht nur möglich, sondern eigentlich explizit von Java so vorgesehen, dass sie die JRE mit rein packen. Sie wollen es bloß offensichtlich einfach nicht, sondern überlassen es völlig widersinnig den Anwendern sich darum zu kümmern.
Das war’s dann wohl mit MediathekView :-(. Der Hauptentwickler hat im Forum das Ende des Windows- und Linux-Supports angekündigt:
„DerReisende77 Entwickler vor 13 Stunden
So meine liebe „Community“,
Wie ich bereits in einem anderen Thread angedeutet habe kommt hiermit nun auch höchst offiziell meine Ankündigung bzw. Abkündigung:
Mit sofortiger Wirkung Stelle ICH den Support und die Entwicklung von MediathekView für Windows und Linux ein.
Dass was ihr in der Vergangenheit erfolgreich mit Xaver geschafft habt, habt ihr nun auch bei mir erreicht. Ich habe wirklich keine Lust mehr, meine Freizeit zu opfern, den Client am laufen zu halten und Features zu implementieren nur um festzustellen dass der ganze Scheiss nicht zuverlässig auf allen anderen Betriebssystemen abseits meines macOS läuft. Weiterhin habe ich auch überhaupt keine Lust mehr meine Freizeit unter Windows oder Linux zu verbringen um Fehler auszumerzen die eigentlich keine sind und nur darauf zurück zu führen sind dass Java entgegen seiner ursprünglichen Philosophie doch auf jeder Plattform anders läuft. Und irgendein User eine exotische Bildschirmkombination unter Windows, asbach uralte Treiber verwendet oder sonstiges macht. Was man natürlich auch alles daheim super testen kann indem ich auf den reichen Fundus meiner 200000 Testsysteme zurückgreife, die ich nur für euch angeschafft habe.
Ähnlich ist es mit Linux. Es macht total viel Spaß herauszufinden dass der original NVIDIA-Treiber problemlos funktioniert, das open-source pendant jedoch genau einen Fehler hat der die Arbeit mit MediathekView beeinträchtigt. Aber ist ja open-source und damit voll toll und alles viel viel besser. Oder oracle java unter linux etwas anders (meist besser) als das openjdk funktioniert. Ist aber auch egal, das eine hat sich ja für die Vielzahl der Nutzer erledigt.[…]“
Quelle: https://forum.mediathekview.de/topic/2650/roadmap-f%C3%BCr-mediathekview-oder-tsch%C3%BCss-windows-und-linux
Ist vielleicht besser so. Die neue Entwickler-Community wirkte ja von Anfang an mit diesem Projekt ziemlich überfordert.
Xavers MTPlayer ist eine gute Alternative. Danke für die Tipps.
Tolle Hinweise hier auf Alternativen und Hilfestellungen.
Klasse Blog.