Feature wünsche
-
Ein paar Features die ich gut fände:
- Wenn der Download fehlschlägt wird das Video aus der Abo-Liste genommen, so dass es beim nächsten ausführen der Abos wieder versucht wird zu downloaden
- Metadaten direkt in die MP4 schreiben
- Bandbreitenlimit zeitgesteuert
-
@letzplay sagte in Redesign für Mediathekview 14.0.0:
Ein paar Features die ich gut fände:
- Wenn der Download fehlschlägt wird das Video aus der Abo-Liste genommen, so dass es beim nächsten ausführen der Abos wieder versucht wird zu downloaden
- Metadaten direkt in die MP4 schreiben
- Bandbreitenlimit zeitgesteuert
Punkt 2 haben wir nicht in der Hand, da die MP4 ja nicht von uns, sondern vom Sender kommen und wir die Daten nicht verändern wollen.
-
Bitte immer an TLS denken damit jede Übertragung zum und vom Server sicher geschieht
https://forum.mediathekview.de/topic/1305/tls-zum-update-der-datenbank
Beispielsweise gibt es so einige http links zu webserver, die nicht in der HSTS-Preload liste enthalten sind und dadurch Angriffe auf die Webbrowser eurer Nutzer möglich werden. Beispielsweise sourceforge.net vermisst das preload flag: https://www.ssllabs.com/ssltest/analyze.html?d=sourceforge.net
https://github.com/mediathekview/MediathekView/search?p=1&q=http&unscoped_q=http
-
In letzter Zeit gab es eine Anfrage zur Übersetzung des Programms oder der Anleitung. Je nachdem, wie viel ihr ändern wollt, könnte man die entsprechenden Bereiche gleich so schreiben, dass eine spätere Übersetzung ohne Veränderung des Sourcecodes möglich ist.
Entscheidend für die GUI ist natürlich auch das Zielsystem. Ich als alter Desktop-Fan hätte gern alles in einem Fenster (so wie die Versionen bis 13.0.6) und nicht mit Popups oder abdockbaren Fenstern. Es kann aber sein, dass das auf einem Tablet oder Smartphone unpraktisch ist.
-
Der Ursprüngliche Beitrag ist nicht für Feature Wünsche gedacht!
Ich habe das mal abgespalten.
-
@ximxxomd sagte in Feature wünsche:
Beispielsweise gibt es so einige http links zu webserver, die nicht in der HSTS-Preload liste enthalten sind und dadurch Angriffe auf die Webbrowser eurer Nutzer möglich werden. Beispielsweise sourceforge.net vermisst das preload flag: https://www.ssllabs.com/ssltest/analyze.html?d=sourceforge.net
https://github.com/mediathekview/MediathekView/search?p=1&q=http&unscoped_q=httpWir reichen nur die Links aus der Mediathek weiter. Wenn die Sender nunmal kein HTTPS verwenden können wir da auch nichts für. Alles künstliche von https auf http ändern das wir mal hatten sollte entfernt sein. D.h. wir übergeben die URLs wie sie von den Sendern kommen. Sourceforge nutzen wir übrigens nicht das sind nur noch Überreste vom ehemaligen Hauptentwickler. Und ob unsere Crawler, die auf unserem Server laufen die Mediatheken mit http aufrufen braucht dich nicht zu kümmern zumal das meiste in alt Crawlern steckt die eh abgelöst werden.
-
Ich fände einen Mechanismus super, der fälschlich als neu angezeigte Einträge verhindert. Der Client könnte sich dafür lokal aus jeder neuen Liste jede Video-Url (oder andere eindeutige Eintrags-ID) zusammen mit dem (Erstellungs-)Datum der Liste merken. Gespeichert wäre also zu jeder Url/ID das Datum ihres letzten Auftretens. Außerdem würden nach einem einstellbaren Zeitraum (z.B. einen Monat) nach dem letzten Auftreten die älteren Urls/IDs rausfliegen. Die Url/ID-Datenbank würde also nicht endlos wachsen. Und nun kommt der Clou: Mittels der Url/ID-Datenbank könnten dann alle fälschlich neuen Einträge der aktuellen Liste, in denen solche Urls/IDs bereits in früheren Listen vorkommen sind, verlässlich als nicht neu markiert werden. Im Unterschied zu meinem damaligen Vorschlag würde alles lokal im Client ablaufen, wodurch alle in dem verlinkten Thread beschriebenen Nachteile einer Serverlösung entfallen und nur die unbestreitbar wertvollen Vorteile verbleiben.
-
@herbivore ist ein interessanter Ansatz. Das Problem dabei ist jedoch die Performance mit java . Die meisten Leute hier jammern über die Performance der Anwendung beim Lesen der Liste was durch die DB kommt. Schließlich schreibe ich da die URLs unter anderem rein. Wenn nun noch die abfragen in Bezug auf die filmliste für die neuen Einträge kommen ist das quasi eine Verdoppelung der Laufzeit. Das wird nicht auf viel Gegenliebe treffen… Zumal gerade die Windows User da massiv unter Performance Nachteilen leiden werden.
Evtl ist das ganze aber interessant Mal abseits von Java zu lösen. -
Das nächste Problem ist nur bei Nutzung der URL das Beiträge von unterschiedlichen Sender gefunden werden mit untersch. Titel und Thema. Wenn ich da nur die URL betrachte werden alle als nicht neu markiert obwohl sie durchaus für den Sender neu sein könnten. Das muss aber berücksichtigt werden da ich ja z.B. einen Sender komplett wegfiltern kann weil mich nur der andere interessiert. Dann würde ich dort den “neuen” Beitrag nicht mehr als neu bekommen.
-
@DerReisende77 Freut mich, dass dir mein Vorschlag gefällt. Die Performance bekommen wir bestimmt in den Griff. Die Lösung deines letzten Einwurfs verbirgt sich hinter der erwähnten ID. Ich dachte da z.B. an getIndex aus MServer/src/main/java/mServer/crawler/sender/newsearch/ZdfDatenFilm.java oder eine ähnliche Funktion.
