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?
Mir gefällt auch die alte Implementierung (2008), wo es zwei Optionen für Untertitelvergleich gab ("Yes" und "If Present"), besser. Hieß: bei Yes müssen auch Untertitel vorhanden sein, sonst wird angenommen, die Sendung könnte unterschiedlich sein (wenn bei der Tagesschau kein Untertitel da ist, ist trotzdem jede Tagesschau verschieden)
Bei "If Present" zählten auch gleiche LEERE Untertitel als Wiederholung, wenn alle anderen Bedingungen passen.
Im März 2011 ist diese Option wieder rausgenommen worden, die Option heisst immer noch "If Present", verhält sich aber wie das alte "Yes".
Ich scheue mich etwas, an der Schraube zu drehen, weil sich wohl die Mehrheit an das Verhalten gewöhnt hat oder es richtig findet.
Stimmt, das ist nicht konfigurierbar. Sind denn außer den Feldbreiten auch die ausgegebenen Felder strittig?
Was passiert denn, wenn du im der epgsearchmenu.conf ein paar mehr tabulatoren einträgst?
Deine Grafik ist blockiert, das Menü, mit dem epgsearch startet, ist konfigurierbar, welches ist gemeint?
Nach dem "set to no event" kommt doch 5 Sekunden später wieder ein "set to event", wahrscheinlich hat sich was im
EPG geändert. Der Rechner sollte dann eigentlich um 03:26 aufnehmen, das ist auch der next timer event im log.
man 5 epgsearchmenu.conf
Die Meldungen mit pid=1528 kommen alle vom vdr. Nur die allererste Meldung ist von epgsearch. Was passiert in der Lücke im Log
zwischen 3:26 und 4:55 Uhr?
Könnte durchaus die Ursache sein.
Meine Patch-Idee würde in dem geschilderten Fall nichts bringen. Die gelinkten Dateien (epgsearch.conf etc) sind nicht auffällig und funktionieren bei mir.
Was steht denn in der der epgsearch.log und im system-logging vor dem Absturz? Welche Versionen von vdr und plugins sind im Einsatz? Selbst übersetzt oder welcher Distro-Stand genau?
Ein Backtrace im Coredump würde auch vielleicht etwas mehr aussagen
Ich kann die Delay-Änderung von 2.4 für 2.2 als Patch zur Verfügung stellen, wenn gewünscht. Das müsste aber jemand anders ausprobieren auf Nebenwirkungen, bevor es ins git kommt.
Natürlich ist ein Update von epgsearch möglich, aber zu einer Problembehebung gehört eine Fehlererkennung. Die ist mir mit einer vagen Beschreibung nicht möglich, wenn ich das Problem nicht nachstellen kann.
Ich werde mal einen epgsearch in vdr-projects einstellen, der seine Checks um 10 Sekunden (einstellbar) verzögert beim Start, vielleicht hilft es ja.
Dieses "out of bounds" kommt, wenn die Uhrzeitanzeige im Setup aktiv ist (die eigentlich völlig unnötig ist).
Der DrawText in DrawClock müsste bei Index 31 beginnen.
Du könntest mal probehalber den conflictcheck im setup abschalten, um zu sehen, ob es vom Searchtimer-Update oder vom Conflictcheck kommt. In einem anderen Thread hier gab es vor kurzem einen Patch, dass epgsearch seine Aktionen nach vdrstart erst verzögert beginnt, um gerade bei verschlüsselten Kanälen locking-Problemen aus dem Weg zu gehen.
Ansonsten ist eine Analyse nur mit einem backtrace möglich
Ohne epgsearch.log mit verbosity=3 kann ich nichts weiter dazu beitragen (und möglichst noch den entsprechenden epgsearch.conf-Eintrag)
Ich frage mich, ob epg2vdr da rein spielen kann? Was sagt denn die epgsearch.log?
Gibt es logs zum externen epg?
Ist das ein Sender in anderer Zeitzone? VPS?
Die Anzahl der zu behaltenden Aufnahmen wird nur in Betracht gezogen, wenn "Löschen nach n Tagen" > 0 ist.
Die 2 bei dir wird im GUI auch nur dann angeboten !?
Das Verhalten ist so beabsichtigt, wenn im obigen Eintrag 1 steht, wird am Tag nach der Aufnahme nachgesehen, ob sie schon gelöscht werden darf oder ob noch Aufnahmen stehen bleiben sollen. Dann sollten in der epgsearch.log Meldungen kommen wie "delete expired" oder "expired, but will be kept"
Und was steht genau in der conf.d/epgsearch.conf ?
QuoteDisplay MoreWenn ich das richtig verstehe bedeutet "timer 0", dass der timer deaktiviert/gelöscht wird...?
Insofern muss es ein Problem mit epgsearch sein...
Die "timer 0" Meldungen werden vom vdr ausgegeben, wenn epgsearch ein neues timer-Objekt anlegt. Das ist nötig, um zu untersuchen, ob der Timer schon existiert, gerade aufgenommen wird, ...
Erst wenn das Objekt aktiv wird, erhält es eine Id ungleich Null.
Die Meldungen in der Systemlog sind völlig normal.
Wenn Timer gelöscht werden, sollte eine andere Meldung kommen. Sind vielleicht andere Plugins im Spiel, stimmt die Systemzeit (ich weiss, das ist alles schon gesagt). Was steht in der epgsearch.log?
