Mal wieder VPS

  • Hi,


    hier noch ein kleines Update zu dem Patch:

    Bug fix: int cDevice::Priority(void) berücksichtigt jetzt auch Occupied, falls IsPrimaryDevice() == true.

    Improvement: int cDevice::Priority(void) gibt jetzt bei Occupied() devices "occupiedPriority - 1" zurück.

    Damit können Occupied() devices für Aufnahmen mit gleicher Priorität verwendet werden.


    ~ Markus

  • Code
    esyslog("ERROR timer %s recording, but EIT present/following missing. This is a bug in VDR, or this channel %d %s (%s) does not provide useable VPS information and you should disable VPS for this channel", 

    Wenn das ein "bug in VDR" ist, dann solltest du den beheben ;-).

    Ansonsten würde ich empfehlen, diese Meldung nochmal zu überarbeiten...

  • > Wenn das ein "bug in VDR" ist, dann solltest du den beheben ;-).

    Wer auch immer dafür zuständig ist, Fehler in VDR zu beheben.


    Also, um da Missverständnisse zu vermeiden: Das ist nicht ein Fehler in meinem hier geposteten Patch. Kann auch ein Bug in einem Plugin oder DVB Treiber oder ... sein. Mögliche Ursachen:

    • Der thread, der die EIT present/following Informationen updatet, läuft nicht/ist blockiert/bekommt zu wenig CPU Zeit/... . Warum auch immer, z.B. weil sich der DVB Treiber nicht so verhält wie erwartet und auf Anfragen nicht/zu langsam reagiert. Das wäre dann ein Bug im DVB Treiber, und ja, hatte ich schon ...
    • Ein anderer thread hält zu lange einen Lock auf LOCK_SCHEDULES_*. Dieser andere thread kann z.B. von einem Plugin sein. Und ja, bei meinen Plugins bin ich dafür zuständig, solche Fehler zu beheben
    • Kann natürlich auch ein Bug in einem (anderen) Patch sein
    • ...


    Was ich mit der Meldung sagen will:

    VDR zeichnet den Sender auf -> ein Tuner empfängt den Sender -> EIT present/following ist aktuell. Außer:

    • Der Sender sendet EIT present/following zu selten/oder gar nicht
    • Der Teil von VDR, der die EIT present/following Daten des Senders "empfängt", verarbeitet, ... funktioniert nicht richtig. Warum auch immer ...


    Könntest Du eine bessere Formulierung für die Meldung finden?


    ~ Markus


    P.S.: Bei "VDSB / video data stream broken" Fehlern dachten wir immer, es liegt am DVB Treiber oder am Sender oder an der Ausrichtung der Sat Schüssel oder an ...

    Kann aber auch an Fehlern in Patches (vdr-plugin-dynamite: bug fix) oder an Fehlern in VDR (Server ohne Ausgabeplugin, Kanal ändern führt zu "ERROR: video data stream broken") liegen.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Ich finde es etwas übertrieben, an der Stelle einen ganzen "Roman" zu erzählen ;-).

    EIT present/following bleibt aus, dafür kann es viele Gründe geben - wenn das vermehrt auftritt muss man es eh debuggen.


    Was anderes: warum occupiedPriorityTimeout zusätzlich zu occupiedTimeout?

    SetOccupied() wird nur an einer einzigen Stelle aufgerufen, und da nur mit 8 Sekunden Timeout. Das sollte sich doch mit *einer* Variablen erschlagen lassen, ohne die ganzen Fallunterscheidungen. Oder übersehe ich da was?

  • Hi Klaus,


    Dann schreibe doch:

    Code
    ERROR timer %s recording, but EIT present/following is missing. VPS is disabled until EIT present/following will be availabel again.

    wäre für mich auch OK. Gerne auch einen anderen Text.


    Zu occupiedPriorityTimeout: Habe ich eingebaut, weil das doch ein erheblicher Eingriff ist, ich unterbreche ja möglicherweise laufende Aufnahmen.


    Andererseits: Da in der Praxis (im VDR)

    • alle setOccupied Aufrufe (quasi) gleichzeitig erfolgen,
    • und bei allen Aufrufen der gleiche Timeout gesetzt wird,
    • und der nächste (quasi gleichzeitige) Aufruf von setOccupied erst nach dem Ablauf des Timeouts erfolgt

    dürfte occupiedPriorityTimeout tatsächlich unnötig sein, und kann auch weggelassen werden. Schadet aber auch nicht, basierend auf obiger Überlegung müsste das Ergebnis identisch sein.


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Dieser Patch ändert das Interface von cDevice::MaySwitchTransponder(). Wenn ich ihn übernehme, müssten alle Plugins, die von cDevice ableiten (z.B. sat-ip, iptv), entsprechend geändert werden. Ein einfaches Neucompilieren würde da nicht reichen.

    Welche dieser drei zwei Vorgehensweisen soll es sein?

    1. eine neue Developer-Version

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

    3. einfach einbauen und es "krachen" lassen

  • Ich würde Nummer 3 auf jeden Fall streichen.

  • 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

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Letztlich gibt es nur zwei realistische Optionen. Entweder die API wird nicht inkompatibel geändert (keine Ahnung wie die dann aussehen müsste) oder sie wird inkompatibel geändert und nach dem "krachen lassen" Prinzip rausgegeben.


    Ein Makro mit "standardmäßig deaktiviert" bringt niemandem was wenn ein Plugin dann die neue Schnittstelle benötigt. Der Distributor hat dann nur eine realistische Option: Einschalten.


    Und eigentlich haben wir mittlerweile auch theoretisch bessere Chancen denn je eine Änderung in endlicher Zeit bei allen Plugins reinzubekommen.

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

    Dann ja.

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

    error: 'virtual bool cDevice::MaySwitchTransponder(const cChannel*, int) const'

    was hidden [-Werror=overloaded-virtual]

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

    Sie mussten den neuen Parameter hinzufügen.

  • 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.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Warum muss unbedingt MaySwitchTransponder geändert werden?

  • Die code Änderungen für satip und iptv wären gering.

    Mal abgesehen davon, dass eine Änderung in iptv rein zu bekommen schwierig wird.



    Aber der Impact des Patches als solches für VDR Infrastruktur sind nicht ohne..

  • Was wäre denn stattdessen von folgender Variante zu halten?

    - Ändert keine Interfaces.

    - Wenn VPS+VPSGRACE abgelaufen ist, wird mit niedriger Priorität weiter bis zum Ende der Event-Zeit aufgenommen, womit auch gleichzeitig sichergestellt ist, dass der Event aktuell bleibt.

    - Evtl. wäre noch darüber nachzudenken, ob priorityGrace '1' sein soll, oder besser 'priority - 1', oder ganz anders.

  • 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 .

  • > 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.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • 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.

  • In der bisherigen Version würde er zumindest die vorgegebene Zeit aufnehmen

    Was passiert ohne Patch, wenn die Sendung um mehr als die Länge verspätet gesendet wird (zum Beispiel wegen aktueller Berichterstattung): Dann ist der Timer im falschen Timeslot abgearbeitet und die eigentliche Sendung wird trotz korrektem VPS Signal nicht aufgenommen. Oder nicht ?

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!