Ich poste mein Thema von hier mit mehr Details nochmals in VDR Core in der Hoffnung, kls hat einen Tipp.
Ich glaube inzwischen nicht mehr, dass das was mit epgd zu tun hat, außer vielleicht, dass er zusätzliche Last auf den svdrp Schnittstelle erzeugt und damit die Meldung häufiger kommt.
Umgebung: Zwei vdr 2.6.1 Backends, die über Peering mit einander verbunden sind.
Ich bekomme im 10-20 Minutentakt folgende Meldung ins Syslog:
Jun 24 19:14:51 user.err VDR-2204 vdr: [439] SVDRP VDR-2204 < 10.1.5.143:6419 timeout while waiting for response from 'VDR-2204-Dev'
Jun 24 19:14:51 user.err VDR-2204 vdr: [439] ERROR: can't send 'POLL VDR-2204 TIMERS' to 'VDR-2204-Dev'
Jun 24 19:25:11 user.err VDR-2204 vdr: [439] SVDRP VDR-2204 < 10.1.5.143:6419 timeout while waiting for response from 'VDR-2204-Dev'
Jun 24 19:25:11 user.err VDR-2204 vdr: [439] ERROR: can't send 'POLL VDR-2204 TIMERS' to 'VDR-2204-Dev'
Ich habe mal versucht den Timeout näher zu analysieren (Syslog von der Gegenseite zum ersten Eintrag, mit zusätzlich eingebauten Meldungen):
Jun 24 19:14:46 VDR-2204-Dev vdr[2057]: < S VDR-2204: POLL VDR-2204 TIMERS -> Befehl kommt vom am Client an
Jun 24 19:14:46 VDR-2204-Dev vdr: [2078] SVDRP: cSVDRPServer::Execute(): called, cmd = POLL VDR-2204 TIMERS from VDR-2204
Jun 24 19:14:46 VDR-2204-Dev vdr: [2078] cSVDRPServer::CmdPOLL() called
Jun 24 19:14:46 VDR-2204-Dev vdr: [2078] cSVDRPClientHandler::TriggerFetchingTimers() called
Jun 24 19:14:46 VDR-2204-Dev vdr: [2078] cSVDRPClientHandler::TriggerFetchingTimers() want to lock mutex 0x55bedeb4b430 -> zusätzliche Log bevor LockMutex
Jun 24 19:14:46 VDR-2204-Dev vdr[2057]: > C VDR-2204: POLL VDR-2204-Dev TIMERS
Jun 24 19:14:46 VDR-2204-Dev vdr: [2352] epg data writer thread ended (pid=2057, tid=2352)
Jun 24 19:14:51 VDR-2204-Dev vdr[2057]: < C VDR-2204: 250 OK
Jun 24 19:14:51 VDR-2204-Dev vdr[2057]: > S VDR-2204: 250 OK
Jun 24 19:14:51 VDR-2204-Dev vdr[2057]: < S VDR-2204: LSTT ID
Jun 24 19:14:51 VDR-2204-Dev vdr[2057]: > S VDR-2204: 250-1 1:S19.2E-1-1002-5021:2022-07-16:0208:0309:11:99:Crossing Oceans with a White Cane| 3004-682:<epgd><timerid>375</timerid></epgd>
Jun 24 19:14:51 VDR-2204-Dev vdr[2057]: > S VDR-2204: 250 2 1:S19.2E-1-1007-4914:2022-06-25:1048:1151:11:99:Archiv 1~Dokus~P.M. Wissen:<epgd><timerid>377</timerid></epgd>
Jun 24 19:14:51 VDR-2204-Dev vdr: [2078] cSVDRPClientHandler::TriggerFetchingTimers() mutex 0x55bedeb4b430 locked -> 5s später bekommt er erst den Lock
Jun 24 19:14:51 VDR-2204-Dev vdr: [2078] cSVDRPClientHandler::TriggerFetchingTimers() Client->SetFetchFlag(sffTimers) called
Jun 24 19:14:51 VDR-2204-Dev vdr: [2078] cSVDRPClientHandler::TriggerFetchingTimers() Client->SetFetchFlag(sffTimers) end
Jun 24 19:14:51 VDR-2204-Dev vdr: [2078] cSVDRPServer::CmdPOLL() Reply OK
Jun 24 19:14:51 VDR-2204-Dev vdr: [2078] SVDRP: cSVDRPServer::Execute(): end, cmd = POLL from VDR-2204 after 5s
Alles anzeigen
Dadurch, dass der MutexLock 5s braucht, gibt es auf der Gegenseite einen Timeout. Hochsetzen des Timeouts bringt nichts, dann braucht der MutexLock entsprechend länger ?!
Ich habe nur Timeout zu POLL TIMERS im syslog, keine andern. Das Peering funktioniert aber ohne Einschränkungen, da der Befehl nur sporadisch in den Timeout läuft.
Mit ist es nicht gelungen, rauszufinden, wer/was diesen Lock hält und warum genau für die Dauer des Timeouts. kls hast du einen Tipp, wo es hängt ?
Als Anlage die Änderungen um die zusätzlichen Logs zu erzeugen.