search

manio / vdr-plugin-dvbapi

VDR dvbapi plugin for use with OSCam
http://www.streamboard.tv/wbb2/thread.php?threadid=40060
GNU General Public License v2.0
58 stars 25 forks source link

VDR crash issues when decoding two channels from different transponders #146

Closed STPKITT closed 1 year ago

STPKITT commented 1 year ago

Hi, I'm running all this on the MiniDVBLinux Distribution aka MLD 5.5. VDR version is 2.6.4, dvbapi is 2.2.6-GIT-v222 (that's what's shown in VDR's OSD). I had the exact same issue 3 years ago (so with older versions of the software components) and gave up thinking over time those bugs will get ironed out, but here I am with a freshly setup system experiencing the exact same issue again. No issue on the same hardware when it's running a several years old easyVDR installation. When recording an encrypted channel I can start another recording of an encrypted channel on the same transponder without any issue. However when I'm recording an encrypted channel and I start a parallel recording of another encrypted channel on a different transponder VDR chrashes, no matter if the frontend in use is softhddevice or Kodi and no matter the provider of the encrypted channels involved. Sometimes the crash already happens when I switch to that other channel without starting to record it. The error in the log is either Magick: abort due to signal 11 (SIGSEGV) "Segmentation Fault"... or Magick: abort due to signal 6 (SIGABRT) "Abort"...

In the VDR log I found often appearing:

`Apr 11 20:14:57 MLD user.err vdr: [12805] DVBAPI-Error: Decrypt: set_FastECM_CW_Parity MUST WAIT parity:1 pid:1791 keyindex:1 adapter:0 len:172021

Apr 11 20:14:59 MLD user.err vdr: [12805] DVBAPI-Error: Decrypt: set_FastECM_CW_Parity MUST WAIT SUCCESS parity:1 pid:1791 keyindex:1 adapter:0 len:172021 time:-2459953

Apr 11 20:15:04 MLD user.err vdr: [12805] DVBAPI-Error: Decrypt: set_FastECM_CW_Parity MUST WAIT parity:2 pid:1796 keyindex:1 adapter:0 len:240829

Apr 11 20:15:06 MLD user.err vdr: [12805] DVBAPI-Error: Decrypt: set_FastECM_CW_Parity MUST WAIT TIMEOUT parity:2 pid:1796 keyindex:1 adapter:0 len:240829 time:-2466458

Apr 11 20:15:31 MLD user.err vdr: [12805] DVBAPI-Error: Decrypt: set_FastECM_CW_Parity MUST WAIT parity:2 pid:1791 keyindex:1 adapter:0 len:155289

Apr 11 20:15:33 MLD user.err vdr: [12805] DVBAPI-Error: Decrypt: set_FastECM_CW_Parity MUST WAIT SUCCESS parity:2 pid:1791 keyindex:1 adapter:0 len:155289 time:-2495330

Apr 11 20:15:45 MLD user.err vdr: [12805] DVBAPI-Error: Decrypt: set_FastECM_CW_Parity MUST WAIT parity:2 pid:1791 keyindex:1 adapter:0 len:108853

Apr 11 20:15:48 MLD user.err vdr: [12805] DVBAPI-Error: Decrypt: set_FastECM_CW_Parity MUST WAIT TIMEOUT parity:2 pid:1791 keyindex:1 adapter:0 len:108853 time:-2508362

Apr 11 20:15:54 MLD user.info vdr: [12602] DVBAPI: 0.0 set CAM decrypt (SID 318 (0x013E), caLm 4, HasCaDescriptors 0)`

Please let me know if you need more details (hardware info, logs, whatever) or if this is the wrong place for this particular issue.

EDIT I've now been able to do a short test on another machine on another sat-dish even, but the result was the same. Both machines run a Nvidia GT220 GPU though.

manio commented 1 year ago

Please attach vdr to a gdb and provide me a backtrace. ps. I thought I am the only one still using GT220 :)

STPKITT commented 1 year ago

:-D GT220 still going strong, one of them being a passively cooled model from MSI bought in time for the 2010 Olympic Games.

I attached the backtrace here (I'm no expert at this, so I guess it's that and in full). It from the moment VDR chrashed while I was recording an encrypted channel and started another recording of an encrypted channel on another transponder.

I also uploaded the coredump-file, I did 7-zip it though since it originally was 720 Mb in size. Here's the link to it: https://file.io/xMiwVReGwYh8

In the meantime I read some speculation in a forum that FastECM could be problematic generally, so I'll mention here that I had FastECM enabled at the moment VDR chrashed. After creating the coredump & backtrace for you I did another try in exactly the same way but this time with FastECM disabled. The result was exactly the same though, VDR crashed instantly.

Let me know if I can further help by providing even more information.

Greets!

Backtrace_APMLD.txt

manio commented 1 year ago

I am not 100% sure but for me it rather look like a problem in vdr process, not a dvbapi plugin. Please try to report it there... Closing for now, please reopen when necessary.

STPKITT commented 3 months ago

Hello, I just wanted to report that I tried again on the exact same hardware, but this time on the distribution MLD 6.4 alpha with VDR 2.6.7, softhddevice 1.12.5-GIT68590fe, dvbapi 2.2.6-GIT-28fc0c9 connected to OSCAM 1.20_svn and so far did not experience this issue so that I'd declare it solved for now.