Posts by MarkusE

    > Schön wäre es, wenn wir die Ausgangsfrage zur Formulierung lösen oder wenigstens zurückstellen könnten. Das ständige Nachziehen des Patches ist auf Dauer schon etwas lästig.

    Was soll ich dazu jetzt sagen? Genau das war mein Ziel, als ich diesen Thread gestartet habe. Warum Du den Patch upgedatet hast obwohl wir uns hier noch nicht auf die Formulierung geeinigt haben, ist mir unklar.

    Und ich habe Deine Offtopic Fragen hier beantwortet, weil ich angenommen habe, dass das hilft, gute Formulierungen zu finden.

    Alle Texte, die von tvscraper kommen, sind englisch ("Systemsprache").

    Alle Texte aus dem Sender EPG und aus den live po Dateien sind deutsch.

    Und Texte, die ein Script von Dir zusammengebastelt hat oder die von epgsearch kommen oder ... sind? Na ja, je nach dem woher die Bestandteile kommen.

    Anmerkungen:

    • Die ersten 2 Zeilen "The Rookie" und "The Hammer, USA 2023 - Bearbeitet" kommen NICHT von tvscraper, sondern aus der info.vdr. Diese Texte sind auch auf allen Tabs ("EPG", "Scraper", ...) gleich.
    • tvscraper erwartet in der 2. Zeile (Kurztext) den Epsiodennamen auf Deutsch, weil zdf_neo EPG auf deutsch sendet.

    In diesen Einstellungen wird festgelegt, in welcher Sprache welcher Sender das EPG bereitstellt. Damit werden Sendungen identifiziert.

    Diese Sprache unterscheidet sich im Allgemeinen von der Sprache, in der die Texte aus den externen Datenbanken im UI dargestellt werden.

    Anmerkung: Die im UI dargestellten Texte werden aus Performancegründen in der lokalen tvscraper Datenbank gespeichert. Eine Änderung dieser Sprache bedeutet, dass diese Daten gelöscht und in der neuen Sprache von der externen Datenbank geholt werden müssen. Das möchte ich nicht implementieren, der Aufwand ist mir zu hoch. Wer diese Sprache ändern möchte, muss:

    • VDR beenden
    • Die tvscraper Datenbank, deren in memory Kopie und alle von tvscraper heruntergeladenen Bilder löschen (in /var/cache/vdr/plugins/tvscraper UND /dev/shm)
    • Die Sprache ändern (Systemsprache des Rechners)
    • VDR neu starten

    Ist jetzt keine perfekte Lösung, sollte aber auch nicht so oft notwendig sein.

    > Wo kann ich in deinem Patch die Anzahl der zu ignorieren Fehler erhöhen ?

    Da ist kein Zähler drin, dafür brauchst Du eine neue Member Variable neben ignoreTsContinuityErrorPid. Der Patch setzt am Anfang ignoreTsContinuityErrorPid = Channel->Dpid(0). Falls dann ein Continuity Error bei dieser Pid auftritt, wird der Fehler ignoriert und ignoreTsContinuityErrorPid = 0 gesetzt.

    Alternative: Du verwendest VPS, dann wird die Aufzeichnung rechtzeitig vor der nächsten Aufnahme beendet.

    > wie man so einen Timer aus der Kontrolle von epgsearch lösen könnte.

    Man müsste das aux Feld des Timers bearbeiten.

    Aber eigentlich will ich den Timer gar nicht aus der Kontrolle von epgsearch lösen. Also z.B. Start/Ende soll epgsearch ruhig weiter updaten. Aber: Ist es wirklich notwendig, den manuell geänderten Namen beim Update wieder auf einen generierten Default (2025.10.04-20:00-Sa) zu setzen?

    Ich habe einen Epgsearch Suchtimer auf "doctor who", mit "Serienaufnahme:" angekreuzt, Verzeichnis "Serien".

    Es wurde der Timer

    Code
    BBC Three HD 	19:57-20:55 0:58	
    
    Serien~Doctor Who~2025.10.04-20:00-Sa

    Erstellt. Das ist so weit OK. Im EPG steht kein Kurztext :( , und dann wird das Datum verwendet. Ich hab jetzt also mal hier https://thetvdb.com/series/doctor-who-2005/episodes/1452911 nachgeschaut, der Episondenname ist "Victory of the Daleks".

    Dann also gleich mal den Timer geändert, auf

    Code
    Serien~Doctor Who~Victory of the Daleks

    alles andere unverändert.

    Eigentlich gut: Nur: beim nächsten Suchtimer-Update ändert Epgsearch den Timer wieder zurück auf

    Code
    Serien~Doctor Who~2025.10.04-20:00-Sa

    :(

    Wie kann ich das verhindern?

    Hi kls ,

    Wie der Titel schon sagt: Der Section Handler hält Locks zu lange. Hier mal der syslog, gefiltert nach 1812231:

    Danach geht es unauffällig (und ohne "ERROR: lock kept too long") weiter.

    Hinweis: Ich kann ITV* hier zwar empfangen, es ist aber gerade so an der Grenze, manchmal geht es auch nicht. Das könnte dazu führen, dass der Treiber länger braucht, um Anfragen zu beantworten.

    Aus mediasrv.log:

    Ich hatte den Patch aus #40 jetzt einige Tage ohne eine Meldung in Verwendung, aber heute fand ich das hier:

    Code
    Aug 14 17:29:59 raspi4 vdr: [13408] channel 7 (BR Fernsehen Süd HD) event Thu 14.08.2025 17:30-18:00 (VPS: 14.08. 17:30) 'Abendschau - Der Süden' status 2->4
    Aug 14 17:31:00 raspi4 vdr: [13429] ERROR: lock kept too long (1755185460 seconds)
    Aug 14 17:31:02 raspi4 vdr: [13429] ./vdr cRwLock::Unlock() calling CheckLockTime at thread.c:169 at cRwLock::Unlock() at thread.c:225
    Aug 14 17:31:02 raspi4 vdr: [13429] ./vdr cStateLock::Lock(cStateKey&, bool, int) at thread.c:794
    Aug 14 17:31:02 raspi4 vdr: [13429] ./vdr cTimers::GetTimersRead(cStateKey&, int) at timers.c:1298
    Aug 14 17:31:02 raspi4 vdr: [13429] ./vdr cSVDRPClientHandler::ProcessConnections() at svdrp.c:647
    Aug 14 17:31:02 raspi4 vdr: [13429] ./vdr cSVDRPClientHandler::Action() at svdrp.c:737
    Aug 14 17:31:02 raspi4 vdr: [13429] ./vdr cThread::StartThread(cThread*) at thread.c:323
    Aug 14 17:31:39 raspi4 vdr: [13412] SATIP: Idle timeout - releasing [device 2]

    Die Zahl von 1755185460 Sekunden erscheint nicht realistisch, kann sich also nur um einen Bug handeln. Unmittelbar vor und nach dieser Meldung ist allerdings nichts Ungewöhnliches im Log. Meine Vermutung ist, dass vielleicht lockTime nicht richtig initialisiert wurde, ich sehe aber nicht, wo das passieren könnte. Vielleicht mag der eine oder andere das ja mal kritisch begutachten. Ich überlege, den Patch fest einzubauen, würde aber natürlich vorher gerne sicherstellen, dass sowas nicht nochmal passiert.

    Das ist bei mir jetzt auch aufgetreten:

    Code
    2025-09-22T16:04:54.569511+02:00 rpi4s vdr: [1144632] ERROR: lock kept too long (1758549894 seconds)
    2025-09-22T16:04:55.201496+02:00 rpi4s vdr: [1144632] /usr/bin/vdr cRwLock::Unlock() calling ?? at ??:0
    2025-09-22T16:04:55.201734+02:00 rpi4s vdr: [1144632] /usr/bin/vdr cSchedules_Lock::~cSchedules_Lock() calling ?? at ??:0
    2025-09-22T16:04:55.201817+02:00 rpi4s vdr: [1144632] /usr/bin/vdr main calling ?? at ??:0

    Ich denke, da rufen 2 Prozesse fast gleichzeitig CheckLockTime auf.

    In Zeile 3 if (t > 0) ist t noch größer 0, und in Zeile 4 int d = time(NULL) - t ist t == 0. Also hat ein anderer Prozess zwischen Zeile 3 und 4 t = 0 gesetzt.