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

Participate now!

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