Feature Sammlung MediathekView 14.0.0



  • Verehrtes Entwicklerteam,
    dann mache ich hier mal einen Anfang mit Vorschlägen zur Weiterentwicklung von MV (von realistisch bis erträumt).

    Habe ein paar Anregungen zusammengetragen, die funktioneller Natur sind und sich eher nicht auf die Oberfläche beziehen.

    • In ABOs im Feld ‘Thema’ RegEx (#:) erlauben. Zur Zeit wird das meines Erachtens nur als Text interpretiert, anders als in den anderen Textfeldern. Würde bei manchen ABO-Definitionen gute Dienste leisten.

    • Kurze Mitteilungen mit History in MV über größere Änderungen im Hintergrund: z.B. Crawleränderungen, die teilweise eine deutliche Änderung von ABOs nötig machen (prominente Beispiele aus letzter Zeit: ARTE.DE, ZDF, DW, SRF). Selbst im Forum wird man nur fündig, wenn ein User irgendeine Auffälligkeit gemeldet hat. Auch gut für User, die nicht regelmäßig ins Forum schauen. Man sollte dort aber trotzdem für weitere Infos zum Forum verlinken.

    • Apropo Crawler. Könnte(n) der oder die Crawler sich nicht auch ein wenig selber überwachen, wenn es massive Abweichungen an den Suchergebnissen eines Senders gibt und den Administratoren mitteilen, dass sich was Grundlegendes auf der Senderseite getan hat. Kriterien gibt es ja wahrscheinlich zu Hauf, die man auswerten könnte.

    • Hervorhebung des Alters der Filmliste, wenn diese älter als z.B. etwas mehr als 2 (oder 3) Stunden ist, je nach Rythmus der Aktualisierungen. Da sieht man dann auch gleich (unter anderem beim Programmstart), ob irgendwas mit dem (automatischen) Laden der Filmliste nicht geklappt hat. Alternativ oder zusätzlich könnte MV auch in regelmäßigen Zeitabständen selber nachschauen, ob es eine neue Filmliste gibt und das dann dezent signalisieren, etwa über eine farbliche Markierung in dem Bereich der Altersanzeige der Filmliste oder einen veränderten ‘neue Filmliste laden’-Button oder …

    • Weiterer Filter, besonders auch für die ABOs, wenn die anderen Filter nicht greifen: ‘Zeitbereich’ für die ‘Zeit’ einer Sendung.
      Vielleicht erledigt sich das auch, wenn man zusätzlich in der URL suchen kann (optional mit RegEx versteht sich), wie schon von anderer Seite im Forum vorgeschlagen wurde.

    • Manche Unter-Fenster behalten keine Infos über ihre letze Position und Größe. Z.B.: ABO, Beenden (unabhängig vom Status des Hauptfensters oder nur bei minimiertem Hauptfenster), Blacklist, …

    • Option zum Abschalten der Ersetzungstabelle (oder zweite Ersetzungstabelle) für die Suchvorgabe in der MV-Mediensammlung, wenn man aus der Liste der Filme heraus die Suche aufruft. Ich habe das Problem, dass bei meinen Aufzeichnungen alle Leerzeichen durch Underscores ersetzt werden (Ersetzungstabelle), die Dateien nach einer strukturierten Umbenennung (Renamer) aber Dateinamen ohne Underscores sind, so wie ich sie dann auch archivieren will. So muss ich für die Suche immer alle Underscores durch Leerzeichen ersetzen, was auf die Dauer eher lästig ist. Außerdem wäre für die Suche auch schön, wenn sie einzelne Wörter unabhängig von ihrer Reihenfolge finden würde (als Vorbild könnte hier ‘Everything’ fungieren). Was das flexiblere Suchen angeht, gilt das auch für die Textfelder im Filme-Filter.

    • Meldung ins Forum aus MV heraus (für registrierte User). Da könnte man automatisch relevante Daten wie OS, Java-Version, MV-Version, Datum+Uhrzeit, Datum+Uhrzeit der Filmliste oder auch eine Protokolldatei mitschicken, was die dauernden Hinweise und Nachfragen im Forum überflüssig machen würde. Gleichzeitig könnte man durch Abfragen/Auswahlfelder noch besser strukturieren, um was es gerade geht. Bei einer Meldung zu einem fehlenden Beitrag müsste man dann ein Feld für einen Sender und Datum+Uhrzeit auswählen. Man könnte sich dann auch eine automatische Suche im Forum vorstellen, ob das schon mal gemeldet wurde. Das setzt allerdings die sichere Speicherung der Zugangsdaten voraus, was ein nicht trivilales Problem ist, besonders wenn das auf allen unterstützten Plattformen funktionieren soll. Weiterhin müsste das Forum ebenso weiter strukturiert werden; ein ziehmlicher Rattenschwanz aus meiner Sicht, aber eben auch von Vorteil sowohl für die Admins und Entwicker, als auch für die User.

    • Was ich toll fände, wenn man mehrere Aufnahmen von Live-Streams (auch überschneidend) mit Anfang und Ende planen könnte. Das Thema gabe es auch schonmal im Forum:
      ** https://forum.mediathekview.de/topic/191/livestreams-per-timer-aufzeichnen
      Dabei sollte man auch ein eigenes Aufnahme-Set auswählen können (siehe Forum-Beiträge zu Abspielproblemen von aufgenommenen Live-Streams unter Windows). Die zur Verfügung stehende Bandbreite sollte dann natürlich großzügig für die Live-Streams priorisiert werden. Das wäre dann ein VDR inside - mit allen rechtlichen und technischen Problemen (Zwangstrennung, firewall, proxy, stotternde Streams …), die sich daraus ergeben können. Das könnte man aber auch (zumindest unter Windows) an die Aufgabenplanung oder in ein externes Script delegieren, welches regelmäßig abgearbeitet wird. Das ganze ist noch nicht ganz zu Ende gedacht. Vielleicht hat jemand gute Vorschläge dazu. Mir geht es dabei eher darum, das mit unter der Oberfläche von MV abarbeiten zu können und nicht noch ein extra Programm starten (und pflegen) zu müssen.
      Hier mal ein paar Links zum zeitgesteuerten Aufnehmen von Live-Streams und den Problemen und teilweise Lösungen dazu:
      ** https://www.deskmodder.de/blog/2016/11/20/tutorial-wie-zeitgesteuert-mit-vlc-streams-aufnehmen/
      ** https://telekomhilft.telekom.de/t5/Fernsehen/Aufnahme-Streaming-zeitgesteuert-mit-VLC/td-p/605826
      ** https://www.vlc-forum.de/thread/142-zeitgesteuert-aufnehmen/
      ** https://www.computerbase.de/forum/showthread.php?t=1471803
      ** https://www.macuser.de/threads/mit-vlc-rtp-stream-zeitgesteuert-aufnehmen.707387/
      ** https://www.macuser.de/threads/vlc-command-line-shell-script.564662/
      ** https://www.reddit.com/r/rocketbeans/comments/3u45gg/stream_aufnehmen/ (gute Diskussion und Anregungen)
      ** http://docs.livestreamer.io/index.html (direkt aufnehmen: livestreamer -o DATEINAME.ts URL source
      ** https://github.com/streamlink/streamlink-twitch-gui (ein GUI zu livestreamer)
      ** http://www.tubedigger.com/ (kostet)
      ** https://www.pcwelt.de/downloads/Wakeuponstandby-Download-551967.html
      ** https://www.heise.de/download/product/free-stream-recorder-87159
      ** http://www.kastorsoft.com/streamrecorder_en.php

    • Interaktion mit TV-Browser. Ungeahnte Möglichkeiten auf beiden Seiten … und wahrscheinlich auch Schwierigkeiten …

    Wie oben schon angedeutet, bin ich hier bei den Träumen gelandet.

    So, das war’s erstmal von meiner Seite.

    Herzliche Grüße,
    Jo



  • Ich würde mir für ein redesigntes Mediathekview eine bessere Integration in KDE wünschen. Neben einer besseren Anpassung von Grafik/ Icons, wäre das vor allem eine Integration in das Notifikation-System, was auch anderen Linux-Benutzeroberflächen zugute käme, da alle die gleiche Grundlage haben. Auch fände ich es gut, wenn die Downloads direkt an KDE übergeben werden würden. Ansonsten scheint Mediathekview einen großen Speicherhunger zu haben, wäre schön wenn der geringer werden würden.


  • Entwickler

    @mark

    Hallo Mark, magst du mal “großen Speicherhunger” für uns definieren? Groß ist ja leider ein dehnbarer begriff. Aber auf einem aktuellen PC mit 32GB RAM ist 4GB nicht groß. Wenn man ein Laptop mit 2GB RAM hat, was schon etwas älter ist, dann wären 4GB nur mit auslagern von Speicher möglich.

    Daher magst du uns mal eine Referenz geben, was du für groß und klein hältst?

    Ansonsten, schon mal vielen Dank für das positive Feedback. Wir werden sehen was die nächsten Versionen so bringen. Auch die Entwickler haben schon einige Ideen. Aber zum Sammeln von Punkten ist es immer gut wenn jemand schreibt wie er/sie sich das vorstellt. Daher auch an @Jo-Grothe vielen Dank für die Mühe seine Ideen zusammenzuschreiben.

    Viele Grüße
    Sascha



  • @thesasch sagte in Redesing für Mediathekview 14.0.0:

    @mark

    Hallo Mark, magst du mal “großen Speicherhunger” für uns definieren? Groß ist ja leider ein dehnbarer begriff. Aber auf einem aktuellen PC mit 32GB RAM ist 4GB nicht groß.

    Das ist aber nichts was Otto Normalanwender zu hause rumstehen hat, von daher als Referenz schon mal ungeeignet.



  • @thesasch sagte in Redesing für Mediathekview 14.0.0:

    @mark

    Hallo Mark, magst du mal “großen Speicherhunger” für uns definieren? Groß ist ja leider ein dehnbarer begriff. Aber auf einem aktuellen PC mit 32GB RAM ist 4GB nicht groß. Wenn man ein Laptop mit 2GB RAM hat, was schon etwas älter ist, dann wären 4GB nur mit auslagern von Speicher möglich.

    Daher magst du uns mal eine Referenz geben, was du für groß und klein hältst?

    Ja, gerne. Ich habe aus dem Systemmonitor von KDE folgende Information rausgeholt:
    "The process java (with pid 8151) is using approximately 1001.8 MB of memory.
    It is using 994.6 MB privately, and a further 26.1 MB that is, or could be, shared with other programs.
    Dividing up the shared memory between all the processes sharing that memory we get a reduced shared memory usage of 7.1 MB. Adding that to the private usage, we get the above mentioned total memory footprint of 1001.8 MB."
    Java läuft ohne Mediathekview nicht, also wird der Speicher nur von Mediathekview verbraucht.


  • Entwickler

    @mark sagte in Redesing für Mediathekview 14.0.0:

    @thesasch sagte in Redesing für Mediathekview 14.0.0:

    @mark

    Hallo Mark, magst du mal “großen Speicherhunger” für uns definieren? Groß ist ja leider ein dehnbarer begriff. Aber auf einem aktuellen PC mit 32GB RAM ist 4GB nicht groß. Wenn man ein Laptop mit 2GB RAM hat, was schon etwas älter ist, dann wären 4GB nur mit auslagern von Speicher möglich.

    Daher magst du uns mal eine Referenz geben, was du für groß und klein hältst?

    Ja, gerne. Ich habe aus dem Systemmonitor von KDE folgende Information rausgeholt:
    "The process java (with pid 8151) is using approximately 1001.8 MB of memory.
    It is using 994.6 MB privately, and a further 26.1 MB that is, or could be, shared with other programs.
    Dividing up the shared memory between all the processes sharing that memory we get a reduced shared memory usage of 7.1 MB. Adding that to the private usage, we get the above mentioned total memory footprint of 1001.8 MB."
    Java läuft ohne Mediathekview nicht, also wird der Speicher nur von Mediathekview verbraucht.

    Vielen Dank fürs nachsehen. Das alleine die Filmliste im Rohformat schon 128MB hat ist dir aber bewusst. D.h. man könnte es jetzt so entwickeln das diese Liste nur ein einziges Mal im Speicher existiert und bei jedem Zugriff alle Informationen aus dieser Liste genommen werden. D.h. jedes mal wenn du was suchst oder scrollen willst muss im Speicher durch diese 128MB durchgehen. Das würde ein ziemlich langsames Oberflächenverhalten erzeugen und du würdest dich darüber beschweren das die Oberfläche nicht schnell genug reagiert.

    Jetzt ist es so das die Filmliste und die restliche Funktionalität durchaus nicht unkomplex sind und dafür das du ein einigermaßen ansprechendes Oberflächenverhalten hast, wird hier einiges in anderen Formaten vorgehalten. Das braucht aber seinen Speicher. Und daher finde ich 1 GB für eine Software die dir 50.000 Objekte anzeigt nicht unbedingt viel.

    Zum Vergleich wenn ich mein Lightroom öffne ohne irgendwas zu machen dann sind bei 25.000 Objekten in der Übersicht auch 500MB verbraucht, wobei hier immer die Bilder nachgeladen werden müssen die gerade nicht sichtbar sind. D.h. jedes mal wenn ich das scrollen anfange. Gut der Vergleich ist nicht ganz offensichtlich, aber beide Programme zeigen dir eine Liste an Objekten an. Das eine in Textform, das andere in Bildform. Und ich muss sagen das ich in MV jederzeit an jede Stelle in der Liste springen kann ohne das hier Daten nachgeladen werden müssen.

    Fazit: Ich persönlich finde 1 GB durchaus berechtigt.

    Viele Grüße
    Sascha



  • Beim (manuellen) Neuladen der Filmliste werden bisher zuerst alle Objekte der alten Filmliste im RAM vergessen und dann wird versucht, die neue Liste zu laden. Da in letzter Zeit immer wieder einmal keine neue Filmliste geladen werden konnte, fiel mir dieses Vorgehen negativ auf. Denn dadurch wird wieder die alte Filmliste geladen und alle Tabellen, die noch dazu gehören, werden neu angelegt.
    Performanter wäre es in diesem Fall, die alte Filmliste erst dann zu vergessen, wenn die neue Filmliste schon auf der Festplatte angekommen ist und als aktueller als die alte erkannt wurde.


  • Administrator

    (Ich habe das hier mal abgespltitet, da es im anderen Beitrag eher um das zukünftige Aussehen als um gewünschte Features gehen sollte.)



  • @thesasch sagte in Feature Sammlung MediathekView 14.0.0:

    Fazit: Ich persönlich finde 1 GB durchaus berechtigt.

    Jein. Ich bin kein Programmierer, aber ich würde durchaus hinterfragen, ob die ganze Liste immer im Speicher vorgehalten werden muss. Ich scrolle eigentlich nie durch die gesamte Liste, sondern suche eigentlich immer mit bestimmten Suchworten. Nun gibt es unter Linux und KDE mittlerweile solche Desktopsuchmaschinen, die quasi den ganzen Rechner verschlagworten und in einer Datenbank speichern. Zwischenzeitlich war das auch nicht so perfomant, aber mittlerweile geht es. Im idle-Zustand nimmt das Programm 10MB Speicher ein, wenn ich eine Suche starte und gleich Ergebnisse bekomme, dann sind es 30MB. Ich bin wie gesagt kein Programmierer, aber frage mich, ob das nicht auch für MediathekView möglich wäre, zu markieren welche Sender nicht im Speicher vorzuhalten sind. Es ist schon gut die Liste vollständig zu haben, aber es wäre gut, wenn zwischen einer vollen Liste und einer eingeschränkten Liste, die man selbst konfiguriert hin- und herschalten könnte.


  • Globaler Moderator

    @mark Man kann das ganze auch als Datenbank aufsetzen oder ggf. auf unnötige Informationen im Speicher anfangs verzichten. So müssen z.B. die URLs und die Beschreibung nicht im Speicher gehalten werden sondern nur ein Pointer in die Liste. Oder man lädt sich nur immer einen kleinen Teil und schmeißt ihn hinterher wieder weg. Früher - als Speicher knapp war - gab es Editoren, die immer nur 2kByte im Speicher hatten und den Rest auf der Diskette. Es gibt dadurch natürlich andere Einschränkungen, z.B. Verlangsamung beim Filtern und Suchen.


  • Administrator

    @menchensued sagte in Feature Sammlung MediathekView 14.0.0:

    @mark Man kann das ganze auch als Datenbank

    Das ist aktuell auch mein Plan. Eine lokale Datnebank in die die Filme geladen werden.
    Bzgl. Geschwindigkeit kann man immer die aktuell angezeigten im Ram vorhalten + nochmal die gleiche Menge derer die quasi auf der nächsten Seite kommen in den Ram laden. Damit geht es schnell man hat aber nicht die gesamte Liste im RAM.

    Ganz Allgemein wollen wir in der zukunft dann auch auf Serverseite von der Liste als Datei weg hin zu einer (sehr wahrscheinlich REST) API. Bei dieser kann dann der Client neue Filme anfragen indem er das Datum der letzten aktualisierung mitsendet und sich als Update alle Änderungen seit dem Holt.


Anmelden zum Antworten
 

46
Online

965
Benutzer

829
Themen

4333
Beiträge

Es scheint als hättest du die Verbindung zu MediathekView-Forum verloren, bitte warte während wir versuchen sie wieder aufzubauen.