device.c.5.diff ist doch keine Lösung dafür.
Denn die Ursache ist:
AttachReceiver() hält den mutexReceiver und stoppt nach AddPid() am cCamSlot-mutex.
In cCiAdapter::Action() wird der cCamSlot-mutex gehalten, und Detach() stoppt am mutexReceiver.
=> deadlock
Um das zu lösen, muss man tiefer im VDR-Code drin sein, als ich es bin.
Möglicherweise muss die ganze mutexReceiver Sache noch mal von Grund auf neu überdacht werden.
So lange bleibt es bei device.c.4.diff.
Jo, jedenfalls danke. Mit der v4 konnte ich bei mir keinen Absturz mehr feststellen. Vorher war das bei wildem Rumgezäppe und gleichzeitigem Aufnehmen Stand der Dinge, dass die Mühle sich verabschiedet hat.
...
Um das zu lösen, muss man tiefer im VDR-Code drin sein, als ich es bin.
Möglicherweise muss die ganze mutexReceiver Sache noch mal von Grund auf neu überdacht werden.
Wenn doch jetzt die Situation von @jfie genau analisiert ist, könnte sich denn da nicht mal der ursprüngliche Author der Sache annehmen? Von wem stammt dieser Code? Bei mir sorgt das fast täglich für einen Hänger da ich praktisch nur die verschlüsselten CH Sender schaue.
Gruss, Xcoder
Bis Klaus mal dazu kommt, ist deine einzige Option, die Plugins mit Receivern wegzulassen, also osdteletext, permashift etc.
Ich bin auch viel auf diesen Sendern, und bei mir knallt es praktisch nie.
Seit welcher VDR-Version besteht denn etwa das Problem?
Bzw. andersherum gefragt:
Ich bin momentan noch auch 2.0.7, benutze osdteletext und habe keine Probleme.
Besteht die Gefahr, dass mich das mach einem Update auf 2.2.x erwischt?
Besteht dieses Problem in Version 2.3.4 immer noch?
Klaus
Also bei mir ist das in den paar Tagen seit Umstellung des einen Geräts von VDR 2.2.0 auf VDR 2.3.4 nicht mehr aufgetreten.
Gruß
Frank
Hi, I switched to vdr 2.3.8 a week ago.
But unfortunately I have hit a deadlock again possibly related to the above.
I attached a backtrace of the two threads involved
Greetings Rene
Hi, after a few weeks I have had the same lock about 3 times.
I still believe it is related to the above.
A little investigation:
Thread one:
cTransfer::~cTransfer transfer.c:22 = cReceiver::Detach();
cReceiver::Detach receiver.c:128 = device->Detach(this);
cDevice::Detach device.c:1822 = camSlot->Assign(NULL); locking cCamslot &mutex !!!!
cCamSlot::Assign ci.c:2162 = assignedDevice->Detach(caPidReceiver)
cDevice::Detach device.c:1807 = Lock()
Thus waiting for device lock
Thread two:
cDevice::Action device.c:1678 = Receiver->Receive(b, TS_SIZE);
This is holding the device lock during "Distribute the packet to all attached receivers:"
cCaPidReceiver::Receive ci.c:217 = AddEmmPid(EmmPid);
cReceiver::AddPid receiver.c:49 = device->AddPid(Pid);
cDevice::AddPid device.c:598 = camSlot->SetPid(Pid, true);
waiting for cCamslot mutex
Greetings Rene
Hi Rene,
sorry it's been a while ;-).
Please take a look at the attached patch.
I believe the Lock()/Unlock() in cDevice::AttachReceiver() and cDevice::Detach() is superfluous, because the receiver[] list is already protected by mutexReceiver, which is held in both cases. Consequently we need to hold mutexReceiver in cDevice::Action() now, too, but this seems only natural, because now every access to receiver[] is protected only by mutexReceiver, and we totally avoid the deadlock in waiting for the device lock.
Klaus
Looks like this still needs some more consideration - I had two crashes today when recordings started.
I'll look into this...
Klaus
The lock on mutexReceiver was apparently held too long in cDevice::Detach().
The attached patch (which replaces the previous one) now seems to work.
The question now is, whether it also fixes the initial problem reported in this thread...
Klaus
Hi Klaus,
Thanks for looking at this.
I will patch my vdr, and let you know the results.
However that can take a while, my last lock was about 3 weeks ago 
Greetings Rene
The question now is, whether it also fixes the initial problem reported in this thread...
I will check asap. With the osdteletex-plugin the deadlock appeared rather reliable.
BTW, very nice that this bug is treated now.
Gruss, Xcoder
I expirienced the following Issue with the applied patch vdr-2.3.8-fixdevicedetachlock-2.diff:
During a recording is running:
New vnsi clients are not able to get the channel list from vnsiserver the first entry is recived then it waits.
Existings clients a not able to switch channels it waits for a stream.
The recording keeps running, the programmed end time is not respected anymore.
VDR needs to get restarted.
After removing this patch anything is working as it should.
Gruß RHS
My system is vdr-2.3.8 with satip live dvbapi and vnsiserver plugins.
Must be a problem in the vnsi plugin, since this patch doesn't change anything in the area of channels.
Klaus
I have a second Problem with the vdr-2.3.8-fixdevicedetachlock-2 Patch. If I use the patch, the streamdev client on a Rapberry PI can not switch the channel.
A VDR streamdev client of the same sources on a x86 PC don't has this issue.
Hi,
It is now more then 4 weeks ago, that I applied the patch.
Since then no deadlock 
N.B. I also have 3 RPI's with mpd as streamdev client, all working as expected.
So fingers crossed.
Greetings Rene
Hi,
The question now is, whether it also fixes the initial problem reported in this thread...
I did now a backport to vdr-2.2 and it seems to work well. Multiple recordings, streamdev operation, PiP, no problem so far.
Originally I had often lockups when using the osdteletext-plugin. Even when the osdteletext is started there is no lockup. But the osdteletext does not work but this seems to be related to softhddevice-openglosd which I use in the meantime.
Here the vdr-2.2.0 backported version of the patch from kls:
--- ../vdr-2.2.0.orig/device.c 2018-02-11 20:19:14.000000000 +0100
+++ device.c 2018-02-11 20:11:41.842012116 +0100
@@ -1604,6 +1604,7 @@
// Distribute the packet to all attached receivers:
Lock();
for (int i = 0; i < MAXRECEIVERS; i++) {
+ cMutexLock MutexLock(&mutexReceiver);
if (receiver[i] && receiver[i]->WantsPid(Pid)) {
if (DetachReceivers && cs && (!cs->IsActivating() || receiver[i]->Priority() >= LIVEPRIORITY)) {
dsyslog("detaching receiver - won't decrypt channel %s with CAM %d", *receiver[i]->ChannelID().ToString(), CamSlotNumber);
@@ -1666,10 +1667,8 @@
}
}
Receiver->Activate(true);
- Lock();
Receiver->device = this;
receiver[i] = Receiver;
- Unlock();
if (camSlot && Receiver->priority > MINPRIORITY) { // priority check to avoid an infinite loop with the CAM slot's caPidReceiver
camSlot->StartDecrypting();
startScrambleDetection = time(NULL);
@@ -1687,13 +1686,11 @@
if (!Receiver || Receiver->device != this)
return;
bool receiversLeft = false;
- cMutexLock MutexLock(&mutexReceiver);
+ mutexReceiver.Lock();
for (int i = 0; i < MAXRECEIVERS; i++) {
if (receiver[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]);
@@ -1701,6 +1698,7 @@
else if (receiver[i])
receiversLeft = true;
}
+ mutexReceiver.Unlock();
if (camSlot) {
if (Receiver->priority > MINPRIORITY) { // priority check to avoid an infinite loop with the CAM slot's caPidReceiver
camSlot->StartDecrypting();vdr-2.2.0-fixdevicedetachlock-2.diff
Cheers
Don’t have an account yet? Register yourself now and be a part of our community!