Beiträge von TomJoad

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.

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.

Kann ich nicht nachvollziehen. Bei mir erzeugt epgsearch mit Suchtimer "fear the walking" genau 5 Timer, auch nach weiteren Searchtimer-Updates bleibt es dabei.

Allerdings wird vdr wohl den 3. Timer von 2:03-2:00 von Sonntag 2:03 bis Montag 2:00 laufen lassen (so ist es im Schedule markiert) oder sofort beenden. In diesem Spezialfall könnte man es mit einem längeren Nachlauf wahrscheinlich korrigieren.

Es bleibt dabei, dass es kein Allheilrezept gibt und man in der Nacht immer aufpassen muss.

Die Änderung in epgsearchext.c hat definitiv gefehlt.

Die zweite Änderung verstehe ich noch nicht. Möchtest du wirklich, das ein leerer Untertitel als Wiederholung akzeptiert wird, wenn im Vergleich ein Untertitel vorhanden ist?

Dann würde ich bei Sendern, wo das EPG unzuverlässig ist, doch gleich auf Untertitelvergleich verzichten?

Es kommt doch drauf an, was häufiger vorkommt und es dürfte schwierig sein, es allen recht zu machen (oder muss ich einen weiteren Modus einbauen?).

Ich kann leider nicht erkennen, ob ein EPG gerade eingeschränkt ist.

Eigentlich sollte man das alte Verhalten konfigurieren können, ich schaue mir das nochmal an.

In libavutil/frame.h und sonstwo in FFmpeg finde ich kein ELEMENT0 ???

Wäre es nicht sinnvoll, die Teletextpid herzunehmen, dann kann das Format der channels.conf unverändert bleiben? Die Kombination Vpid== 0 und Tpid != 0 wird es nicht geben. Damit wird die Info sofort aus der channels.conf verfügbar.

Dann kann man auch bei dem AAC-Audiostream unterscheiden, ob RDS eingebettet ist oder nicht. Für das eingebettete RDS braucht man eine angepasste FFmpeg Version, die man bei Carsten Gross (ts2shout) findet https://github.com/carsten-gross/FFmpeg , sonst werden die RDS-Daten nicht durchgelassen.

Im Prinzip läuft es damit schon bei mir, erfordert einen etwas größeren Eingriff in das Radioplugin. Es fehlt nur noch, dass beim Aufnehmen dieser Radiokanäle wie vorher auch die RDS-Daten mitgenommen werden, wenn sie in einem extra-Stream sind.

Leider sehe ich nicht, dass irgendwo das offiziell in FFmpeg einfliessen soll.

In epgsearch you can find "Use Content Descriptor"

Probier mal im Patch von Klaus aus Beitrag #14 die Abfrage zu ändern in

while (file.IsOpen() && cFile::FileReady(file, 0)) ...

weil in der Schleife die Datei nach EOF geschlossen wird

Ich wollte nur darauf hinweisen, dass auch ohne "using namespace std" und Aufruf von swap() Plugins in diese Falle laufen können.

Ich habe jetzt bei epgsearch DISABLE_TEMPLATES_COLLIDING_WITH_STL eingefügt und kann ohne Probleme damit leben.

Das Problem mit dem swap(,) , der uneindeutig wird, läss sich im vdr lösen, indem wieder abgefragt wird, ob _MOVE_H definiert ist (wie in den Versionen vorher auch)

--- tools.h.orig    2021-05-22 21:21:17.967112345 +0200
+++ tools.h    2021-05-22 21:21:47.802718408 +0200
@@ -57,8 +57,10 @@
 #if !defined(DISABLE_TEMPLATES_COLLIDING_WITH_STL)
 template<class T> inline T min(T a, T b) { return a <= b ? a : b; }
 template<class T> inline T max(T a, T b) { return a >= b ? a : b; }
+#if !defined(_MOVE_H)
 template<class T> inline void swap(T &a, T &b) { T t = a; a = b; b = t; }
 #endif
+#endif
 template<class T> inline int sgn(T a) { return a < 0 ? -1 : a > 0 ? 1 : 0; }
 
 template<class T> inline T constrain(T v, T l, T h) { return v < l ? l : v > h ? h : v; }

z.B. zieht epgsearch in Ubuntu-focal /usr/include/c++/9/bits/unique_ptr.h rein, wo ab Zeile 399 steht

using std::swap

swap(...)

...

Auch ohne namespace std scheinen einige System-Includes swap zu brauchen und ziehen std nach. Durch den Verzicht auf STL_CONFIG_H gibt es dann wohl Probleme.

Zu epgsearch sind vorläufige Anpassungen weiter oben, aber ich wollte mit dem git noch warten, bis sich hier eine endgültige Lösung abzeichnet.

Für epgsearch und gcc11 sind Änderungen neu im git.

Das scheint, zumindest in der Programmansicht von epgsearch, auch vorher keine Problem gewesen zu sein. Aber ich werde mir das genauer ansehen.

Mit den angehängtem diff lässt sich epgsearch wieder übersetzen (ohne ausgiebigen Test)

Ich habe mal des Handling von devices mit "HasInternalCam" vom vdr in epgsearch nachgezogen. Bevor ich das auf die Allgemeinheit loslasse, sollte der Patch aber ausgiebig getestet werden - und ich selber habe keine Cams und keine Entschlüsselungsmöglichkeiten.

Ich kann auch nichts bauen für BM2LTS

Ich bin ganz unbedarft beim CAM-Handling, aber epgsearch bildet den Mechanismus mit HasInternalCam() noch nicht nach, kann das eine Rolle spielen?

epgsearch benutzt die gleiche Routine wie der vdr in device.c, um festzustellen, ob ein verschlüsselter Sender entschlüsselt werden kann. Mittlerweile gibt es minimale Abweichungen zu dort, deren Bedeutung ich nicht verifizieren kann, weil ich nur unverschlüsselte Sender sehen kann.

Kann es möglich sein, das zu dem Zeitpunkt, wo der Konfliktcheck losläuft, der Kanal nicht verfügbar ist?

Ich bin eigentlich leidenschaftslos, ob epgsearch bei vdr-developer oder unter vdr-projects liegt. Mich nerven nur etwas Seiten, die behaupten, mirror von etwas zu sein und jahrelang keinen Pull machen. Solange im ungepflegten vdr-wiki noch der Verweis auf vdr-developer steht und das git dort funktioniert, werde ich es da aktuell halten.

Ich betrachte es aber auch nicht als großen Aufwand - bei entsprechender Berechtigungserteilung - das Repos auf vdr-projects aktuell zu halten.

Passiert das beim vdr-Start? Ist die neueste epgsearch-Version installiert, wo man die Checks verzögert loslaufen lassen kann?