Beiträge von TomJoad

Uwe hat oben schon darauf hingewiesen:

radioaudio.c:1962:22: warning: unused variable 'j' [-Wunused-variable]
 1962 |             for (int j = 0; !found && a[i]; i++)

da und in den folgenden Zeilen muss i durch j ersetzt werden

@nvertigo: Bosetti ist zwar ein Serientimer, aber AvoidRepeats steht auf No, dann wurde noch nie ein epgsearchdone.data-Eintrag erzeugt.

@nvertigo: Die komplette epgsearch.log von heute würde ich gerne sehen

Danke fürs Testen, ich kann das zwar bei mir nicht nachvollziehen, habe aber eine Umstellung gemacht, die den crash verhindern sollte.

Ausserdem werden mehr logs mit Loglevel 2 statt 3 geschrieben.

Tut mir leid, da ist beim Kopieren was schief gegangen. Die v2 sollte keine rejects mehr haben.

Vielleicht mag ja jemand den angehängten Patch testen, bevor er ins git kommt.

Damit dürfen timer schon gelöscht sein, wenn das Aufnahmeende untersucht wird.

Sollte mit vdr 2.4 und 2.6 funktionieren.

epgsearch-changed-handling-of-finished-recordings.patch

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

Hallo Helmut, es scheinen auf jeden Fall ein Problem mit dem Erkennen von FIL Elementen zu geben. Folgt in der realen Reihenfolge nach dem DSE-Element ein FIL-Element als letztes vor dem TERM, wird das DSE-RDS nicht erkannt.

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.

Da müsste mal jemand schauen, wie es bei der Satellitenausstrahlung ist. Sonst würde ich das Problem bei PYUR ansiedeln

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

--- conflictcheck.c.orig    2021-12-10 17:48:56.144864670 +0100
+++ conflictcheck.c    2021-12-10 20:50:00.616298758 +0100
@@ -704,9 +704,8 @@ int cConflictCheck::GetDevice(cConflictC
                 imp |= devices[i].Receiving();
                 // do we have GetClippedNumProvidedSystems ???  uses MaxNumProvidedSystems in vdr since V1.7 !!
                 // but should not be needed
-                imp <<= 2;
+                imp <<= 8; // NumProvidedSystems is not clipped, apply headroom
                 imp |= devices[i].NumProvidedSystems(); // avoid cards which support multiple delivery systems
-                // imp <<= 2;
                 // imp |= GetClippedNumProvidedSystems(2, device[i]) - 1;  // avoid cards which support multiple delivery systems
                 // use the device with the lowest priority (+MAXPRIORITY to assure that values -99..99 can be used)
                 imp <<= 8;

Wieso ist das bisher niemandem aufgefallen? Ich kann es reproduzieren, sollte auch schon vor 2.4.1 ein Problem gewesen sein.

Danke, scheint wunderbar zu funktionieren.

Du solltest in Zeile 180 des patches noch "==" in "=" abändern?

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.