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
57 stars 25 forks source link

Continous retune of channel #82

Closed jonofe closed 9 years ago

jonofe commented 9 years ago

Hi Manio, I opened the following issue on the Kodi forum and FernetMenta directed me to you. Hopefully you can help me with the following issue, which maybe caused by dvbapi:

I'm using VDR in the following config:

vdr (2.1.6/2.1.6) - The Video Disk Recorder hello (2.1.1) - A friendly greeting permashift (1.0.0) - Automatically record live TV epgtableid0 (2.1.1) - EPG handler for events with table id 0x00 streamdev-client (0.6.1-git) - VTP Streaming Client dvbsddevice (2.1.2) - SD Full Featured DVB device svdrpdemo (2.1.1) - How to add SVDRP support to a plugin dvbapi (2.1.1-GIT-vdr-2.1.6) - SoftCAM for OSCam vnsiserver (1.2.0) - VDR-Network-Streaming-Interface (VNSI) Server status (2.1.1) - Status monitor test svcsvr (2.1.1) - Service demo server osddemo (2.1.2) - Demo of arbitrary OSD setup pictures (2.1.1) - A simple picture viewer svccli (2.1.1) - Service demo client dvbhddevice (2.1.6) - HD Full Featured DVB device rcu (2.1.1) - Remote Control Unit streamdev-server (0.6.1-git) - VDR Streaming Server skincurses (2.1.1) - A text only skin

I access the VDR live stream via VNSI from an Intel NUC with OpenElect 4.97.2.

When I switch to the channel SuperRTL I get continuous artefacts and freezers and in the vdr log I can see the following messages in a loop:

Dec 15 20:16:42 david vdr: [1635] VNSI: Started streaming of channel SUPER RTL HD (timeout 10 seconds) Dec 15 20:16:43 david vdr: [27698] VNSI: Video Input - new pmt, attaching receiver Dec 15 20:16:43 david vdr: [27698] DVBAPI: 0.0 set CAM decrypt (SID 11931 (0x2E9B), caLm 4, HasCaDescriptors 1) Dec 15 20:16:43 david vdr: [1638] VNSI: Created stream for pid=300 and type=8 Dec 15 20:16:43 david vdr: [1638] VNSI: Created stream for pid=310 and type=1 Dec 15 20:16:43 david vdr: [1638] VNSI: Created stream for pid=330 and type=9 Dec 15 20:16:43 david vdr: [1638] VNSI: Created stream for pid=320 and type=11 Dec 15 20:16:47 david vdr: [1636] VNSI: call retune ... Dec 15 20:16:47 david vdr: [1638] VNSI: close video input ... Dec 15 20:16:47 david vdr: [1636] DVBAPI: 0.0 set CAM decrypt (SID 11931 (0x2E9B), caLm 5, HasCaDescriptors 1) Dec 15 20:16:47 david vdr: [1638] VNSI: call retune ... Dec 15 20:16:47 david vdr: [27698] VNSI: Video Input - new pmt, attaching receiver Dec 15 20:16:47 david vdr: [27698] DVBAPI: 0.0 set CAM decrypt (SID 11931 (0x2E9B), caLm 4, HasCaDescriptors 1) Dec 15 20:16:51 david vdr: [1660] VNSI: call retune ... Dec 15 20:16:51 david vdr: [1638] VNSI: close video input ... Dec 15 20:16:51 david vdr: [1660] DVBAPI: 0.0 set CAM decrypt (SID 11931 (0x2E9B), caLm 5, HasCaDescriptors 1) Dec 15 20:16:51 david vdr: [1638] VNSI: call retune ... Dec 15 20:16:51 david vdr: [27698] VNSI: Video Input - new pmt, attaching receiver Dec 15 20:16:51 david vdr: [27698] DVBAPI: 0.0 set CAM decrypt (SID 11931 (0x2E9B), caLm 4, HasCaDescriptors 1) Dec 15 20:16:55 david vdr: [1686] VNSI: call retune ... Dec 15 20:16:55 david vdr: [1638] VNSI: close video input ... Dec 15 20:16:55 david vdr: [1686] DVBAPI: 0.0 set CAM decrypt (SID 11931 (0x2E9B), caLm 5, HasCaDescriptors 1) Dec 15 20:16:55 david vdr: [1638] VNSI: call retune ... Dec 15 20:16:55 david vdr: [27698] VNSI: Video Input - new pmt, attaching receiver Dec 15 20:16:55 david vdr: [27698] DVBAPI: 0.0 set CAM decrypt (SID 11931 (0x2E9B), caLm 4, HasCaDescriptors 1) Dec 15 20:16:59 david vdr: [1704] VNSI: call retune ... Dec 15 20:16:59 david vdr: [1638] VNSI: close video input ... Dec 15 20:16:59 david vdr: [1704] DVBAPI: 0.0 set CAM decrypt (SID 11931 (0x2E9B), caLm 5, HasCaDescriptors 1) Dec 15 20:16:59 david vdr: [1638] VNSI: call retune ... Dec 15 20:16:59 david vdr: [27698] VNSI: Video Input - new pmt, attaching receiver Dec 15 20:16:59 david vdr: [27698] DVBAPI: 0.0 set CAM decrypt (SID 11931 (0x2E9B), caLm 4, HasCaDescriptors 1) Dec 15 20:17:03 david vdr: [1723] VNSI: call retune ... Dec 15 20:17:03 david vdr: [1723] DVBAPI: 0.0 set CAM decrypt (SID 11931 (0x2E9B), caLm 5, HasCaDescriptors 1) Dec 15 20:17:08 david vdr: [1638] VNSI: close video input ... Dec 15 20:17:08 david vdr: [1638] VNSI: call retune ... Dec 15 20:17:08 david vdr: [27698] VNSI: Video Input - new pmt, attaching receiver Dec 15 20:17:08 david vdr: [27698] DVBAPI: 0.0 set CAM decrypt (SID 11931 (0x2E9B), caLm 4, HasCaDescriptors 1) Dec 15 20:17:12 david vdr: [1849] VNSI: call retune ... Dec 15 20:17:12 david vdr: [1849] DVBAPI: 0.0 set CAM decrypt (SID 11931 (0x2E9B), caLm 5, HasCaDescriptors 1) Dec 15 20:17:16 david vdr: [1638] VNSI: close video input ... Dec 15 20:17:16 david vdr: [1638] VNSI: call retune ... Dec 15 20:17:17 david vdr: [27698] VNSI: Video Input - new pmt, attaching receiver

Other HD channels which use DVBAPI as well work without problems. I already switched EPG Update off, but without success.

I can observe the same behaviour when I'm accessing via XBMC from my Win 8.1 PC. So probably a problem of the VDR backendConfused

Any help is very much appreciated.

BR André

manio commented 9 years ago

Hello! Hmmm ... this seems weird because the PMT data is constantly triggered. The simple test you can do is to shedule a recording on this channel. Recording is done totally by VDR (using my plugin) so you can be sure that none of the output/streaming plugin is influencing on this. After some time just play the recording and you'll see if everything is ok (and if my plugin was able to deliver keys to proper decryption).

I can see in your case that VDR is still requested to stop and start a channel (probably by VNSI because the PMT data was changed?). It is normal but this should be rare - especially just after switch to new channel and when PMT is reread (so - mainly just after zap, or after PMT change), and not so often later. For my daily usage I am not using VNSI, but rather XVDR, and I didn't notice similar problem, so you may also try it.

jonofe commented 9 years ago

I did a recording already, without any problems, without freezers. so, that means it is probably a problem of VNSI plugin, right? I used VNSI to have timeshift available. Is that also possible with XVDR? I will give it a try.

manio commented 9 years ago

It means that this is not a problem of VDR and the dvbapi plugin. Timeshift is also possible with XVDR.