Posts by Fourty2
-
-
Habe so einen ähnlichen Fehler.
Ab und an zerlegt es die Datenbank, MariaDB startet dann neu und mit etwas Glück gibt es nur epg2vdr: SQL-Error in 'execute(stmt_execute)' ohne, daß es den VDR (wiederholt) mitreißt.
Habe allerdings von den letzten 7 Tagen Datenbank Backups, die ich dann einfach wieder zurückkopiere, bis die DB wieder ok ist. Automatische Datenbankreparatur konnte den ursächlichen Fehler nie beseitigen.
Hatte bisher allerdings eher den Verdacht, daß das auftrat, wenn ein VDR ungünstig abstürzte (CI Hänger, ö.ä.) oder ich beim Umbau auf "Non-Blocking API" was übersehen habe.
Grüße,
Stefan
-
Ich würde hier eher ein schwaches Signal vermuten.
Das habe ich als erstes geprüft. Da sich das Verhalten zwischen Sonne und Regen nicht unterschied, habe ich es auf den CAM-Zweig eingegrenzt. FTA ging ja auch immer.
Wenn es das aber nicht ist und du ein DD-CI verwendest, versuche es einmal mit einer kleineren Buffergröße beim ddci2-Plugin - z.B. mit --bufsz 500 statt dem Default von 1500.
Das mit dem Buffer interessiert mich. Warum? Ich hätte ihn größer gemacht.
Tatsächlich nutze ich am J3160-ITX Board eine Octopus-Mini V2 (Mini-PCIe) und das zugehörige DuoFlex-CI. Und da lag auch das Problem.
Die Octopus paßte 2017 nicht wirklich in den Mini-PCIe-Slot, Tastaturanschluß im Weg (ausgelötet) einziges Befestigungloch genau am TAB1 Stecker - naja, lief irgendwie.
Später eine Mini-PCIe-Verlängerung aufgetrieben und die Octopus ins Gehäuse geklebt. Dabei muß ich wohl die Kabel TAB1<->TAB2 vertauscht haben. Das CAM in CI-Port 1 störte das aber wohl nicht. Nach dem TV Test hatte ich dann CI-Port 2 erwischt, nur noch JuSchu-Pin Abfrage alle 2 Sek im Log ... also das Kistchen geöffnet, Kabel korrigert und anders verlegt und dabei gemerkt, das einer der CI-Slot-Anschlußpins zur Leiterplatte des Duoflex zum Nachbarn verbogen war. Das war es wohl wirklich.
Muß vor ein paar Monaten passiert sein, als die Stromversorgung einer Platte wackelig war und ich Kabel getauscht habe.
Geht also seit heute wieder.
Stefan
-
Fourty2 Solche Meldungen habe ich vor längerer Zeit auch einmal im syslog gefunden, die Ursache war damals Datenmüll aus dem Modul.
Was sagt denn die Info-Datei - gibt es Fehler in der Aufnahme?
10k+ Fehler.
Hatte MTD dann kurz deaktiviert, da waren es dann TS-Cont-Fehler. Bei Empfangsfehlern wolkiger Art hätte/habe ich aber FEC-Fehler dabei - sollte es also nicht sein.
Edit:
Im TV tut das Modul. Also wohl was im DDCi2/Ciplus System struppig. Kernel war es nicht, versuchen wir mal einen VDR-2.6.1.
Stefan
-
Hallo zusammen,
ich hab aus heiterem Himmel sowas hier:
CodeFeb 15 13:20:14 vdr: [18936] ERROR: invalid MTD number (31) in PID 8191 (1FFF) Feb 15 13:20:14 vdr: [18936] ERROR: invalid MTD number (31) in PID 8191 (1FFF) Feb 15 13:20:14 vdr: [18936] ERROR: invalid MTD number (31) in PID 8191 (1FFF) Feb 15 13:20:16 vdr: [18936] ERROR: invalid MTD number (2) in PID 512 (0200) Feb 15 13:20:16 vdr: [18936] ERROR: invalid MTD number (5) in PID 1360 (0550) Feb 15 13:20:16 vdr: [18936] ERROR: invalid MTD number (2) in PID 732 (02DC) Feb 15 13:20:16 vdr: [18936] ERROR: invalid MTD number (28) in PID 7170 (1C02) Feb 15 13:20:16 vdr: [18936] ERROR: invalid MTD number (2) in PID 594 (0252)
Kommt und geht. Es läuft keine Aufnahme. Passierte aber heute morgen auch mit Aufnahmen.
Was könnte das sein?
Stefan
-
Das kommt halt darauf an, welche Quellen man wo wiedergibt und ob der angeschlossene Fernseher das zielsicher automatisch umschalten kann.
Den VDR nutzen wir für Fernsehen und Aufnahmen. Insbesondere per "Himmel" kamen bisweilen (also zumindest zur NVidia-Zeit bis etwa 2017) Daten mit sehr "hellem" Schwarz. Steht die Kette komplett auf Limited-RGB, ist das "helle" Schwarz auch dann schwarz. Daher dort Limited-RGB.
Kodi nutzen wir nur für Bilder, Musik und Musikvideos, nicht als VDR-Backend, da paßt Full-RGB hier besser.
Das ist aber vermutlich auch sehr vom TV abhängig.
Stefan
-
Also bisher funktioniert Dein letzter Patch ... Danke
Das 2 minütige Hin- und Herschalten macht das "VPS" schon immer.
Bei "normalen" Timer-Aufnahmen passiert das nur unsichtbar auf freien Karten.
VPS ist bei mir wegen epg2vdr aus, sonst brechen die Aufnahmen ab, sobald sie in der Datenbank sind.
Muß dem Plugin mal abgewöhnen, an aktiven VPS Timern rumzutogglen.
Stefan
-
Also wenn man Farbwiedergabe vergleichen will, sollte man das Bild vielleicht zuvor Farbkalibrieren.
Unser (Intel J3160) Bild wird immer bewundert. War mit NVidia nicht wirklich anders. Ist allerdings erst seit ungefähr libva2 so, zuvor war das Bild z.B. vom Radio-Plugin ... dürftig.
VDR ist auf RGB-Limited, Kodi Full. Kalibriert.
Stefan
-
Ist ja klar, kaum hab' ich mir V3+a gestern in den GIT-Stand hineingefummelt, gibt es was neues ...
-
Hatte angenommen, fehlende ECM (hier NDS alle 7 sec, ~ 300 ms vor Gültigkeit - falls das noch aktuell ist), würden als Scrambled im Log ankommen, aber stimmt, dann kommt nix, nur Modul abschießen macht "scrambled"-Fehler.
Backref: dies hier
Code
Display More+void cFrameChecker::CheckFrame(const uchar *Data, int Length) +{ + int64_t Pts = TsGetPts(Data, Length); + if (Pts >= 0) { + if (lastPts >= 0) { + int Diff = int(round((PtsDiff(lastPts, Pts) / double(frameDelta)))); + if (Diff > 0) { + if (Diff <= MAX_BACK_REFS) { + if (lastFwdRef > 1) { + if (backRefs != uint32_t((1 << (lastFwdRef - 1)) - 1)) + Report("missing backref");
Ich stopfe das ins VDR-Log, und gucke bei Fehlern schon mal nach, was Ursache war.
Stefan
-
kamel5 :
Habe jetzt Deinen letzten Commit in Master gepacht. Bisher kein Lock Error.
Danke,
Stefan
PS:
Hatte auch die Fehleranzeige (aus 4c4cdb98e662c69d..) probiert, leider sieht man die Fehler nicht, weil die zwei Zeitdauern bereits zuviel Platz brauchen, wenn man das Menü nach goldenem Schnitt teilt.
Habe mir dies daher zur Aufnahmezeit (wie im Original) verschoben, da paßt es besser.
-
Mit der auskommentierten Zeile habe ich es jetzt noch nicht geschafft, einen Deadlock zu erzeugen.
Einmal hat das Modul in die bereits laufende Aufnahme ein paar Backref-Fehler gemacht, einmal die neue Aufnahme mit #750 TS-Fehler begonnen, bevor Bild kam. Aber kein Hänger mehr.
Seiteneffekt bisher (Kurztest, klar) nicht zu endecken. Habe aber auch nur zwei Tuner.
Stefan
-
Das scheint mir prinzipiell noch zu diesem Thread hier zu gehören:
-
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:
Code
Display MoreJan 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
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
Diff
Display More--- 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();
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.
Code
Display MoreJan 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
Stefan
-
Kaum durch den Compiler geschoben, schon veraltet ...
-
Hier nochmal der Deadlock mit -ggdb -O0, wegen Größe komplett als Textdatei anbei.
Code
Display MoreThread 1 - "21315" (gdb) bt #0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:103 #1 0x00007f2ce8ab9714 in __GI___pthread_mutex_lock (mutex=0x5652a3450870) at ../nptl/pthread_mutex_lock.c:80 #2 0x00005652a226dc3c in cMutex::Lock (this=0x5652a3450870) at thread.c:224 #3 0x00005652a219af02 in cThread::Lock (this=0x5652a3450850) at thread.h:94 #4 0x00005652a226e634 in cThreadLock::Lock (this=0x7ffc389a6860, Thread=0x5652a3450850) at thread.c:430 #5 0x00005652a226e5c0 in cThreadLock::cThreadLock (this=0x7ffc389a6860, Thread=0x5652a3450850) at thread.c:417 #6 0x00005652a219541f in cDevice::SetCamSlot (this=0x5652a3450850, CamSlot=0x0) at device.c:450 #7 0x00005652a2180e55 in cCamSlot::Assign (this=0x7f2cd385e260, Device=0x0, Query=false) at ci.c:2546 #8 0x00005652a219a84f in cDevice::Detach (this=0x5652a3450850, Receiver=0x5652bda587b0) at device.c:1844 #9 0x00005652a219a998 in cDevice::DetachAllReceivers (this=0x5652a3450850) at device.c:1867 #10 0x00005652a21aa4fd in cDvbDevice::DetachAllReceivers (this=0x5652a3450850) at dvbdevice.c:2369 #11 0x00005652a2194eda in cDevice::GetDevice (Channel=0x5652a31a3310, Priority=50, LiveView=false, Query=false) at device.c:334 #12 0x00005652a21edb1a in cRecordControls::Start (Timers=0x5652a2367a00 <cTimers::timers>, Timer=0x7f2cd385ce60, Pause=false) at menu.c:5705 #13 0x00005652a228208d in main (argc=74, argv=0x7ffc389a72c8) at vdr.c:1133
Format dann jeweils Sourceausschnitt (soweit vorhanden), lokale Variablen, mutex:
Code(gdb) up #1 0x00007f2ce8ab9714 in __GI___pthread_mutex_lock (mutex=0x5652a3450870) at ../nptl/pthread_mutex_lock.c:80 (gdb) info locals ignore1 = <optimized out> ignore2 = <optimized out> ignore3 = <optimized out> type = <optimized out> __PRETTY_FUNCTION__ = "__pthread_mutex_lock" id = <optimized out>
Code
Display More(gdb) up ¦222 void cMutex::Lock(void) ¦223 { >¦224 pthread_mutex_lock(&mutex); ¦225 locked++; ¦226 } #2 0x00005652a226dc3c in cMutex::Lock (this=0x5652a3450870) at thread.c:224 (gdb) info locals No locals. (gdb) print mutex.__data.__owner $1 = 21773 (gdb) thread find 21773 Thread 41 has target id 'Thread 0x7f2c6d7fa700 (LWP 21773)'
Und entsprechend für Thread 41:
Code
Display MoreThread 41 - "21773" (gdb) bt #0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:103 #1 0x00007f2ce8ab9714 in __GI___pthread_mutex_lock (mutex=0x5652a3453190) at ../nptl/pthread_mutex_lock.c:80 #2 0x00005652a226dc3c in cMutex::Lock (this=0x5652a3453190) at thread.c:224 #3 0x00005652a226e574 in cMutexLock::Lock (this=0x7f2c6d7f9d10, Mutex=0x5652a3453190) at thread.c:404 #4 0x00005652a226e500 in cMutexLock::cMutexLock (this=0x7f2c6d7f9d10, Mutex=0x5652a3453190) at thread.c:391 #5 0x00005652a2199c31 in cDevice::Action (this=0x5652a3450850) at device.c:1701 #6 0x00005652a226e0ed in cThread::StartThread (Thread=0x5652a3450850) at thread.c:293 #7 0x00007f2ce8ab6fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486 #8 0x00007f2ce85ab4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Code
Display More(gdb) up #1 0x00007f2ce8ab9714 in __GI___pthread_mutex_lock (mutex=0x5652a3453190) at ../nptl/pthread_mutex_lock.c:80 (gdb) info locals ignore1 = <optimized out> ignore2 = <optimized out> ignore3 = <optimized out> type = <optimized out> __PRETTY_FUNCTION__ = "__pthread_mutex_lock" id = <optimized out> (gdb) print mutex $19 = (pthread_mutex_t *) 0x5652a3453190
Code
Display More(gdb) up ¦222 void cMutex::Lock(void) ¦223 { >¦224 pthread_mutex_lock(&mutex); ¦225 locked++; ¦226 } #2 0x00005652a226dc3c in cMutex::Lock (this=0x5652a3453190) at thread.c:224 (gdb) info locals No locals. (gdb) print mutex $20 = pthread_mutex_t = {Type = Error check, Status = Acquired, possibly with waiters, Owner ID = 21315, Robust = No, Shared = No, Protocol = None} (gdb) thread find 21315 Thread 1 has target id 'Thread 0x7f2ce820e780 (LWP 21315)' (gdb) print locked $21 = 1
[..]
Code
Display More(gdb) up ¦1691 if (GetTSPacket(b)) { ¦1692 if (b) { ¦1693 // Distribute the packet to all attached receivers: ¦1694 Lock(); ¦1695 cCamSlot *cs = CamSlot(); ¦1696 if (cs) ¦1697 cs->TsPostProcess(b); ¦1698 int Pid = TsPid(b); ¦1699 bool IsScrambled = TsIsScrambled(b); ¦1700 for (int i = 0; i < MAXRECEIVERS; i++) { >¦1701 cMutexLock MutexLock(&mutexReceiver); ¦1702 cReceiver *Receiver = receiver[i]; ¦1703 if (Receiver && Receiver->WantsPid(Pid)) { ¦1704 Receiver->Receive(b, TS_SIZE); ¦1705 // Check whether the TS packet is scrambled: #5 0x00005652a2199c31 in cDevice::Action (this=0x5652a3450850) at device.c:1701 (gdb) info locals MutexLock = {mutex = 0x5652a3453190, locked = false} Receiver = 0x0 i = 0 cs = 0x7f2cd385e260 Pid = 1279 IsScrambled = false b = 0x5652beeb8a78 "G\004\377\027V\251?!\337µ\236\205l?\371dH\374\335\"\f\261\003\324\306h\340p\"\324\365g\355\207\177\200\240e\376\224\362\242\305\067\030\274\006\025\270\223\373\307C'\272hg\277u\2 12\266.(?\022\201\232\352O\227a\207c\225\240\205\262&k\227>(-\024Yk\342\214s\004?/_\212\223\204\217\257a\023?H~9''aHOK\004IE\311\336?\030&" (gdb) print mutex $25 = {mutex = pthread_mutex_t = {Type = Error check, Status = Acquired, possibly with waiters, Owner ID = 21773, Robust = No, Shared = No, Protocol = None}, locked = 1} (gdb) print receiver[0] $26 = (cReceiver *) 0x0 (gdb) print mutexReceiver $27 = {mutex = pthread_mutex_t = {Type = Error check, Status = Acquired, possibly with waiters, Owner ID = 21315, Robust = No, Shared = No, Protocol = None}, locked = 1}
HTH,
Stefan
-
Bisher ein Einzelfall, hab wegen des Deadlock-Problems aber noch nicht versucht, es zu reproduzieren.
Aufzeichnungsmenü ist geteilt (links Aufnahme / rechts Beschreibung), denke also ja.
Einstellungen (setup.conf):
Code
Display Moreskinnopacity.darkgrey.backgroundStyle = 0 skinnopacity.darkgrey.channelBackgroundTransparency = 0 skinnopacity.darkgrey.channelBorderBottom = 15 skinnopacity.darkgrey.channelBorderVertical = 15 skinnopacity.darkgrey.channelFadeTime = 0 skinnopacity.darkgrey.channelHeight = 30 skinnopacity.darkgrey.channelPosterBorder = 4 skinnopacity.darkgrey.channelUseLogoBackground = 0 skinnopacity.darkgrey.discUsageStyle = 1 skinnopacity.darkgrey.epgImageHeight = 281 skinnopacity.darkgrey.epgImageWidth = 375 skinnopacity.darkgrey.fontDetailView = 5 skinnopacity.darkgrey.fontDetailViewSmall = 5 skinnopacity.darkgrey.fontEPGInfoWindow = 4 skinnopacity.darkgrey.fontIndex = 0 skinnopacity.darkgrey.fontMenuitemRecordings = 0 skinnopacity.darkgrey.fontMenuitemRecordingsSmall = 0 skinnopacity.darkgrey.menuChannelLogoBackground = 0 skinnopacity.darkgrey.menuWidthChannels = 38 skinnopacity.darkgrey.menuWidthMain = 38 skinnopacity.darkgrey.menuWidthRecordings = 38 skinnopacity.darkgrey.menuWidthSchedules = 38 skinnopacity.darkgrey.menuWidthSetup = 38 skinnopacity.darkgrey.menuWidthTimers = 38 skinnopacity.darkgrey.messageFadeTime = 0 skinnopacity.darkgrey.narrowTimerMenu = 0 skinnopacity.darkgrey.numDefaultMenuItems = 14 skinnopacity.darkgrey.numRecordingsMenuItems = 7 skinnopacity.darkgrey.numSchedulesMenuItems = 7 skinnopacity.darkgrey.progressCurrentSchedule = 1 skinnopacity.darkgrey.replayFadeTime = 0 skinnopacity.darkgrey.showDiscUsage = 0 skinnopacity.darkgrey.tracksFadeTime = 0 skinnopacity.darkgrey.volumeFadeTime = 0
/var/lib/vdr/plugins/skinnopacity als Anlage
Stefan
-
Das weiß ich auch nicht (hat Klaus aber 2014, VDR 2.1.x, so programmiert).
Der VDR hing, nachdem der ListLock-Fehler im Markad Plugin (läuft im Hauptthread) beseitigt war, zuverlässig an dieser Stelle. Das tat er gelegentlich schon seit längerer Zeit (2.4.5 +/-). Bisher hatte ich das Modul in Verdacht, aber habe mal den Debuger angeklemmt.
Der fand den VDR wartend, was erklärte, das alles, was im Haupthread mitlief (markad, Live, ...) hing, und anderes mit extra Thread halt weiter machte (vaapi - nur ohne Bild, epg2vdr, ..).
Hab dann ermittelt, wer die Mutex besitzt - und etwas später, warum auch der Besitzer der Mutex wartete.
Deadlock, klar. Hab dann geguckt, wo Thread 1 die Mutex holt und diese Warteposition von Thread 1 als erst einmal doppelten Mutexlock empfunden (und zunächst auskommentiert).
Damit klappt dann natloses Umschalten zwischen Timern (A/B) und bei PID Update wieder. Allerdings scheint er mir jetzt gelegentlich beim Timerende zwei Gedenkminuten einzufügen - muß aber nicht zusammenhängen.
(Reicht ja schon, das epg2vdr bei jeder Aufnahmeänderung (Neu, Ändern, Löschen) für ca 1,5 Minuten Channels und Recordings (und je Aufnahme kurz Schedules) readlockt, um alle 5000+ Aufnahmen durchzutackern und ein Plugin im Haupthread auf die Listen wartet.)
Stefan
-
Hallo HelmutB ,
ja sicher sind die Mutexe unterschiedlich:
Thread 1 hat die Mutex A, auf die Thread 40 wartet.
Thread 40 hat die Mutex B, auf die Thread 1 wartet.
Wie beim Online-Neukundengeschäft:
Der Verkäufer hat die Ware und will Vorkasse.
Der Kunde das Geld und will erst nach Erhalt der Ware zahlen.Irgendwann schreitet dann eine Frau ein (VDR Watchdog) und will Geld und Ware, vorher tut sich nix.
Die Optimierung (-march=native -O3, Quadcore) könnte man natürlich ausschalten, ob der Fehler dann noch auftritt, werde ich prüfen.
Hab mal den Watchdog auf 10 Minuten gesetzt, damit ich per Zweitsystem den Debugger an laufen bekomme, sobald der VDR nicht mehr mag: immer diese Stelle bisher.
Ohne LOCK_THREAD gab es bis jetzt (trotz der beiden VDR-2.5 Patche) keine Umschalt-Probleme mehr.
Stefan
-
Was seit dem letzten Update anders ist:
Das langsame Ausblenden des OSD arbeitet wieder (weiß garnicht mehr, wann das zuletzt funktionierte),
Stefan