Vielleicht spielt die Startreihenfolge der Plugins eine Rolle!? Ich hatte ähnliche Probleme vor 1 Jahr, hatte diese aber auf ein zu schlechtes Netzteil für den Raspberry schließen können....
Ich habe aktuell erst das Ausgabe Plugin (rpihddevice), dann das OSD Teletext Plugin und dann das satip Plugin konfiguriert. Seit Monaten läuft nun auch das OSD Teletext Plugin ohne Probleme mit raspberry.
ring buffer overflows -> cDevice::Detach() blockiert...
-
-
iNOB ja das ist klar und auch logisch. Ohne Anwender ist ja auch die beste Software nichts wert, und deren Erfahrung ist das A und O zum Erfolg.
Uwe: das osdteletext plugin hatte ich heute morgen mal deaktiviert, dieses hat ja auch einen cReceiver-Thread, oder sogar mehrere, am laufen. Mit einem Skript, dass alle 5 Sekunden den Kanal wechselt hat es nun sehr lange gedauert, bis wieder ein deadlock und dan ring buffer offerflows passieren. Es hat also schon mit den cReceiver-Threads etwas zu tun. Aber somit ist es trotzdem nicht das osdteletext Plugin allein. Ich vermute ein Prinzipielles Problem, dass mit dem Handling des cThread Mutex zusammenhängt.
Da ist nun wirklich jemand gefordert, der da den ganzen Durchblick hat...
Gruss, und vielen Dank an alle die Mithelfen.
Xcoder -
Ich habe in device.c noch log Meldungen eingebaut und den Kanal alle 5 Sekunden gewechselt. Nach x-mal umschalten steckte es wie im oben imgdb backtrace zu sehen in cDevice::Detach()->cMutexLock::Lock()->cMutex::Lock() fest.
Code
Alles anzeigenMay 14 09:28:32 core vdr: [20817] DDDDD AttachReciever: attaching receiver 0 (0x391da10) finish May 14 09:28:32 core vdr: [5824] device 1 receiver thread ended (pid=20817, tid=5824) May 14 09:28:32 core vdr: [5826] device 1 receiver thread started (pid=20817, tid=5826, prio=high) May 14 09:28:32 core vdr: [20817] DDDDD AttachReciever: attaching receiver 1 (0x37f4680) start May 14 09:28:32 core vdr: [20817] DDDDD AttachReciever: attaching receiver 1 (0x37f4680) finish May 14 09:28:37 core vdr: [20817] DDDDD Detach: detaching receiver 0 (0x391da10) start May 14 09:28:37 core vdr: [20817] DDDDD Detach: detaching receiver 0 (0x391da10) finish May 14 09:28:37 core vdr: [20817] DDDDD Detach: detaching receiver 1 (0x37f4680) start May 14 09:28:37 core vdr: [20817] DDDDD Detach: detaching receiver 1 (0x37f4680) finish May 14 09:28:37 core vdr: [5826] device 1 receiver thread ended (pid=20817, tid=5826) May 14 09:28:37 core vdr: [20817] DDDDD AttachReciever: attaching receiver 0 (0x14cdb60) start May 14 09:28:37 core vdr: [20817] DDDDD AttachReciever: attaching receiver 0 (0x14cdb60) finish May 14 09:28:37 core vdr: [5857] device 1 receiver thread started (pid=20817, tid=5857, prio=high) May 14 09:28:37 core vdr: [20817] DDDDD AttachReciever: attaching receiver 1 (0x391da10) start May 14 09:28:37 core vdr: [20817] DDDDD AttachReciever: attaching receiver 1 (0x391da10) finish May 14 09:28:37 core vdr: [20817] DDDDD Detach: detaching receiver 0 (0x14cdb60) start May 14 09:28:37 core vdr: [20817] DDDDD Detach: detaching receiver 0 (0x14cdb60) finish May 14 09:28:37 core vdr: [20817] DDDDD AttachReciever: attaching receiver 0 (0x14cdb60) start May 14 09:28:37 core vdr: [20817] DDDDD AttachReciever: attaching receiver 0 (0x14cdb60) finish May 14 09:28:37 core vdr: [20817] DDDDD AttachReciever: attaching receiver 2 (0x37f4680) start May 14 09:28:37 core vdr: [20817] DDDDD AttachReciever: attaching receiver 2 (0x37f4680) finish May 14 09:28:37 core vdr: [20817] DDDDD Detach: detaching receiver 0 (0x14cdb60) start May 14 09:28:37 core vdr: [20817] DDDDD Detach: detaching receiver 0 (0x14cdb60) finish May 14 09:28:37 core vdr: [20817] DDDDD AttachReciever: attaching receiver 0 (0x14cdb60) start May 14 09:28:37 core vdr: [20817] DDDDD AttachReciever: attaching receiver 0 (0x14cdb60) finish May 14 09:28:38 core vdr: [5857] DDDDD Detach: detaching receiver 0 (0x14cdb60) start May 14 09:28:38 core vdr: [5857] DDDDD Detach: detaching receiver 0 (0x14cdb60) finish May 14 09:28:38 core vdr: [5857] DDDDD AttachReciever: attaching receiver 0 (0x14cdb60) start May 14 09:28:38 core vdr: [5857] DDDDD AttachReciever: attaching receiver 0 (0x14cdb60) finish May 14 09:28:42 core vdr: [20817] DDDDD Detach: detaching receiver 1 (0x391da10) start May 14 09:28:42 core vdr: [20817] DDDDD Detach: detaching receiver 1 (0x391da10) finish May 14 09:28:42 core vdr: [20817] DDDDD Detach: detaching receiver 0 (0x14cdb60) start May 14 09:28:42 core vdr: [20817] DDDDD Detach: detaching receiver 0 (0x14cdb60) finish May 14 09:28:42 core vdr: [20817] DDDDD AttachReciever: attaching receiver 0 (0x14cdb60) start May 14 09:28:42 core vdr: [20817] DDDDD AttachReciever: attaching receiver 0 (0x14cdb60) finish May 14 09:28:42 core vdr: [20817] DDDDD Detach: detaching receiver 2 (0x37f4680) start May 14 09:28:42 core vdr: [20817] DDDDD Detach: detaching receiver 2 (0x37f4680) finish May 14 09:28:42 core vdr: [20817] DDDDD Detach: detaching receiver 0 (0x14cdb60) start
Hier der Ausschnitt mit meinem Log-Code in cDevice::Detach():
Code
Alles anzeigenif (receiver[i] == Receiver) { esyslog("DDDDD Detach: detaching receiver %d (%p) start", i, Receiver); Lock(); receiver[i] = NULL; Receiver->device = NULL; Unlock(); Receiver->Activate(false); for (int n = 0; n < Receiver->numPids; n++) DelPid(Receiver->pids[n]); esyslog("DDDDD Detach: detaching receiver %d (%p) finish", i, Receiver); } else if (receiver[i]) receiversLeft = true;
Wie kann ich was sonst noch mit dem Mutex vom receiver 0 device abhängt und diesen zu diesem Zeitpunkt lockt?
Gruss, Xcoder
-
vdr-2.2.0 ist ja schon etwas älter, und es gibt da einige Patche dafür.
Ich habe da z.B.
Fix_TS_buffer_thread_high_CPU_usage.diff
vdr-2.1.6-emmtime.diff
vdr-2.2.0-caid_buffer-v2.diff
vdr-clear-pids.diff
Vermutlich hier aus dem Forum und auch von der VDR Mailing Liste.
Der letzte könnte eventuell was mit deinem Problem zu tun haben, probier‘s einfach mal aus.Sonst wäre noch die Frage, ob er nur bei bestimmten Sendern crasht.
-
jrie Leider ohne Einfluss. Da ich das satip Plugin und minisatip nutze, sehe ich auch gut, dass die PIDs i.O. sind. Habe den Path eingespielt aber dieser hat keinen Einfluss.
Ich denke ich habe nun die Threads isoliert welche sich gleichzeitig locken. Mit aktive osdteletext kommt der Fehler viel schneller. Nun hier der Backtrace der involvierten Threads. Der Pointer 0x2048660 ist das betreffende cThread Objekt und sowohl in Thread 1 und 159 vorhanden.
Code
Alles anzeigenThread 159 (Thread 0x7f19527fc700 (LWP 13566)): #0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x00007f19fd668b05 in __GI___pthread_mutex_lock (mutex=mutex@entry=0x204af40) at ../nptl/pthread_mutex_lock.c:81 #2 0x000000000050b4a9 in cMutex::Lock (this=0x204af40) at thread.c:193 #3 0x000000000050ba4f in cMutexLock::Lock (this=0x7f19527fbbe0, Mutex=<optimized out>) at thread.c:373 #4 0x0000000000483eff in cDevice::Detach (this=this@entry=0x2048660, Receiver=Receiver@entry=0x2d8e3c0) at device.c:1697 #5 0x00000000004740a1 in cCaPidReceiver::Receive (this=0x2d8e3c0, Data=<optimized out>, Length=<optimized out>) at ci.c:213 #6 0x00000000004870a7 in cDevice::Action (this=0x2048660) at device.c:1617 #7 0x000000000050b8b9 in cThread::StartThread (Thread=0x2048660) at thread.c:262 #8 0x00007f19fd666454 in start_thread (arg=0x7f19527fc700) at pthread_create.c:334 #9 0x00007f19fc010eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 44 (Thread 0x7f19dffa2700 (LWP 12312)): #0 cRingBuffer::ReportOverflow (this=0x204b970, Bytes=188) at ringbuffer.c:102 #1 0x00007f19f8d2e5e8 in cSatipDevice::WriteData (this=0x2048660, bufferP=0x20552fc "G\001\366\226\340U\324", <incomplete sequence \324>, lengthP=1316) at device.c:436 #2 0x00007f19f8d40244 in cSatipTuner::ProcessVideoData (this=0x204bac0, bufferP=0x20552fc "G\001\366\226\340U\324", <incomplete sequence \324>, lengthP=1316) at tuner.c:284 #3 0x00007f19f8d34fce in cSatipRtp::Process (this=0x204bc58) at rtp.c:135 #4 0x00007f19f8d34724 in cSatipPoller::Action (this=0x203ee40) at poller.c:88 #5 0x000000000050b8b9 in cThread::StartThread (Thread=0x203ee40) at thread.c:262 #6 0x00007f19fd666454 in start_thread (arg=0x7f19dffa2700) at pthread_create.c:334 #7 0x00007f19fc010eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1 (Thread 0x7f19fdc508c0 (LWP 12306)): #0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x00007f19fd668b05 in __GI___pthread_mutex_lock (mutex=mutex@entry=0x2048680) at ../nptl/pthread_mutex_lock.c:81 #2 0x000000000050b4a9 in cMutex::Lock (this=this@entry=0x2048680) at thread.c:193 #3 0x0000000000483f77 in cThread::Lock (this=0x2048660) at thread.h:92 #4 cDevice::Detach (this=<optimized out>, Receiver=0x2d8e3c0) at device.c:1702 #5 0x000000000047765f in cCamSlot::SendCaPmt (this=0x2d8e0d0, CmdId=<optimized out>) at ci.c:2025 #6 0x00007f19f91755a9 in SCCAMSlot::StartDecrypting() () from /usr/lib/vdr/plugins/libvdr-dvb....so.2.2.0 #7 0x000000000048403d in cDevice::Detach (this=<optimized out>, Receiver=0x2e1b450) at device.c:1717 #8 0x00007f19f31efb2c in cTxtReceiver::~cTxtReceiver() () from /usr/lib/vdr/plugins/libvdr-osdteletext.so.2.2.0 #9 0x00007f19f31efbf9 in cTxtReceiver::~cTxtReceiver() () from /usr/lib/vdr/plugins/libvdr-osdteletext.so.2.2.0 #10 0x00000000005032f2 in cStatus::MsgChannelSwitch (Device=0x2d73b10, ChannelNumber=0, LiveView=true) at status.c:41 #11 0x0000000000485ff4 in cDevice::SetChannel (this=this@entry=0x2d73b10, Channel=Channel@entry=0x1e2a8c0, LiveView=LiveView@entry=true) at device.c:749 #12 0x0000000000486490 in cDevice::SwitchChannel (this=0x2d73b10, Channel=0x1e2a8c0, LiveView=LiveView@entry=true) at device.c:703 #13 0x000000000047091b in cChannels::SwitchTo (this=<optimized out>, Number=<optimized out>) at channels.c:991 #14 0x000000000046d3aa in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1355
Aber da habe ich immer noch nicht wirklich den Durchblick...
-
Das heisst aber erstmal nur, dass osdteletext da ein Problem hat.
Weitaus interessanter wäre so ein backtrace ohne dass osdteletext läuft.Und wegen des Zürcher Senders empfehle ich:
Diff
Alles anzeigen--- a/device.c +++ b/device.c @@ -1566,7 +1566,7 @@ bool cDevice::Receiving(bool Dummy) const return false; } -#define TS_SCRAMBLING_TIMEOUT 3 // seconds to wait until a TS becomes unscrambled +#define TS_SCRAMBLING_TIMEOUT 60 // seconds to wait until a TS becomes unscrambled #define TS_SCRAMBLING_TIME_OK 10 // seconds before a Channel/CAM combination is marked as known to decrypt void cDevice::Action(void)
-
Habe ich auch gedacht. Dann konnte ich das Problem aber auch ohne osdteletext reproduzieren... einfach mit leicht anderem backtrace. Das Problem bleibt aber, dass sich zwei Threads jeweils in einem Detach gegenseitig blockieren. Der eine Thread (jeweils #1) wartet in pthread_mutex_lock() auf einen mutex dessen owner ein anderer Thread ist, und dieser macht das umgekehrte...
Momentan kann ich das Problem gerade nicht mehr reproduzieren, die Plugins femon, osdteletext, play und streamdev-server sind nicht installiert, dvb-api, satip, epgsearch, skindesigner, softhddevice, live und permashift sind aktiv. Der VDR schaltet nun seit 1h ohne deadlock von von Sender zu Sender... Eines der 4 noch nicht aktivierten wird es dann wohl sein.
-
Momentan kann ich das Problem gerade nicht mehr reproduzieren, die Plugins femon, osdteletext, play und streamdev-server sind nicht installiert, dvb-api, satip, epgsearch, skindesigner, softhddevice, live und permashift sind aktiv. Der VDR schaltet nun seit 1h ohne deadlock von von Sender zu Sender... Eines der 4 noch nicht aktivierten wird es dann wohl sein.Da ich das Problem, besonders bei laufenden Aufnahmen, auch habe:
Bei mir sind von den deaktivierten nur osdteletext (derzeit deaktiviert, Fehler bleibt) und femon installiert.Grüße,
42 -
Oder dann doch nicht... Es ist wirklich zum verzweifeln. Nachdem permashift als Quelle schon ausgeschlossen hatte, ca 1h alle 5 sec Sender umschalten, kam es nun doch wieder zum deadlock. Aus dem Backtrace sieht man, dass 2 Threads auf einen mutex warten:
ZitatThread 499 (Thread 0x7f8aeeffd700 (LWP 8711)):
#0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x00007f8b53393b05 in __GI___pthread_mutex_lock (mutex=mutex@entry=0xcf3e30) at ../nptl/pthread_mutex_lock.c:81
#2 0x000000000050ac79 in cMutex::Lock (this=0xcf3e30) at thread.c:193
#3 0x000000000050b21f in cMutexLock::Lock (this=0x7f8aeeffcbd0, Mutex=<optimized out>) at thread.c:373
#4 0x0000000000484568 in cDevice::Detach (this=this@entry=0xcf1550, Receiver=Receiver@entry=0x15da770) at device.c:1690
#5 0x00000000004743c1 in cCaPidReceiver::Receive (this=0x15da770, Data=<optimized out>, Length=<optimized out>) at ci.c:213
#6 0x000000000048643b in cDevice::Action (this=0xcf1550) at device.c:1614
#7 0x000000000050b089 in cThread::StartThread (Thread=0xcf1550) at thread.c:262
#8 0x00007f8b53391454 in start_thread (arg=0x7f8aeeffd700) at pthread_create.c:334
#9 0x00007f8b51d3beed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109Thread 1 (Thread 0x7f8b5397c8c0 (LWP 31384)):
#0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x00007f8b53393b05 in __GI___pthread_mutex_lock (mutex=mutex@entry=0xcf1570) at ../nptl/pthread_mutex_lock.c:81
#2 0x000000000050ac79 in cMutex::Lock (this=this@entry=0xcf1570) at thread.c:193
#3 0x00000000004845b1 in cThread::Lock (this=0xcf1550) at thread.h:92
#4 cDevice::Detach (this=<optimized out>, Receiver=Receiver@entry=0x15da770) at device.c:1693
#5 0x0000000000477bc6 in cCamSlot::SendCaPmt (this=this@entry=0x15da480, CmdId=CmdId@entry=4 '\004') at ci.c:2068
#6 0x000000000047802b in cCamSlot::StopDecrypting (this=0x15da480) at ci.c:2207
#7 0x00000000004759e1 in cCamSlot::Assign (this=0x15da480, Device=Device@entry=0x0, Query=Query@entry=false) at ci.c:1780
#8 0x0000000000484668 in cDevice::Detach (this=<optimized out>, Receiver=0xa5c8000) at device.c:1708
#9 0x00007f8b378d5ba7 in cBufferReceiver::~cBufferReceiver() () from /usr/lib/vdr/plugins/libvdr-permashift.so.2.2.0
#10 0x00007f8b378d5cb9 in cBufferReceiver::~cBufferReceiver() () from /usr/lib/vdr/plugins/libvdr-permashift.so.2.2.0
#11 0x00007f8b378d4e59 in cPluginPermashift::StopLiveRecording() () from /usr/lib/vdr/plugins/libvdr-permashift.so.2.2.0
#12 0x0000000000502a72 in cStatus::MsgChannelSwitch (Device=0x15d0a10, ChannelNumber=0, LiveView=true) at status.c:41
#13 0x0000000000485924 in cDevice::SetChannel (this=this@entry=0x15d0a10, Channel=Channel@entry=0xad3400, LiveView=LiveView@entry=true)
at device.c:749
#14 0x0000000000485d90 in cDevice::SwitchChannel (this=0x15d0a10, Channel=0xad3400, LiveView=LiveView@entry=true) at device.c:703
#15 0x0000000000470bcb in cChannels::SwitchTo (this=<optimized out>, Number=<optimized out>) at channels.c:991
#16 0x000000000046d64f in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1355Der owner des jeweiligen mutex ist der andere Thread:
Zitat$1 = (pthread_mutex_t *) 0xcf1570
$2 = {__data = {__lock = 2, __count = 0, __owner = 8711, __nusers = 1, __kind = 2, __spins = 0, __elision = 0, __list = {__prev = 0x0,
__next = 0x0}}, __size = "\002\000\000\000\000\000\000\000\a\"\000\000\001\000\000\000\002", '\000' <repeats 22 times>, __align = 2}$3 = (pthread_mutex_t *) 0xcf3e30
$4 = {__data = {__lock = 2, __count = 0, __owner = 31384, __nusers = 1, __kind = 2, __spins = 0, __elision = 0, __list = {__prev = 0x0,
__next = 0x0}}, __size = "\002\000\000\000\000\000\000\000\230z\000\000\001\000\000\000\002", '\000' <repeats 22 times>, __align = 2}Eine Gemeinsamkeit ist, dass es jeweils in Thread #1 bis MsgChannelSwitch() geht, ab da kommt dann offenbar eine Methode aus einem beliebigen Plugin. Daher könnte es doch um ein prinzipielles VDR Problem gehen und ist nicht spezifisch für ein bestimmtes Plugin.
Ideen wie man das weiter eingrenzt?
Gruss, Xcoder
-
bei jedem Thread der neu erzeugt wird, dh. jedem Plugin und jedem thread in vdr selbst, im constructor dessen Adresse ausprinten.
Dann kannst du anhand der Pointer Adressen sehen wer sich gegenseitig aufhängt.
Interessant sind nur die Plugins und Threads, die Daten von einem (DVB-) Device holen.Ist nat. beliebig aufwändig.
-
Moin,
bei jedem Thread der neu erzeugt wird, dh. jedem Plugin und jedem thread in vdr selbst, im constructor dessen Adresse ausprinten.
oder alternativ den Debug Output in der Start Funktion von cThread anpassen...oder besser vor der Abfrage, ob der Thread eine Description hat, einen weiteren Debug Output einfügen. Am besten so:Code+dsyslog("starting thread, pointer %p", Thread); if (Thread->description) { dsyslog("%s thread started (pid=%d, tid=%d, prio=%s)", Thread->description, getpid(), Thread->childThreadId, Thread->lowPriority ? "low" : "high");
Ciao Louis
-
ich würde
.. %p", this);
bevorzugen.
-
ich würde
.. %p", this);
bevorzugen.
Hm, wenn ich mir diese Zeile so anschaue, dann kommt das aufs gleiche rausCiao Louis
-
By the way...ich habe zwar ein komplett anderes Setup (siehe Signatur, direkt eingebauter DVB-C Tuner), aber meine Frau schafft es auch mal ab und an, durch wildes Zappen den VDR in eine Deadlock Situation zu befördern. Da das aber extrem selten passiert (vielleicht einmal alle 4 Wochen bei sehr schnellem mehrfachem Umschalten), habe ich mich noch nicht so wirklich mit dem debugging beschäftigt. Beim letzten mal habe ich den VDR mit "killall -SIGSEGV vdr" abgeschossen, der VDR auf meinem Prod System ist aber ohne Debug Symbole gebaut. Deshalb war der coredump nicht so wirklich hilfreich. Wenn ich mich aber recht erinnere, war der Deadlock an einer ähnlichen Stelle...
Ciao Louis
-
der VDR auf meinem Prod System ist aber ohne Debug Symbole gebaut
Der vdr muss nicht mit Debug-Symbolen gebaut sein, die kann man beim Bauen auch in eine extra Datei extrahieren, so dass gdb sie wiederfindet und benutzen kann, das Programm selbst aber trotzdem kleiner bleibt. Müsstest du mal gucken, wie das unter gentoo funktioniert, bei Debian kann man die Symbole automatisch in ein dbg-Paket verschieben, welches man bei Bedarf installieren kann.Die werden dann unter /usr/lib/debug/.build-id/... abgelegt.
Lars.
-
Ich weis ja, welche beiden Threads sich gegenseitig blockieren: es ist der main-Thread #1 und der jeweilige receiver Thread desjenigen Devices welches das Live Signal empfängt. Die Frage ist doch, wieso haben 2 Threads eine Referenz auf ein fremdes cThread Objekt und führe dessen Methode Lock() aus... Wenn das zufällig gleichzeitig passier, dann gibt es einen klassischen Deadlock.
louis: das bestärkt mich in der Ansicht, dass es nicht an einem bestimmten Plugin liegen könnte, sondern am Design der Klassenhierarchie des VDR selber. Wenn ich bei mir alle gewünschten Plugins aktiviere, passiert es zu oft. Aber auch eher beim schnellen zappen, gelegentlich aber auch spontan beim ersten Umschalten nachdem stundenlang der selbe Sender lief. Es ist wohl reiner Zufall, passiert aber vermutlich öfter, wenn viele cReceiver Objekte in cDevice->receiver[] registriert sind (passiert in cDevice::AttachReceiver()). Eventuell hängt es ja sogar von der Hardware ab, wie oft es dazu kommen kann.
Leider fehlt es mir da immer noch am Durchblick wie das zustande kommt. Schaut man sich nur schon mal den Backtrace an, sieht man um wie viele Ecken es da geht. Es ist schon ein ziemliches Gewimmel an Klassen und Methoden...
Gruss, Xcoder
-
Hi, some time ago I looked at this propblem. Didn't fully understand it, but according to my documentation from then I believe:
The main thread is busy detaching receivers. ( void cDevice::Detach(cReceiver *Receiver in device.c)
holding mutexreceiver and doing a Lock()Another thread is doing "Distribute the packet to all attached receivers" (device.c 1605)
If you put a delay after the lock at line 1606 you will see the deadlock very fast.At this time I am not shure if this is the problem, but maybe worth investigating.
As a bypass I put a "cMutexLock MutexLock(&mutexReceiver);" before the Lock() in line 1605, this problem seems to be gone,
but now I somethimes have lock problems with the streamdev plugin (but not very often) , so this is not a real solution.
Greetings Rene -
As a bypass I put a "cMutexLock MutexLock(&mutexReceiver);" before the Lock() in line 1605, this problem seems to be gone
With that I get sometimes a black screen after channel switch (no streamdev involved). -
Also put a { before the mutexlock and a } after the Lock, to free the mutex.
I forgot to tell you this, sorry -
The way I understand you, that does not make sense to me.
So why don't you send a patch or a piece of code?
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!