Also, falls ich eplists Daten in tvscraper nutzen würde, würde es dann genügen, die eplists Daten nur zu lesen?
Oder müsste ich auch die Möglichkeit zum Ergänzen / Ändern von eplists Daten mit einbauen?
Also, falls ich eplists Daten in tvscraper nutzen würde, würde es dann genügen, die eplists Daten nur zu lesen?
Oder müsste ich auch die Möglichkeit zum Ergänzen / Ändern von eplists Daten mit einbauen?
> 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:
Dutch texts are updated in git
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:
Ist jetzt keine perfekte Lösung, sollte aber auch nicht so oft notwendig sein.
> Wo ist mein Problem?
Ich denke, Dein Kernel ist zu neu ![]()
Das sollte DD fixen
sieht gut aus (aber ungetestet)
> 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?
Und wie soll jetzt tvscraper den Untertitel herausfinden, ohne den Episodennamen ...
> das würde der Funktion von epgsearch widersprechen
Warum?
Ich habe einen Epgsearch Suchtimer auf "doctor who", mit "Serienaufnahme:" angekreuzt, Verzeichnis "Serien".
Es wurde der Timer
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
alles andere unverändert.
Eigentlich gut: Nur: beim nächsten Suchtimer-Update ändert Epgsearch den Timer wieder zurück auf
![]()
Wie kann ich das verhindern?
Du kannst dich mit gdb in den laufenden vdr hängen und ein backtrace machen
OK, das kannte ich nicht, ich nehme dafür Suchtimer.
Stimmt, Sonderbehandlung für periodische Timer entfernt.
ist im git
Hi kls ,
Wie der Titel schon sagt: Der Section Handler hält Locks zu lange. Hier mal der syslog, gefiltert nach 1812231:
2025-09-30T17:18:17.017920+02:00 rpi4s vdr: [1812231] device 2 section handler thread started (pid=1812226, tid=1812231, prio=low)
2025-09-30T17:21:27.507776+02:00 rpi4s vdr: [1812231] channel 38 (KiKA HD) event Di. 30.09.2025 17:15-17:25 (VPS: 30.09. 17:15) 'Super Happy Magic Forest' status 0->4
2025-09-30T17:22:31.203323+02:00 rpi4s vdr: [1812231] channel 53 (ITV1 HD) event Di. 30.09.2025 17:00-18:00 '' status 0->4
2025-09-30T17:23:35.833763+02:00 rpi4s vdr: [1812231] channel 58 (ITV4 HD) event Di. 30.09.2025 16:50-17:50 '' status 0->4
2025-09-30T17:53:37.119752+02:00 rpi4s vdr: [1812231] channel 58 (ITV4 HD) event Di. 30.09.2025 16:50-17:50 'Magnum, P.I.' status 4->1
2025-09-30T17:53:37.121023+02:00 rpi4s vdr: [1812231] channel 58 (ITV4 HD) event Di. 30.09.2025 17:50-18:55 'Magnum, P.I.' status 0->4
2025-09-30T20:57:39.598055+02:00 rpi4s vdr: [1812231] ERROR: lock kept too long (80 seconds)
2025-09-30T20:57:40.214506+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cMutex::Unlock() calling ?? at ??:0
2025-09-30T20:57:40.214836+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cThreadLock::~cThreadLock() calling ?? at ??:0
2025-09-30T20:57:40.214983+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cSectionHandler::Action() calling ?? at ??:0
2025-09-30T20:57:40.215127+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cThread::StartThread(cThread*) calling ?? at ??:0
2025-09-30T20:57:40.215279+02:00 rpi4s vdr: [1812231] /lib/aarch64-linux-gnu/libc.so.6 at pthread_create.c:442
2025-09-30T20:57:40.215425+02:00 rpi4s vdr: [1812231] /lib/aarch64-linux-gnu/libc.so.6 at clone.S:82
2025-09-30T21:09:05.950530+02:00 rpi4s vdr: [1812231] ERROR: lock kept too long (75 seconds)
2025-09-30T21:09:06.408914+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cMutex::Unlock() calling ?? at ??:0
2025-09-30T21:09:06.409211+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cThreadLock::~cThreadLock() calling ?? at ??:0
2025-09-30T21:09:06.409343+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cSectionHandler::Action() calling ?? at ??:0
2025-09-30T21:09:06.409427+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cThread::StartThread(cThread*) calling ?? at ??:0
2025-09-30T21:09:06.409506+02:00 rpi4s vdr: [1812231] /lib/aarch64-linux-gnu/libc.so.6 at pthread_create.c:442
2025-09-30T21:09:06.409584+02:00 rpi4s vdr: [1812231] /lib/aarch64-linux-gnu/libc.so.6 at clone.S:82
2025-09-30T21:17:58.490838+02:00 rpi4s vdr: [1812231] ERROR: lock kept too long (66 seconds)
2025-09-30T21:17:58.999851+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cMutex::Unlock() calling ?? at ??:0
2025-09-30T21:17:59.000185+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cThreadLock::~cThreadLock() calling ?? at ??:0
2025-09-30T21:17:59.000328+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cSectionHandler::Action() calling ?? at ??:0
2025-09-30T21:17:59.000482+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cThread::StartThread(cThread*) calling ?? at ??:0
2025-09-30T21:17:59.000598+02:00 rpi4s vdr: [1812231] /lib/aarch64-linux-gnu/libc.so.6 at pthread_create.c:442
2025-09-30T21:17:59.000757+02:00 rpi4s vdr: [1812231] /lib/aarch64-linux-gnu/libc.so.6 at clone.S:82
2025-09-30T21:30:31.991920+02:00 rpi4s vdr: [1812231] ERROR: lock kept too long (205 seconds)
2025-09-30T21:30:32.535744+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cMutex::Unlock() calling ?? at ??:0
2025-09-30T21:30:32.536036+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cThreadLock::~cThreadLock() calling ?? at ??:0
2025-09-30T21:30:32.536145+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cSectionHandler::Action() calling ?? at ??:0
2025-09-30T21:30:32.536220+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cThread::StartThread(cThread*) calling ?? at ??:0
2025-09-30T21:30:32.536294+02:00 rpi4s vdr: [1812231] /lib/aarch64-linux-gnu/libc.so.6 at pthread_create.c:442
2025-09-30T21:30:32.536369+02:00 rpi4s vdr: [1812231] /lib/aarch64-linux-gnu/libc.so.6 at clone.S:82
2025-09-30T22:16:18.364619+02:00 rpi4s vdr: [1812231] ERROR: lock kept too long (1016 seconds)
2025-09-30T22:16:19.007954+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cMutex::Unlock() calling ?? at ??:0
2025-09-30T22:16:19.008198+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cThreadLock::~cThreadLock() calling ?? at ??:0
2025-09-30T22:16:19.008279+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cSectionHandler::Action() calling ?? at ??:0
2025-09-30T22:16:19.008354+02:00 rpi4s vdr: [1812231] /usr/bin/vdr cThread::StartThread(cThread*) calling ?? at ??:0
2025-09-30T22:16:19.008426+02:00 rpi4s vdr: [1812231] /lib/aarch64-linux-gnu/libc.so.6 at pthread_create.c:442
2025-09-30T22:16:19.008504+02:00 rpi4s vdr: [1812231] /lib/aarch64-linux-gnu/libc.so.6 at clone.S:82
2025-09-30T22:23:57.891268+02:00 rpi4s vdr: [1812231] changing pids of channel 251 (ARD-Test-R) from 5401+5401=27:5402=deu@3:0:0 to 5411+5411=27:5412=deu@3:0:0
2025-09-30T22:25:42.191478+02:00 rpi4s vdr: [1812231] channel 8 (NITRO) event Di. 30.09.2025 20:15-23:20 'Der Hobbit - Smaugs Einöde' status 0->4
025-09-30T22:25:43.373254+02:00 rpi4s vdr: [1812231] channel 7 (SUPER RTL) event Di. 30.09.2025 22:10-23:05 'Lucifer' status 0->4
2025-09-30T23:24:47.984241+02:00 rpi4s vdr: [1812231] channel 2 (ZDF HD) event Di. 30.09.2025 22:15-22:45 (VPS: 30.09. 22:15) '37°' status 4->1
2025-09-30T23:24:47.984986+02:00 rpi4s vdr: [1812231] channel 2 (ZDF HD) event Di. 30.09.2025 22:45-00:00 (VPS: 30.09. 22:45) 'Markus Lanz' status 0->4
2025-09-30T23:24:49.056726+02:00 rpi4s vdr: [1812231] channel 19 (zdf_neo HD) event Di. 30.09.2025 21:45-23:15 (VPS: 30.09. 21:45) 'Ein starkes Team - Tödlicher Seitens
prung' status 4->1
2025-09-30T23:24:49.057331+02:00 rpi4s vdr: [1812231] channel 19 (zdf_neo HD) event Di. 30.09.2025 23:15-00:40 (VPS: 30.09. 23:15) 'Aufgelegt!' status 0->4
2025-10-01T00:02:48.463731+02:00 rpi4s vdr: [1812231] channel 2 (ZDF HD) event Di. 30.09.2025 22:45-00:00 (VPS: 30.09. 22:45) 'Markus Lanz' status 4->1
2025-10-01T00:02:48.506396+02:00 rpi4s vdr: [1812231] channel 2 (ZDF HD) event Mi. 01.10.2025 00:00-00:15 (VPS: 01.10. 00:00) 'heute journal update' status 0->2
2025-10-01T00:03:27.785612+02:00 rpi4s vdr: [1812231] channel 2 (ZDF HD) event Mi. 01.10.2025 00:00-00:15 (VPS: 01.10. 00:00) 'heute journal update' status 2->4
2025-10-01T00:20:03.203651+02:00 rpi4s vdr: [1812231] channel 2 (ZDF HD) event Mi. 01.10.2025 00:00-00:20 (VPS: 01.10. 00:00) 'heute journal update' status 4->1
2025-10-01T00:20:03.240962+02:00 rpi4s vdr: [1812231] channel 2 (ZDF HD) event Mi. 01.10.2025 00:20-01:45 (VPS: 01.10. 00:15) 'Hypnotic' status 0->2
2025-10-01T00:20:33.205414+02:00 rpi4s vdr: [1812231] channel 2 (ZDF HD) event Mi. 01.10.2025 00:20-01:45 (VPS: 01.10. 00:15) 'Hypnotic' status 2->4
2025-10-01T00:42:03.888926+02:00 rpi4s vdr: [1812231] channel 19 (zdf_neo HD) event Di. 30.09.2025 23:15-00:40 (VPS: 30.09. 23:15) 'Aufgelegt!' status 4->1
2025-10-01T00:42:03.927053+02:00 rpi4s vdr: [1812231] channel 19 (zdf_neo HD) event Mi. 01.10.2025 00:40-01:25 (VPS: 01.10. 00:40) 'Killing Eve' status 0->2
2025-10-01T00:43:16.598047+02:00 rpi4s vdr: [1812231] channel 19 (zdf_neo HD) event Mi. 01.10.2025 00:40-01:25 (VPS: 01.10. 00:40) 'Killing Eve' status 2->4
2025-10-01T01:24:07.505026+02:00 rpi4s vdr: [1812231] channel 19 (zdf_neo HD) event Mi. 01.10.2025 00:40-01:25 (VPS: 01.10. 00:40) 'Killing Eve' status 4->1
2025-10-01T01:24:07.512296+02:00 rpi4s vdr: [1812231] channel 19 (zdf_neo HD) event Mi. 01.10.2025 01:25-02:05 (VPS: 01.10. 01:25) 'Killing Eve' status 0->4
...
Display More
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:
...
2025-09-30 20:56:59 [965124] TS Sync byte not aligned, realigning stream (3800 // 86 // c7 // FEID: 1)
2025-09-30 20:56:59 [965124] TS Sync byte not aligned, realigning stream (4178 // 86 // 25 // FEID: 1)
2025-09-30 20:57:00 [965124] [1] skipped everything ...
2025-09-30 20:57:00 [965124] [1] skipped everything ...
2025-09-30 20:57:00 [965124] There have been 16380 ts errors within 1 second
2025-09-30 20:57:00 [965124] TS Sync byte not aligned, realigning stream (309 // 80 // 19 // FEID: 1)
2025-09-30 20:57:00 [965124] TS Sync byte not aligned, realigning stream (529 // 80 // 56 // FEID: 1)
2025-09-30 20:57:00 [965124] TS Sync byte not aligned, realigning stream (766 // 80 // fa // FEID: 1)
2025-09-30 20:57:00 [965124] TS Sync byte not aligned, realigning stream (998 // 80 // 8 // FEID: 1)
2025-09-30 20:57:00 [965124] TS Sync byte not aligned, realigning stream (1466 // 80 // 2e // FEID: 1)
2025-09-30 20:57:00 [965124] TS Sync byte not aligned, realigning stream (2166 // 80 // 94 // FEID: 1)
2025-09-30 20:57:00 [965124] TS Sync byte not aligned, realigning stream (2459 // 80 // 9c // FEID: 1)
2025-09-30 20:57:00 [965124] TS Sync byte not aligned, realigning stream (2831 // 80 // de // FEID: 1)
2025-09-30 20:57:00 [965124] TS Sync byte not aligned, realigning stream (3411 // 80 // 2d // FEID: 1)
2025-09-30 20:57:00 [965124] TS Sync byte not aligned, realigning stream (3910 // 80 // a9 // FEID: 1)
2025-09-30 20:57:01 [965124] [1] skipped everything ...
2025-09-30 20:57:01 [965124] [1] skipped everything ...
2025-09-30 20:57:01 [965124] [1] skipped everything ...
2025-09-30 20:57:01 [965124] [1] skipped everything ...
2025-09-30 20:57:01 [965124] [1] skipped everything ...
2025-09-30 20:57:01 [965124] There have been 16626 ts errors within 1 second
2025-09-30 20:57:01 [965124] TS Sync byte not aligned, realigning stream (512 // 114 // ac // FEID: 1)
2025-09-30 20:57:01 [965124] TS Sync byte not aligned, realigning stream (1131 // 114 // 9a // FEID: 1)
...
Display More
Im Prinzip ist es natürlich möglich, weitere Datenbanken (IMDb, eplists, ...) hinzuzufügen.
Ich müsste dazu halt die Datenbank aufboren -> Aufwand. Mal sehen. Jedenfalls nicht kurzfristig.
Die IMDb API verlangt außerdem einen AWS Account. Habe ich nicht, hört sich irgendwie aufwändig an.
> Auf der Scraper Seite ist ein Link zu IMDb drin (und keiner zu thetvdb). Also verstehe ich das so, dass dies die verwendete Quelle ist.
Quelle für Serien ist normalerweise TheTVDB, und Quelle für Filme ist TMDB. In diesen Datenbanken ist oft der Link zu IMDb gepflegt, der dann an dieser Stelle angezeigt wird.
> Egal, ob ich auf das IMDb-Icon oder den IMDb-Link klicke, lande ich immer bei https://www.imdb.com/title/tt7587890/, also bei der Serie, nicht aber bei der konkreten Folge (S4E12)
Ob tvscraper die Folge gefunden hat, kannst Du im Tab Scraper sehen. Der IMDb-Link geht auf die Folge, falls (tvscraper die Folge gefunden hat) && (der Link zur IMDb Folge in thetvdb gepflegt ist).
https://thetvdb.com/series/soko-leipzig#seasons
-> thetvdb kennt nur 25 Staffeln
Ich hatte den Patch aus #40 jetzt einige Tage ohne eine Meldung in Verwendung, aber heute fand ich das hier:
CodeAug 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:
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.
static void CheckLockTime(time_t &t)
{
if (t > 0) {
int d = time(NULL) - t;
if (d > MAX_LOCK_TIME) {
esyslog("ERROR: lock kept too long (%d seconds)", d);
cBackTrace::BackTrace();
}
}
t = 0;
}
Display More
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.