Posts by TomJoad

    Ich teste gerade, die Start- und Stopzeiten des Timers zu Beginn der Aufnahme in der recdone-Struktur abzulegen. Falls bei Aufnahmeende der timer nicht mehr verfügbar ist, wird auf diese Werte zurückgegriffen. Damit ist man unabhängig davon, wie lange vdr die timer-Struktur erhält.

    Die Mitbewertung der errors in vdr 2.6 hatte ich auch in der Pipeline, ich würde nur gerne die Anzahl der tolerierten Fehler konfigurierbar machen.

    Werde ich mir ansehen, was steht denn in der epgsearch.log?

    Richtig wäre bei von Searchtimern erzeugten Timern nach Aufnahmeende:

    finished: 'titel' ....

    added rec done for ...


    Hängt aber wahrscheinlich wirklich mit 2.5/2.6 zusammen und mit dem commit:

    Author: Klaus Schmidinger <vdr@tvdr.de>

    Date: Tue Apr 20 13:22:37 2021 +0200
    Deleting expired timers is now triggered immediately after the timers are modified

    Bei meinen Tests mit GetLatmRdsDSE() waren die Transaktionsnummern im 3.Byte immer durchlaufend. "False Positives" kann man vermindern, wenn man abfragt, ob am Anfang ein "0xFE" oder ein "0xFE" unmittelbar nach einem "0xFF" kommt, aber ich habe schon ein Pseudopaket mit lauter "0xFE" gesehen.


    Den Ffmpeg-Code konnte ich nicht nutzen, weil der vdr jedes empfangene TS-Paket an mehrere Receiver verteilen kann, in dem Fall an die Audio-Ausgabe im Output-Plugin und an das Radioplugin, das RDS und früher RASS extrahiert. Das Radioplugin bekam dann manchmal nur einen Teil der Seitenbanddaten, der andere verpuffte im Audio-Ausgabeplugin, wenn ein frame gleichzeitig verarbeitet wurde.

    Ich muss mir das mal anschauen, aber Teletext von einem anderen Kanal als dem Livekanal sollte doch kein Problem sein, wenn dieser Kanal sowohl Vpid als auch Tpid hat.

    Es kommen halt nur von den Radiosendern mit Extrapid für RDS über diese Pid Daten rein, die rein theoretisch der Teletextanzeige Probleme bereiten könnten -

    vielleicht würden die aber auch nur ignoriert werden, weil keine Seitennummer gefunden werden kann.

    Ich sehe aber schon dein Problem, wenn für den Livekanal kein Teletextthread gestartet wird.

    Mein Wunsch wäre, bei reinen Radiosendern (Vpid == 0) gleich einen return einzubauen. Dann kann man die Tpid bei Radiosendern mit Extrapid für RDS zum Speichern dieser Pid in der channels.conf verwenden. Meines Wissens gibt es keinen Radiosender, wo die Teletextpid aktiv wäre.

    Im aktuellen Stand gibt es die Optionen "ja", "nein" und "erlaube leere", letzteres, weil ich es verständlicher fand als die alte Bezeichnung "wenn vorhanden". Aber inhaltlich entspricht es dem ehemaligen Code.

    Die Diskussion ist jetzt, ob es sinnvoll ist, das zu ändern in so was wie "erlaube das eins leer und eins gefüllt ist" oder dies als weitere(?) Option einzubauen.

    Dann würden auch solche Untertitel als gleich beurteilt und kein Timer erzeugt.

    Eine wirklich verlässliche Art, Wiederholungen zu vermeiden, wird es nicht geben, es reicht ja, wenn bei einer Neuausstrahlung im Untertitel eine Jahreszahl dazukommt. Ich denke immer noch, es ist besser Wiederholugen zuzulassen als Aufnahmen zu verpassen. Im obigen Fall mit N24 und N24Doku kann man ja im Suchtimer den Kanal vorgeben.

    Was verstehe ich denn hier falsch? Für mich war immer der Hintergrund bei der Wiederholungsvermeidung, lieber eine Aufnahme zu viel zu haben als eine Sendung nicht aufzunehmen, weil sie fälschlich als Wiederholung erkannt wird.

    Wenn ich jetzt Untertitel für relevant halte, warum soll dann ein fehlender Untertitel mit einem beliebigen Untertitel gleichgesetzt werden?

    Kommen bei einer bestimmten Sendung zu viel wiederholte Aufnahmen, kann ich ja den Untertitelvergleich rausnehmen.

    Die Einstellung mit dem Erlauben beiderseits leerer Untertitel sollte mit dem letzten git-Stand rundlaufen.

    Das weicht vom bisherigen Verhalten ab und es noch zusätzlich einzubauen, macht alles noch komplizierter. Es ist jetzt schon schwierig, verständlich zu erklären, was die Optionen sollen. Es gibt auch nicht so viele Sender, wo man sich nicht aufs EPG verlassen kann - und dann kann man doch immer noch den Untertitelvergleich ganz weglassen.

    Ich habe den Fehler gefunden, wird im git korrigiert

    Solange der vdr in der timers.conf nicht mit der Unixzeit arbeitet wie das EPG, sondern nur HH:MM des gewünschten Tages abspeichert, kann es während der Sommer-auf-Winterzeit-Umstellung Probleme geben. Hier sind die Zeiten am Sonntag zwischen 2:00 und 2:59 zweideutig. Die Anfangszeit kann eine Stunde zu früh liegen und die Endezeit kann vor der Anfangszeit liegen bei Sendungen, die aktiv sind um 3:00.

    (mktime wird bei der Rückumwandlung aus Datum-Uhrzeit in Unixzeit in diesem Zeitraum immer die Sommerzeit hernehmen)


    Daran kann epgsearch nichts ändern. Epgsearch müsste bei der Überprüfung, ob ein Suchtimer für ein Event schon existiert (bei Erzeugen nach Löschen auf ja), die gleichen Zwischenschritte machen (Event->tm, tm->Unixzeit).

    Aber damit ist nicht gewährleistet, dass die erstellten Timer zu sinnvollen Aufnahmen führen. Hat mal jemand ausprobiert, ob der vdr vor der Aufnahme die Daten nochmal mit dem EPG abgleicht und korrigiert? Wenn ja, würde ich die Zwischenschritte einbauen.

    Beim Timer von 2:03-2:00 liegt die Stop-Differenz vom geplanten und vorhandenen ca. 1 Tag auseinander, deshalb wird er neu erzeugt (nur, wenn Timer neu erzeugen gesetzt ist). Dieser Timer ist aber auch nicht sinnvoll und sollte nicht erzeugt werden (passiert aber auch ohne epgsearch)

    Beim Timer von 2:43-3:45 liegt die Start-Differenz um 1 Stunde auseinander, das sollte eigentlich mal korrigiert worden sein.