Beiträge von MarkusE

    Hi,


    Im git ist ein Update.

    • Events werden jetzt erst 5 Stunden nach EndTime() gelöscht.
    • Ich habe die Gewichtung von Vote ... noch mal reduziert. Hier gesendete deutsche Serien habe oft gering Votes, und eigentlich ist das kein wirkliches Kriterium.


    Bitte testen.


    ~ Markus

    Hi,


    Ich dachte erst, es liegt an einem meiner Plugins. Da habe ich aber nichts gefunden, und dann habe ich mal mit plain vdr 2.6.6 ohne Patches und ohne Plugins getestet.

    Und Da tritt der Fehler auch auf.


    Also, beim Start einer Aufnahme belegt vdr zusätzlichen Speicher. Müsste so etwa 16MB bei SD Sendern, und etwa 20MB bei HD Sendern sein.

    Normalerweise wird dieser Speicher beim Beenden der Aufnahme wieder freigegeben. Manchmal aber auch nicht.


    Und manchmal bleibt der nicht freigegebene Speicher dauerhaft belegt.

    Es kommt aber auch vor, dass später eine zweite Aufnahme startet, diese neue Aufnahme fast keinen neuen Speicher belegt (nur so 3.4 MB), und beim Löschen des Timers für die zweite Aufnahme der Speicher wieder freigegeben wird, incl. des Speichers der am Ende der ersten Aufnahme nicht freigegeben wurde.


    Insgesamt nimmt aber der Speicherverbrauch bei vielen Aufnahmen zu, es bleibt immer wieder etwas übrig, das nicht freigegeben wird.


    Hat jemand eine Idee, woran das liegen könnte?

    Wer testen will: Legt einfach mal 10-20 Timer an, jeder mit einer Länge von einer Minute. Nach den Aufnahmen müsste der Speicherzuwachs sichtbar sein.


    ~ Markus

    MarkusE Kann es sein, dass mit deinem Patch in dem Fall, dass vom Sender keine EIT-Daten kommen (aus welchen Gründen auch immer) die Aufnahme nie startet? In der bisherigen Version würde er zumindest die vorgegebene Zeit aufnehmen, aber durch das 'return false' im Falle, dass die Aufnahme noch nicht begonnen hat, wird sie auch nie beginnen.

    Hi Klaus,


    falls der Sender keine EIT Daten (incl. korrektem running status) sendet, wird mit meinem Patch die Sendung nicht aufgenommen.

    Deshalb haben Timer ja das VPS Flag: Damit der User entscheiden kann, welche Sender so zuverlässig EIT/VPS Daten senden, dass diese verwendet werden können.

    Und der Fallback auf die event start-stop Zeit funktioniert doch auch nur dann, wenn der Sender korrekte EIT Daten sendet (in diesem Fall: event start-stop, running status wird nicht benötigt).


    Ohne meinen Patch, jetziges Verhalten:

    - Falls der Sender gar keine EIT Daten sendet, Aufnahme von event start-stop. Da fragt man sich natürlich, woher event start-stop kommt, wenn der Sender gar keine EIT Daten sendet? Na ja, vielleicht wurden ja gestern EIT Daten gesendet, nur heute nicht. Scheint mir doch eher ein theoretisches Problem.

    - Falls der Sender EIT Daten sendet, aber keinen running status: keine Aufnahme, also gleiches Verhalten wie mit dem Patch.

    ~ Markus

    > Welchen Sinn macht es, Timer zu programmieren, von denen man von vornherein weiß, dass sie nicht gleichzeitig aufnehmen können?

    Kann z.B. bei automatisch erzeugten Timern passieren, z.B. von epgsearch oder tvscraper oder ...


    > Und warum beginnt Timer C verspätet?

    um 10:04 ist der Empfänger von Timer A belegt

    -> PresentSeenWithin(EITPRESENTFOLLOWINGRATE) gibt false zurück

    -> Recording() gibt false zurück

    -> Matches(...) gibt startTime <= t + Margin && t < stopTime zurück. Das ist false, die Startzeit ist ja 10:05 und Margin ist 0. Falls der Sender das Event kurzfristig (z.B. um 9:30) updaten sollte, bekommen wir das wegen Timer A nicht mit.

    Hi,


    Anbei der aktuelle Patch.

    Gleiche Funktion, aber jetzt in timers (was Speicher spart), und nochmal von Klaus überarbeitet.

    Kommt so vermutlich in die nächste VDR Version. (bitte nicht schlagen, falls doch nicht ...).


    Wer testen möchte:

    Falls der oben gepostete vps_log.txt schon angewendet wurde: Rückgängig machen.

    Danach den hier attachten vps_longer_v3.diff.txt anwenden.


    VDR und alle Plugins neu übersetzen.


    ~ Markus

    Hi,


    Anbei ein Patch, der das Interface auch nicht ändert und sicherstellt, dass die (VPS) Aufzeichnungen mit der höchsten Priorität korrekt aufgezeichnet werden.


    kls , Dein Patch löst das Problem nicht wirklich.


    Dann würde bei Deinem Patch vps_PresentSeenWithin_v4.diff.txt:

    Timer B: Zwischen 9:10 und 9:15: wird die Aufnahme ständig gestartet und gestoppt. Ist jetzt nicht soo schlimm, erzeugt aber den Eindruck eines Fehlers, und der Sinn von VPS ist doch, das ich erst um 9:15 aufzeichne.


    Timer C: Aufnahme beginnt verspätet um 10:05 .

    ein Macro, das diese Änderung aktiviert (default: deaktiviert):

    -> würde ich nicht machen. Erhöht nur die Komplexität für Plugins, die dann auch noch prüfen müssen, ob das Macro aktiviert ist.


    Bleibt: Neue Developer-Version oder ändern in der aktuellen Prod. Version.

    In beiden Fällen müssen die Plugins angepasst werden, der Aufwand ist also gleich.


    Sind aktuell weitere Entwicklungen geplant? Falls ja, kann man ja eine neue Developer-Version machen.

    Falls nein: ändern in der aktuellen Prod. Version.


    Es ist klar, was geändert werden muss. Keine Fehlersuche notwendig. Änderungen sind gering.

    Hi,


    es geht um diese Änderung:

    Code
    device.h
    -  virtual bool MaySwitchTransponder(const cChannel *Channel) const;
    +  virtual bool MaySwitchTransponder(const cChannel *Channel, int Priority = MINPRIORITY) const;


    Was passiert denn, wenn eine Klasse von cDevice ableitet und MaySwitchTransponder selbst nicht implementiert? Dann müsste doch neu kompilieren reichen (?).


    Und was passiert, wenn wenn eine Klasse von cDevice ableitet und MaySwitchTransponder selbst implementiert? Also

    Code
    virtual bool MaySwitchTransponder(const cChannel *Channel) const;

    in der abgeleiteten Klasse steht? Würde der Complier das als "völlig neue" Methode in der abgeleiteten Klasse interpretieren, und nicht mehr als re-implementierung von MaySwitchTransponder aus device.h?


    Ich habe mal in der history geschaut, und May 9, 2017 wurde eine virtuelle cDevice Methode geändert:

    Code
      virtual bool SignalStats(int &Valid, double *Strength = NULL, double *Cnr = NULL, double *BerPre = NULL, double *BerPost = NULL, double *Per = NULL) const;
      virtual bool SignalStats(int &Valid, double *Strength = NULL, double *Cnr = NULL, double *BerPre = NULL, double *BerPost = NULL, double *Per = NULL, int *Status = NULL) const;

    Welche Änderungen mussten damals in den Plugins, die cDevice ableiten, durchgeführt werden?


    ~ Markus

    ffmpeg: Das, was bei

    Zitat

    Raspberry Pi OS, 64-bit, Debian version: 12 (bookworm)

    mitgeliefert wird. 8:5.1.4-0+rpt2+deb12u1 .


    softhddevice-drm:

    vdr-plugin-softhddevice-drm_0.6.1+git2022-07-19-1 .

    Von yaVDR, aber selbst übersetzt.



    Deinterlacer bei den 576i Sendern:

    Also, mir ist noch nicht aufgefallen, dass bei 576i Sendern etwas nicht stimmt. Habe das aber auch nicht getestet. Ich sehe mir nur Aufzeichnungen an, kein live-tv. Was sollte ich testen?


    ~ Markus

    Und jetzt noch ein paar Worte, wie sich der RPI5 in der Praxis schlägt:


    X11:

    Ich habe nur den Browser (Firefox) und Terminals genutzt, lief insgesamt flott, ich konnte nicht feststellen, dass etwas langsamer als auf dem PC war.

    Von daher: für mich voll OK. Kann jetzt nicht sagen, wie das ist, wenn da noch weitere Programme laufen, habe ich nicht getestet. Mal sehen. Vielleicht wird ja der Nachfolger meines alten Ubuntu PCs ein RPI5?


    VDR:

    Ich verwende softhddevice-drm und skindesigner mit shady_kiss.

    Funktioniert flott und stabil. Ich erinnere mich noch an meine Tests mit softhddevice-drm und RPI3. Das war so instabil, dass ich wieder zu rpihddevice gewechselt bin. Ist gar kein Vergleich. Auf dem RPI5 läuft softhddevice-drm wirklich gut. Der einzige "Schönheitsfehler", den ich bemerkt habe: Nach einem Sprung wird das Bild kurz schwarz. Ob es weitere Fehler gibt, wird die Praxis zeigen.


    Die Performance ist deutlich besser als beim RPI3: Der RPI3 hat sich vor dem ersten Anzeigen des Menüs immer etwas Zeit gelassen, und auch die Anzeige der Bilder der Schauspieler hat gedauert. Beides ist jetzt mit dem RPI5 wirklich flott.


    KODI:

    Ich hatte KODI auf dem fire-tv, und das hat ganz gut funktioniert. 4K Videos (Ausgabe auf full HD) haben aber Probleme gemacht, angeblich war das Netz zu langsam. Und: Nach dem Beenden eines Videos hat es immer etwas gedauert, bis wieder die Liste der Videos angezeigt wurde.

    RPI5 hängt am gleichen LAN Switch an dem auch der fire-tv hängt, und ist in beiden Punkten deutlich besser: (Bisher) keine Probleme mit 4K Videos, und nach Beenden eines Videos kommt die Liste der Videos sofort.


    Fazit:

    Der RPI5 ist genau das, was ich brauche. Auch wenn die Einrichtung aufwändiger war als erwartet.

    Insbesondere die Performance ist Super :) .

    Bildqualität ist auch voll OK, ich bin da aber nicht soo anspruchsvoll (Full HD Fernseher).


    Den Fan habe ich bei meinen Praxistest nie gehört, außer ev. beim Hochfahren, aber nicht beim Anschauen von Videos.


    ~ Markus

    Die Fernbedienung sollte ganz einfach sein:

    Stecker vom RPI3 GPIO abziehen, auf den RPI5 aufstecken, Software+Konfiguration vom RPI3 auf den RPI5 übertragen, fertig.


    Wollte aber auch nicht so einfach. Die Hardware war schon etwas älter, und beim Abziehen des Steckers aus dem RPI3 ist ein Kabel abgegangen.

    Erst mal zum Lötkolben tragen. Und beim Löten ist eine weitere Lötstelle gebrochen :( . Wo nochmal muss welches Kabel der Empfängerdiode hin? Erst mal im Netz suchen, prüfen, wo welche Leitung hingeht, ...


    Nachdem ich dann mit Löten fertig war, habe ich es im RPI3 getestet: Falls ich einen Fehler gemacht habe und etwas kaputtgeht, ist der neue RPI5 wenigstens sicher ... . Außerdem: Wenn ich es gleich in den RPI5 stecke und etwas nicht geht, ist unklar ob es ein HW Fehler oder ein SW Fehler ist. Also erstmal die HW im RPI3 testen.


    Im RPI3 hat es prima funktioniert, also in den RPI5 gesteckt und getestet. Ging leider nicht :( . Trotz der gleichen Konfiguration wie im RPI3 :( . Insbesondere KODI wollte manche Tasten nicht. Nach einer etwas längere Suche hatte ich es dann verstanden, s. Fernbedienung von KODI, warum manche Tasten nicht funktionieren, und wie es funktioniert. .


    Und jetzt geht auch die Fernbedienung :) .


    ~ Markus