Posts by TomJoad

    Einen Suchtimer für den Server zu erzeugen wäre nicht so schwierig (abgesehen von Server-lokalen Einstellungen wie Channelgroups, Blacklists, Wiederholungen...).

    Was ist mit dem Editieren eines Remote-Suchtimers? Braucht Locks, wenn man ganz sicher gehen will. Was ist mit Funktionen wie erzwungenem Suchtimer-Update,

    Anzeigen der Timer, die erzeugt würden, Anzeigen der Timer und Aufnahmen, die erzeugt wurden, Löschen von Suchtimern (mit oder ohne erzeugten Timern)?.

    Wie sieht es aus im Verbund von Rechnern mit unterschiedlichen DVB-Empfangsarten, mit unterschiedlichem EPG oder Kanallisten?

    Ich bin für Code-Vorschläge offen.

    Das Problem von kamel5 lässt sich ohne Änderung im main-vdr nicht lösen. Bei Timeränderungen werden keine timerchange-Statusmeldungen verschickt.

    Das Behandeln des Aufnahmeendes musste mit 2.4 wegen der Lockgeschichten in einen extra-Thread verlegt werden. Damit konnte auch vor 2.5 nicht wirklich gewährleistet werden, dass das zugehörige Timerobjekt noch vorhanden ist.

    Bei manuellem Eingriff muss man wohl auch selber dafür sorgen, dass die Aufnahme als erledigt gekennzeichnet wird.

    Ich habe die Änderungen hochgeladen. Zusätzlich gibt es eine neue Konfigurationsvariable unter Suchtimer: "Erlaubte Fehler" (default: 0). Hat in 2.6 eine Aufnahme mehr als die erlaubten Fehler, wird sie nicht als erledigt eingetragen.

    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.