Der der VDR um 20:00 mit Umschalttimer (ohne VDR-2.5 Patch, abgesehen TS-Errors, mit original LOCK_THREAD) an seiner neuen Lieblingsstelle pausierte, hab ich den Patch oben kurz eingespielt:
Jan 9 20:09:21 vdr: [4840] retuning due to modification of channel 101
Jan 9 20:09:21 vdr: [4840] switching to channel 101
Jan 9 20:09:21 vdr: [4840] SendCaPmts CAM 1: [1] actives in CAM: 2 -> 1 (3 pids)
Jan 9 20:09:21 vdr: [4840] CAM 1: unassigned from device 1
Jan 9 20:09:21 vdr: [4840] CAM 1/1: reusing MTD CAM slot
Jan 9 20:09:21 vdr: [5021] device 1 TS buffer thread ended (pid=4840, tid=5021)
Jan 9 20:09:21 vdr: [5020] buffer stats: 259816 (0%) used
Jan 9 20:09:21 vdr: [5020] device 1 receiver thread ended (pid=4840, tid=5020)
Jan 9 20:09:21 vdr: [4840] CAM 1: assigned to device 1
Jan 9 20:09:21 vdr: [5057] device 1 receiver thread started (pid=4840, tid=5057, prio=high)
Jan 9 20:09:21 vdr: [5058] device 1 TS buffer thread started (pid=4840, tid=5058, prio=high)
Jan 9 20:09:21 vdr: [4840] SendCaPmts CAM 1: [0] actives in CAM: 1 -> 1 (3 pids)
Jan 9 20:09:21 vdr: [4840] SendCaPmts CAM 1: [1] actives in CAM: 1 -> 2 (6 pids)
Jan 9 20:09:21 vdr: [4840] VAAPI: video/vaapi: clear image
Jan 9 20:09:22 vdr: [4962] frame error #1 (missing backref)
Jan 9 20:09:22 vdr: [4962] /srv/vdr/video/local/#1/2022-01-09.18.20.100-0.rec: 1 error
Jan 9 20:09:22 vdr: [5001] frame error #1 (missing backref)
Jan 9 20:09:22 vdr: [4840] switching device 1 to channel 101
Jan 9 20:09:22 vdr: [4840] SendCaPmts CAM 1: [0] actives in CAM: 2 -> 2 (6 pids)
Jan 9 20:09:23 vdr: [5001] /srv/vdr/video/local/#1/2022-01-09.20.00.100-0.rec: 1 error
Jan 9 20:09:23 vdr: epg2vdr: Cleanup old symlinks
Jan 9 20:09:24 vdr: [4905] VAAPI-ERROR: video/vaapi: black surface displayed
Jan 9 20:09:24 vdr: [4905] VAAPI: video: --:--:--.--- +0 0 0/\ms 0+3 v-buf
Jan 9 20:09:34 vdr: [4903] SVDRP < 192.168.1.2:45162 client connection accepted
Jan 9 20:09:34 vdr: [4903] SVDRP > 192.168.1.2:45162 server created
Jan 9 20:09:34 vdr: epg2vdr: Got epgd state 'busy (scraping)' (5)
Jan 9 20:09:34 vdr: epg2vdr: Change handler state to 'standby'
Jan 9 20:09:34 vdr: [4903] SVDRP < 192.168.1.2:45162 lost connection to client
Jan 9 20:09:34 vdr: [4903] SVDRP < 192.168.1.2:45162 connection closed
Jan 9 20:09:34 vdr: [4903] SVDRP < 192.168.1.2:45162 server destroyed
Jan 9 20:09:36 vdr: scraper2vdr: Got 1 series, continuing...
Jan 9 20:09:36 vdr: scraper2vdr: Got 744 new/updated Series in 26s from Database (new max scrsp: 1641744651)
Jan 9 20:09:36 vdr: scraper2vdr: Loading Series content from Database...
Jan 9 20:09:38 vdr: [4903] SVDRP < 192.168.1.2:45164 client connection accepted
Jan 9 20:09:38 vdr: [4903] SVDRP > 192.168.1.2:45164 server created
Jan 9 20:09:38 vdr: epg2vdr: Got epgd state 'standby' (1)
Jan 9 20:09:38 vdr: epg2vdr: Change handler state to 'active'
Jan 9 20:09:38 vdr: [4903] SVDRP < 192.168.1.2:45164 lost connection to client
Jan 9 20:09:38 vdr: [4903] SVDRP < 192.168.1.2:45164 connection closed
Jan 9 20:09:38 vdr: [4903] SVDRP < 192.168.1.2:45164 server destroyed
Jan 9 20:09:51 vdr: scraper2vdr: Handled 16 of 744 series, continuing...
Jan 9 20:10:06 vdr: [5001] frame error #751 (missed)
Jan 9 20:10:06 vdr: [5001] /srv/vdr/video/local/#2/2022-01-09.20.00.100-0.rec: 750 errors
Jan 9 20:10:06 vdr: [5001] ERROR: video data stream broken
Jan 9 20:10:06 vdr: [5001] emergency exit request ignored according to setup
Display More
Beim Retune hat es dann das CAM abgeschossen, aber der VDR hing nicht.
Im Debugger sah man so nichts. Mit "c" nach automatischem Modulreset ging es dann weiter.
Debugger ist noch attached, gucke gegen 22:00, was bei einem Umschalttimer regulär passiert...
Edit:
CAM mag das gar nicht, VDR läuft weiter.
Am MTD (0x4) sollte es eigentlich nicht liegen, da ich den Deadlock auch mit FTA Programmen erzeugen kann. Aber wird probiert:
Edit 2:
Mit 6 Umschaltaufnahmen (FTA <-> FTA, 1x laufend über CAM) kam der Fehler nicht (LOCK_THREAD original), aber immer tut er das auch nicht (CAMTweaks = 0x827 statt 0x823).
Edit 3:
Bin erst einmal wieder auf
--- a/device.c
+++ b/device.c
@@ -447,7 +447,7 @@
void cDevice::SetCamSlot(cCamSlot *CamSlot)
{
- LOCK_THREAD;
+// LOCK_THREAD;
camSlot = CamSlot;
scaMapper = CamSlot ? CamSlot->scaMapper : NULL;
scaMapMasterSlot = scaMapper && CamSlot->IsMasterSlot() && !CamSlot->MtdActive();
Display More
und CAM-Tweaks 0x823 zurück.
Bisher führte zu häufiges Umschlten auf CAM-Programmen dazu, daß irgendwann nur noch eine von zwei möglichen Entschlüsselungen verfügbar war. Jetzt machte das CAM nach 24x schnellem Umschalten während einer Aufnahme (über das CAM) einen Reset (CI+ Auth) und weiter geht's.
Jan 9 22:43:09 vdr: [16543] SendCaPmts CAM 1: [1] actives in CAM: 2 -> 2 (6 pids)
Jan 9 22:43:09 vdr: [16543] VAAPI: video: set trick-speed 0
Jan 9 22:43:09 vdr: [16555] VAAPI: audio/alsa: using pass-through device 'hdmi:CARD=PCH,DEV=2,AES0=0x06'
Jan 9 22:43:09 vdr: [16555] VAAPI: audio/alsa: start delay 336ms
Jan 9 22:43:10 vdr: [16556] DDCI-Err: can't write to CI adapter (/dev/dvb/adapter2/ca0): Eingabe-/Ausgabefehler
Jan 9 22:43:11 vdr: [16556] DDCI-Err: can't write to CI adapter (/dev/dvb/adapter2/ca0): Eingabe-/Ausgabefehler
Jan 9 22:43:11 vdr: [16556] DDCI-Err: can't write to CI adapter (/dev/dvb/adapter2/ca0): Eingabe-/Ausgabefehler
Jan 9 22:43:12 vdr: [16556] CAM 1: module present
==> /var/log/syslog <==
Jan 9 22:43:12 kernel: [54166.602621] dvb_ca_en50221: dvb_ca adapter 2: DVB CAM detected and initialised successfully
==> /var/log/vdr.log <==
Jan 9 22:43:12 vdr: [16556] CAM 1: module ready
Display More
Stefan