Ist es möglich die Aufnahmen Zeigesteuert neu einzulesen. Jedesmal Kodi neu starten ist nicht wirklich komfortabel!

Gruß
privatscheiss

Hello,
I'm no longer able to get my recording list to exact the same grouping as on the VDR side.
Maybe this has something to do with this commit?
44829e9
Is there any way to get back the old behaviour? I have some auto-timers which sort recordings to specific directories. I would like to have exactly this grouping in Kodi.
Thanks in advance.

I added this patch to my local installation to allow setting a listening port on the vnsiserver. This allowes me to run two vnsiserver plugings for protocol version 5 and 6 in parallel.

Use case: Have an Mac with Kodi (Version 6) and an OpenELEC (Version 5) client in parallel.

Would be nice to see this added to the code in general.

thks
meier

root@mediapc:~# cat vnsi.c.add_cmd_option_port.patch 
--- vdr-plugin-vnsiserver/vnsi.c.bak    2015-01-23 22:33:58.496941442 +0100
+++ vdr-plugin-vnsiserver/vnsi.c    2015-01-23 23:00:04.444941257 +0100
@@ -48,12 +48,14 @@
     return "  -t n, --timeout=n      stream data timeout in seconds (default: 10)\n"
            "  -d  , --device         act as the primary device\n"
            "  -s n, --test=n         TS stream test file to simulate as channel\n";
+           "  -p n, --port=n         tcp port to listen on\n";
 }

 bool cPluginVNSIServer::ProcessArgs(int argc, char *argv[])
 {
   // Implement command line argument processing here if applicable.
   static struct option long_options[] = {
+       { "port",     required_argument, NULL, 'p' },
        { "timeout",  required_argument, NULL, 't' },
        { "device",   no_argument,       NULL, 'd' },
        { "test",     required_argument, NULL, 'T' },
@@ -62,8 +64,10 @@

   int c;

-  while ((c = getopt_long(argc, argv, "t:dT:", long_options, NULL)) != -1) {
+  while ((c = getopt_long(argc, argv, "t:dT:p:", long_options, NULL)) != -1) {
         switch (c) {
+          case 'p': if(optarg != NULL) VNSIServerConfig.listen_port = atoi(optarg);
+                    break;
           case 't': if(optarg != NULL) VNSIServerConfig.stream_timeout = atoi(optarg);
                     break;
           case 'd': VNSIServerConfig.device = true;
@@ -97,6 +101,7 @@

 bool cPluginVNSIServer::Start(void)
 {
+  INFOLOG("Starting vnsi server at port=%d\n", VNSIServerConfig.listen_port);
   Server = new cVNSIServer(VNSIServerConfig.listen_port);

   return true;
root@mediapc:~# 

If it's possible, the teletext subtitles should be handled as DVD subtitles.
Instead opening teletext and going on correct page, teletext subtitles should be automatically detected (similarly to the vdr-ttxtsubs plugin) so that we can select it in Kodi subtitle menu.
I don't know if this is easily doable, but would be nice having this feature.

Dear FernetMenta,
Let me share one issue I've
My config is ubuntu14.04+VDR2.2(same issue with 2.3.1)+VNSI1.10.10 + Kodi (15 or 16 or 17)
on HW side, TBS6991 +CAM + legal subscription
I define my list of channels(SD/HD : FTA or Scrambled) and works
The issue is the following, If I switch to a channels not covered by my subscription and come back after on official channel, the Zapping time is very high( up to 40sec instead of few secs)
and I've the following
Apr 15 22:19:54 streamy3 vdr: [1831] CAM 1: assigned to device 1
Apr 15 22:19:54 streamy3 vdr: [1831] VNSI: Successfully found following device: 0x955a20 (1) for receiving
Apr 15 22:19:54 streamy3 vdr: [1831] VNSI: Successfully switched to channel 7 - La2_h12721
Apr 15 22:19:54 streamy3 vdr: [1831] VNSI: Started streaming of channel La2_h12721 (timeout 10 seconds)
Apr 15 22:19:54 streamy3 vdr: [1855] device 1 receiver thread started (pid=1608, tid=1855, prio=high)
Apr 15 22:19:54 streamy3 vdr: [1857] cLiveStreamer stream processor thread started (pid=1608, tid=1857, prio=high)
Apr 15 22:19:54 streamy3 vdr: [1858] device 1 TS buffer thread started (pid=1608, tid=1858, prio=high)
Apr 15 22:19:55 streamy3 vdr: [1856] VNSI: VideoInput: no pat/pmt within timeout, falling back to channel pids
Apr 15 22:19:55 streamy3 vdr: [1856] VNSI: Video Input - new pmt, attaching receiver
Apr 15 22:19:55 streamy3 vdr: [1857] VNSI: Created stream for pid=552 and type=8
Apr 15 22:19:55 streamy3 vdr: [1857] VNSI: Created stream for pid=102 and type=2
Apr 15 22:19:55 streamy3 vdr: [1857] VNSI: Created stream for pid=52 and type=11
Apr 15 22:19:57 streamy3 vdr: [1629] frontend 0/0 lost lock on channel 7 (La2_h12721), tp 112721
Apr 15 22:19:58 streamy3 vdr: [1629] frontend 0/0 regained lock on channel 7 (La2_h12721), tp 112721
Apr 15 22:19:59 streamy3 vdr: [1855] detaching receiver - won't decrypt channel S19.2E-53-1119-12852 with CAM 1
Apr 15 22:19:59 streamy3 vdr: [1855] VNSI: call retune ...
Apr 15 22:19:59 streamy3 vdr: [1855] CAM 1: unassigned
Apr 15 22:19:59 streamy3 vdr: [1857] VNSI: close video input ...
Apr 15 22:19:59 streamy3 vdr: [1857] VNSI: call retune ...
Apr 15 22:19:59 streamy3 vdr: [1857] VNSI: close video input ...
Apr 15 22:19:59 streamy3 vdr: [1858] device 1 TS buffer thread ended (pid=1608, tid=1858)
Apr 15 22:19:59 streamy3 vdr: [1855] buffer stats: 18236 (0%) used
Apr 15 22:19:59 streamy3 vdr: [1855] device 1 receiver thread ended (pid=1608, tid=1855)
Apr 15 22:19:59 streamy3 vdr: [1857] VNSI: close video input ...
Apr 15 22:20:00 streamy3 vdr: message repeated 13 times: [ [1857] VNSI: close video input ...]
Apr 15 22:20:00 streamy3 vdr: [1629] frontend 0/0 lost lock on channel 7 (La2_h12721), tp 112721
Apr 15 22:20:00 streamy3 vdr: [1857] VNSI: close video input ...
Apr 15 22:20:01 streamy3 vdr: message repeated 8 times: [ [1857] VNSI: close video input ...]
Apr 15 22:20:01 streamy3 vdr: [1629] frontend 0/0 regained lock on channel 7 (La2_h12721), tp 112721
Apr 15 22:20:01 streamy3 vdr: [1857] VNSI: close video input ...
Apr 15 22:20:04 streamy3 vdr: message repeated 25 times: [ [1857] VNSI: close video input ...]
Apr 15 22:20:04 streamy3 vdr: [1857] VNSI: Channel: scrambled 3
Apr 15 22:20:04 streamy3 vdr: [1857] VNSI: close video input ...
Apr 15 22:20:14 streamy3 vdr: message repeated 99 times: [ [1857] VNSI: close video input ...]
Apr 15 22:20:14 streamy3 vdr: [1857] VNSI: Channel: no data 16
Apr 15 22:20:14 streamy3 vdr: [1857] VNSI: close video input ...
Apr 15 22:20:15 streamy3 vdr: message repeated 8 times: [ [1857] VNSI: close video input ...]
Apr 15 22:20:15 streamy3 vdr: [1857] CAM 1: assigned to device 1
Apr 15 22:20:15 streamy3 vdr: [1857] VNSI: Successfully found following device: 0x955a20 (1) for receiving
Apr 15 22:20:15 streamy3 vdr: [1865] device 1 receiver thread started (pid=1608, tid=1865, prio=high)
Apr 15 22:20:15 streamy3 vdr: [1867] device 1 TS buffer thread started (pid=1608, tid=1867, prio=high)
Apr 15 22:20:15 streamy3 vdr: [1630] VNSI: Video Input - new pmt, attaching receiver
syslog.zip

I guess it's an issue with VNSI (not the TBS driver or VDR) ... What did you advice ?

Thanks in advance
JP

I found following Messages after each channel switch in my logs:

VNSI-Error: cParser::AddPESPacket - max buffer size reached

I increased in the code the plain Number: 1000000 to 5000000

[code]
if (m_PesBufferPtr + size >= m_PesBufferSize)
{
if (m_PesBufferPtr + size >= 1000000)
{
ERRORLOG("cParser::AddPESPacket - max buffer size reached, pid: %d", m_pID);
Reset();
return false;
}
[/code]

and these Messages are gone.

I don't really understand the code but with this change the short picture disturbance after
channel switch is gone.

Perhaps other methods defining the size address the issue better.
FernetMenta might have a look.

I had to revert the commit "reset parsers if stream is scrambled" (ID 51a0882) for my vdr-2.2.0 because it leads to long channel switching times (more than 12 sec) for scrambled channels.

On the client, a pop up window "channel is scrambled" is shown, but the the stream is working normal.

After reverting the commit everything works as expected and smooth.

Hi,

with a low minuseractivity setting kodi shows a "VDR will shut down in ..." countdown every 10 seconds or so - and restarts it a over and over. As the user can't (and most probably doesn't want to) change anything about that, this message should be added to the ignored ones:

please add

https://github.com/FernetMenta/vdr-plugin-vnsiserver/blob/master/vnsiclient.c#L347

else if (strncmp(Message, trVDR("VDR will shut down in"), 21) == 0) return;

to fix this, thanks!

According to the VDR documentation https://linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf#RID :

RID
Radio ID. Typical 0. Can be used to differentiate between channels having the same SID, NID and TID.

However, VNSI seems ignores this field. I've created a few groups with duplicate channels but different RID. Here is a short example:

:HTB+
EUROSPORT 1 HD;HTB+:12207:vC34M5O35S1:S36.0E:27500:301=27:401=rus@4,421=eng@4:0:500:26001:112:9:0

:Sport
EUROSPORT 1 HD;HTB+:12207:vC34M5O35S1:S36.0E:27500:301=27:401=rus@4,421=eng@4:0:500:26001:112:9:1

The first group is the provider name and it contains all channels of this provider.
The second group contains only the sport channels from the first group, but these channels have a different RID.

I can see all these groups in Streamdev but not in VNSI. Seems VNSI ignores the RID field and treats the channels from the second group as duplicates.

compiling latest git tree leads to unkwown cStateKey timerState;

commenting line 253 in vnsitimer.c out, everything compiles and runs.

VDR backend does not create a thumbnail after recording and then there is no thumb in Kodi.
Please let Kodi / VDR create a thumbnail with ffmpeg after recording.
Thx

When recording scrambled channel with latest beta of oe I get no audio on replay with vnsi server.
Live tv of scrambled channels is working fine.

@fritsch told me to file issue here.

kodi.log http://sprunge.us/FHUg
mediainfo http://pastebin.com/9wua0Rhk
link to recording https://www.dropbox.com/s/9ntzwz5jfmxa7wh/00001.ts?dl=0
oe debug log http://pastebin.com/mnWVSuJx

It would be nice to have the plugin refresh the available recordings every once in a while, since one of my kodi installs is running constantly (raspi 2), there is no way to refresh the recordings made with vdr itself (not via kodi) except to uplug power on the raspi and restart the whole thing.

Archlinux 64-bit, VDR 2.2.0 & vnsiserver 1.2.1
Test channels:
SVT1 HD;Telenor:10903:VC34M5O25S1:S1.0W:25000:1034=27:3024=sve@3;4144=sve@106:6204:B00:3801:70:69:0
NOVA Cinema;UPC Direct:11727:VC78M2S0:S0.8W:28000:151=2:161=cze@4:170:1815,D02,D97,653:30102:1536:701:0
Hi!
I'm having trouble to get picon to work with this 2 satellite, i don't know if it's bug or new future. I haven't been playing with vdr for awhile.
This used to work, generated using Pipelka's serviceref tool.
SVT1 HD;Telenor - 1_0_19_ED9_45_46_7120000_0_0_0
NOVA Cinema;UPC Direct - 1_0_1_7596_2BD_600_7100000_0_0_0

Correctly generated enigma hashes: (can you make work with this?) .
1_0_19_ED9_45_46_E060000_0_0_0 -------- SVT1 HD
1_0_1_7596_2BD_600_E080000_0_0_0 -------- NOVA Cinema

But i managed to get it work with 0.8W with this hash FFF80000
NOVA Cinema: 1_0_1_7596_2BD_600_FF80000_0_0_0
On 1W i tried many hashes like FFFA0000 nothing works.
I got the idea from this tvheadend bug report, they had almost same problem which seems
to be fixed. This links contain great info like how they fixed it and links to enigma source code.
https://tvheadend.org/issues/2700

This script generates enigma compatible hash:
https://github.com/picons/picons-source

Dear Rainer,

first of all, many thanks for your great development work on the PVR branch of Kodi & the VDR backend!
Currently 4k is coming up fast, and there are as well some (demo)-channels available on Astra 19.2E. Kodi already has H265/HVEC support, and VDR is also moving in that direction.

As it looks like, the patch from Thomas Reufer, published on VDR-Portal.de is providing the HVEC parser for VDR which seems to work properly. Details can be found in this thread:
http://www.vdr-portal.de/board17-developer/board97-vdr-core/p1269333-rfc-h-265-frame-parser/

To successfully enable VNSI to stream 4k, it looks like it requires its own parser. It would be a great thing to have the PVR-Backend 4k streaming enabled.

Best regards,
Harald Gutmann

Hi!
I'm running VDR 2.2.0 compiled from source with VNSI Server Plugin (commit 9529e6d) on Ubuntu 14.04 and have a problem that VDR periodically switches to the channel it is currently on with a period of about 11 seconds and that inevitably the mantis driver is screwed and I cant get any picture any more, EPG workds though.
Restarting VDR is not enough, I have to unload and reoad the mantis Kernel module.

Weird thing is I can't really find any errors in the log except for the constant channel switching.
Any ideas? If I run the streamdev plugin instead everything is fine.

05:00.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0](rev 01)
Subsystem: TERRATEC Electronic GmbH Device 1178
Flags: bus master, medium devsel, latency 32, IRQ 16
Memory at f0101000 (32-bit, prefetchable) [size=4K]
Kernel driver in use: Mantis

05:01.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0](rev 01)
Subsystem: TERRATEC Electronic GmbH Device 1178
Flags: bus master, medium devsel, latency 32, IRQ 17
Memory at f0100000 (32-bit, prefetchable) [size=4K]
Kernel driver in use: Mantis

Hi,

I'm unable to watch Live TV (libreelec) when I have recordings going on at the same time (4 DVB-S2 cards in use).

Using GDB and latest git code the problem occurs here, each and every time:
Thread 13 (Thread 0x7fffd37fe700 (LWP 31478)):
#0 0x00007ffff62f49e3 in select () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007ffff4901d4d in cVNSIServer::Action (this=0x8cf650) at vnsiserver.c:195
#2 0x00000000005136f9 in cThread::StartThread (Thread=0x8cf650) at thread.c:262
#3 0x00007ffff79686ba in start_thread (arg=0x7fffd37fe700) at pthread_create.c:333
#4 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Entire bt:
Thread 13 "VNSI Server" hit Catchpoint 1 (signal SIG32), 0x00007ffff62f49e3 in select () at ../sysdeps/unix/syscall-template.S:84
84 ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden.

Thread 13 "VNSI Server" hit Catchpoint 1 (signal SIG32), 0x00007ffff62f49e3 in select () at ../sysdeps/unix/syscall-template.S:84
84 ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden.
(gdb) thread apply all bt

Thread 37 (Thread 0x7fffab7fe700 (LWP 32079)):
#0 0x00007ffff62f2b5d in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007ffff63104ce in __poll_chk (fds=, nfds=, timeout=, fdslen=)
at poll_chk.c:27
#2 0x000000000051b17d in poll (__timeout=100, __nfds=, __fds=0x7fffab7fde40) at /usr/include/x86_64-linux-gnu/bits/poll2.h:41
#3 cPoller::Poll (this=this@entry=0x7fffab7fde40, TimeoutMs=TimeoutMs@entry=100) at tools.c:1446
#4 0x00000000004834e1 in cTSBuffer::Action (this=0x7fffe8001b80) at device.c:1760
#5 0x00000000005136f9 in cThread::StartThread (Thread=0x7fffe8001b80) at thread.c:262
#6 0x00007ffff79686ba in start_thread (arg=0x7fffab7fe700) at pthread_create.c:333
#7 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 36 (Thread 0x7fffabfff700 (LWP 32078)):
#0 0x00007ffff79719ff in __libc_send (fd=67, buf=buf@entry=0x7fffe4041370, n=n@entry=40, flags=flags@entry=32768)
at ../sysdeps/unix/sysv/linux/x86_64/send.c:26
#1 0x00007ffff48f7f26 in cxSocket::write (this=0x7fffc80015b0, buffer=, size=size@entry=40, timeout_ms=timeout_ms@entry=-1,
more_data=more_data@entry=true) at cxsocket.c:98
#2 0x00007ffff48fdef2 in cLiveStreamer::sendStreamPacket (this=0x7fffdc023cb0, pkt=0x7fffabffee30) at streamer.c:364
#3 0x00007ffff48ff80d in cLiveStreamer::Action (this=0x7fffdc023cb0) at streamer.c:218
#4 0x00000000005136f9 in cThread::StartThread (Thread=0x7fffdc023cb0) at thread.c:262
#5 0x00007ffff79686ba in start_thread (arg=0x7fffabfff700) at pthread_create.c:333
#6 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 35 (Thread 0x7fffb27fc700 (LWP 32077)):
#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1 0x0000000000512eee in cCondWait::Wait (this=this@entry=0x7fffe89992b8, TimeoutMs=) at thread.c:71
#2 0x00000000004ee149 in cRingBuffer::WaitForGet (this=this@entry=0x7fffe8999250) at ringbuffer.c:74
#3 0x00000000004ee890 in cRingBufferLinear::Get (this=0x7fffe8999250, Count=@0x7fffb27fbd94: 0) at ringbuffer.c:366
#4 0x0000000000488abc in cTSBuffer::Get (this=0x7fffe8001b80, Available=Available@entry=0x0) at device.c:1783
#5 0x000000000048b6ff in cDvbDevice::GetTSPacket (this=0x910770, Data=@0x7fffb27fbe38: 0x0) at dvbdevice.c:1697
#6 0x0000000000488cb2 in cDevice::Action (this=0x910770) at device.c:1581
#7 0x00000000005136f9 in cThread::StartThread (Thread=0x910770) at thread.c:262
#8 0x00007ffff79686ba in start_thread (arg=0x7fffb27fc700) at pthread_create.c:333
#9 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 34 (Thread 0x7fffb2ffd700 (LWP 32076)):
#0 0x00007ffff62f2b5d in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007ffff63104ce in __poll_chk (fds=, nfds=, timeout=, fdslen=)
at poll_chk.c:27
#2 0x000000000051b17d in poll (__timeout=-1, __nfds=, __fds=0x7fffc80015e8) at /usr/include/x86_64-linux-gnu/bits/poll2.h:41
#3 cPoller::Poll (this=this@entry=0x7fffc80015e8, TimeoutMs=TimeoutMs@entry=-1) at tools.c:1446
#4 0x00007ffff48f807a in cxSocket::read (this=this@entry=0x7fffc80015b0, buffer=buffer@entry=0x7fffb2ffce60, size=size@entry=4,
---Type to continue, or q to quit---
timeout_ms=timeout_ms@entry=-1) at cxsocket.c:128
#5 0x00007ffff48f52d4 in cVNSIClient::Action (this=0x7fffc8001530) at vnsiclient.c:91
#6 0x00000000005136f9 in cThread::StartThread (Thread=0x7fffc8001530) at thread.c:262
#7 0x00007ffff79686ba in start_thread (arg=0x7fffb2ffd700) at pthread_create.c:333
#8 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 33 (Thread 0x7fffb0bfb700 (LWP 31849)):
#0 0x00007ffff62f2b5d in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007ffff63104ce in __poll_chk (fds=, nfds=, timeout=, fdslen=)
at poll_chk.c:27
#2 0x000000000051b17d in poll (__timeout=100, __nfds=, __fds=0x7fffb0bfae40) at /usr/include/x86_64-linux-gnu/bits/poll2.h:41
#3 cPoller::Poll (this=this@entry=0x7fffb0bfae40, TimeoutMs=TimeoutMs@entry=100) at tools.c:1446
#4 0x00000000004834e1 in cTSBuffer::Action (this=0x7fffd40008e0) at device.c:1760
#5 0x00000000005136f9 in cThread::StartThread (Thread=0x7fffd40008e0) at thread.c:262
#6 0x00007ffff79686ba in start_thread (arg=0x7fffb0bfb700) at pthread_create.c:333
#7 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 32 (Thread 0x7fffa9efd700 (LWP 31848)):
#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1 0x0000000000512eee in cCondWait::Wait (this=this@entry=0x7fffd40009e8, TimeoutMs=) at thread.c:71
#2 0x00000000004ee149 in cRingBuffer::WaitForGet (this=this@entry=0x7fffd4000980) at ringbuffer.c:74
#3 0x00000000004ee890 in cRingBufferLinear::Get (this=0x7fffd4000980, Count=@0x7fffa9efcd94: 0) at ringbuffer.c:366
#4 0x0000000000488abc in cTSBuffer::Get (this=0x7fffd40008e0, Available=Available@entry=0x0) at device.c:1783
#5 0x000000000048b6ff in cDvbDevice::GetTSPacket (this=0x909c20, Data=@0x7fffa9efce38: 0x0) at dvbdevice.c:1697
#6 0x0000000000488cb2 in cDevice::Action (this=0x909c20) at device.c:1581
#7 0x00000000005136f9 in cThread::StartThread (Thread=0x909c20) at thread.c:262
#8 0x00007ffff79686ba in start_thread (arg=0x7fffa9efd700) at pthread_create.c:333
#9 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 31 (Thread 0x7fffaabff700 (LWP 31847)):
#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1 0x0000000000512eee in cCondWait::Wait (this=this@entry=0x92dad8, TimeoutMs=) at thread.c:71
#2 0x00000000004ee149 in cRingBuffer::WaitForGet (this=this@entry=0x92da70) at ringbuffer.c:74
#3 0x00000000004ee890 in cRingBufferLinear::Get (this=0x92da70, Count=@0x7fffaabfee3c: 58280) at ringbuffer.c:366
#4 0x00000000004de03f in cRecorder::Action (this=0x950060) at recorder.c:125
#5 0x00000000005136f9 in cThread::StartThread (Thread=0x950190) at thread.c:262
#6 0x00007ffff79686ba in start_thread (arg=0x7fffaabff700) at pthread_create.c:333
#7 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 30 (Thread 0x7ffff36a9700 (LWP 31734)):
#0 0x00007ffff62f2b5d in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007ffff63104ce in __poll_chk (fds=, nfds=, timeout=, fdslen=)
---Type to continue, or q to quit---
at poll_chk.c:27
#2 0x000000000051b17d in poll (__timeout=100, __nfds=, __fds=0x7ffff36a8e40) at /usr/include/x86_64-linux-gnu/bits/poll2.h:41
#3 cPoller::Poll (this=this@entry=0x7ffff36a8e40, TimeoutMs=TimeoutMs@entry=100) at tools.c:1446
#4 0x00000000004834e1 in cTSBuffer::Action (this=0x7fffc40008e0) at device.c:1760
#5 0x00000000005136f9 in cThread::StartThread (Thread=0x7fffc40008e0) at thread.c:262
#6 0x00007ffff79686ba in start_thread (arg=0x7ffff36a9700) at pthread_create.c:333
#7 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 29 (Thread 0x7fffb13fc700 (LWP 31733)):
#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1 0x0000000000512eee in cCondWait::Wait (this=this@entry=0x7fffc40009e8, TimeoutMs=) at thread.c:71
#2 0x00000000004ee149 in cRingBuffer::WaitForGet (this=this@entry=0x7fffc4000980) at ringbuffer.c:74
#3 0x00000000004ee890 in cRingBufferLinear::Get (this=0x7fffc4000980, Count=@0x7fffb13fbd94: 0) at ringbuffer.c:366
#4 0x0000000000488abc in cTSBuffer::Get (this=0x7fffc40008e0, Available=Available@entry=0x0) at device.c:1783
#5 0x000000000048b6ff in cDvbDevice::GetTSPacket (this=0x9030d0, Data=@0x7fffb13fbe38: 0x0) at dvbdevice.c:1697
#6 0x0000000000488cb2 in cDevice::Action (this=0x9030d0) at device.c:1581
#7 0x00000000005136f9 in cThread::StartThread (Thread=0x9030d0) at thread.c:262
#8 0x00007ffff79686ba in start_thread (arg=0x7fffb13fc700) at pthread_create.c:333
#9 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 28 (Thread 0x7fffb1bfd700 (LWP 31732)):
#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1 0x0000000000512eee in cCondWait::Wait (this=this@entry=0x951ba8, TimeoutMs=) at thread.c:71
#2 0x00000000004ee149 in cRingBuffer::WaitForGet (this=this@entry=0x951b40) at ringbuffer.c:74
#3 0x00000000004ee890 in cRingBufferLinear::Get (this=0x951b40, Count=@0x7fffb1bfce3c: 62040) at ringbuffer.c:366
#4 0x00000000004de03f in cRecorder::Action (this=0x94e430) at recorder.c:125
#5 0x00000000005136f9 in cThread::StartThread (Thread=0x94e560) at thread.c:262
#6 0x00007ffff79686ba in start_thread (arg=0x7fffb1bfd700) at pthread_create.c:333
#7 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 21 (Thread 0x7fffb37fe700 (LWP 31486)):
#0 0x00007ffff62f2b5d in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007ffff63104ce in __poll_chk (fds=, nfds=, timeout=, fdslen=)
at poll_chk.c:27
#2 0x000000000051b17d in poll (__timeout=-1, __nfds=, __fds=0x7fffc8000d08) at /usr/include/x86_64-linux-gnu/bits/poll2.h:41
#3 cPoller::Poll (this=this@entry=0x7fffc8000d08, TimeoutMs=TimeoutMs@entry=-1) at tools.c:1446
#4 0x00007ffff48f807a in cxSocket::read (this=this@entry=0x7fffc8000cd0, buffer=buffer@entry=0x7fffb37fde60, size=size@entry=4,
timeout_ms=timeout_ms@entry=-1) at cxsocket.c:128
#5 0x00007ffff48f52d4 in cVNSIClient::Action (this=0x7fffc8000c50) at vnsiclient.c:91
#6 0x00000000005136f9 in cThread::StartThread (Thread=0x7fffc8000c50) at thread.c:262
#7 0x00007ffff79686ba in start_thread (arg=0x7fffb37fe700) at pthread_create.c:333
#8 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
---Type to continue, or q to quit---

Thread 15 (Thread 0x7fffd27fc700 (LWP 31480)):
#0 0x00007ffff62c375d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007ffff62f51a4 in usleep (useconds=useconds@entry=250000) at ../sysdeps/posix/usleep.c:32
#2 0x00007ffff490c726 in cVNSIStatus::Action (this=0x8cf780) at status.c:307
#3 0x00000000005136f9 in cThread::StartThread (Thread=0x8cf780) at thread.c:262
#4 0x00007ffff79686ba in start_thread (arg=0x7fffd27fc700) at pthread_create.c:333
#5 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 13 (Thread 0x7fffd37fe700 (LWP 31478)):
#0 0x00007ffff62f49e3 in select () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007ffff4901d4d in cVNSIServer::Action (this=0x8cf650) at vnsiserver.c:195
#2 0x00000000005136f9 in cThread::StartThread (Thread=0x8cf650) at thread.c:262
#3 0x00007ffff79686ba in start_thread (arg=0x7fffd37fe700) at pthread_create.c:333
#4 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 12 (Thread 0x7fffd3fff700 (LWP 31477)):
#0 0x00007ffff62f2b5d in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0x00000000004f05b2 in poll (__timeout=1000, __nfds=6, __fds=0x7fffd3ffde10) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 cSectionHandler::Action (this=0x902900) at sections.c:184
#3 0x00000000005136f9 in cThread::StartThread (Thread=0x902900) at thread.c:262
#4 0x00007ffff79686ba in start_thread (arg=0x7fffd3fff700) at pthread_create.c:333
#5 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 11 (Thread 0x7ffff0ea4700 (LWP 31476)):
#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1 0x00000000005130dc in cCondVar::TimedWait (this=this@entry=0x8fb498, Mutex=..., TimeoutMs=TimeoutMs@entry=1000) at thread.c:127
#2 0x000000000048e6b5 in cDvbTuner::Action (this=0x8fad10) at dvbdevice.c:1000
#3 0x00000000005136f9 in cThread::StartThread (Thread=0x8fad10) at thread.c:262
#4 0x00007ffff79686ba in start_thread (arg=0x7ffff0ea4700) at pthread_create.c:333
#5 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 10 (Thread 0x7ffff16a5700 (LWP 31474)):
#0 0x00007ffff62f2b5d in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0x00000000004f05b2 in poll (__timeout=1000, __nfds=6, __fds=0x7ffff16a3e10) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 cSectionHandler::Action (this=0x9025c0) at sections.c:184
#3 0x00000000005136f9 in cThread::StartThread (Thread=0x9025c0) at thread.c:262
#4 0x00007ffff79686ba in start_thread (arg=0x7ffff16a5700) at pthread_create.c:333
#5 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 9 (Thread 0x7ffff1ea6700 (LWP 31473)):
#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
---Type to continue, or q to quit---
#1 0x00000000005130dc in cCondVar::TimedWait (this=this@entry=0x8fa648, Mutex=..., TimeoutMs=TimeoutMs@entry=1000) at thread.c:127
#2 0x000000000048e6b5 in cDvbTuner::Action (this=0x8f9ec0) at dvbdevice.c:1000
#3 0x00000000005136f9 in cThread::StartThread (Thread=0x8f9ec0) at thread.c:262
#4 0x00007ffff79686ba in start_thread (arg=0x7ffff1ea6700) at pthread_create.c:333
#5 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 8 (Thread 0x7ffff26a7700 (LWP 31471)):
#0 0x00007ffff62f2b5d in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0x00000000004f05b2 in poll (__timeout=1000, __nfds=6, __fds=0x7ffff26a5e10) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 cSectionHandler::Action (this=0x8b3020) at sections.c:184
#3 0x00000000005136f9 in cThread::StartThread (Thread=0x8b3020) at thread.c:262
#4 0x00007ffff79686ba in start_thread (arg=0x7ffff26a7700) at pthread_create.c:333
#5 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 7 (Thread 0x7ffff46ab700 (LWP 31470)):
#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1 0x00000000005130dc in cCondVar::TimedWait (this=this@entry=0x8da448, Mutex=..., TimeoutMs=TimeoutMs@entry=1000) at thread.c:127
#2 0x000000000048e6b5 in cDvbTuner::Action (this=0x8d9cc0) at dvbdevice.c:1000
#3 0x00000000005136f9 in cThread::StartThread (Thread=0x8d9cc0) at thread.c:262
#4 0x00007ffff79686ba in start_thread (arg=0x7ffff46ab700) at pthread_create.c:333
#5 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 6 (Thread 0x7ffff2ea8700 (LWP 31468)):
#0 0x00007ffff62f2b5d in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0x00000000004f05b2 in poll (__timeout=1000, __nfds=6, __fds=0x7ffff2ea6e10) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 cSectionHandler::Action (this=0x8a79b0) at sections.c:184
#3 0x00000000005136f9 in cThread::StartThread (Thread=0x8a79b0) at thread.c:262
#4 0x00007ffff79686ba in start_thread (arg=0x7ffff2ea8700) at pthread_create.c:333
#5 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 5 (Thread 0x7ffff3eaa700 (LWP 31467)):
#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1 0x00000000005130dc in cCondVar::TimedWait (this=this@entry=0x8b2958, Mutex=..., TimeoutMs=TimeoutMs@entry=1000) at thread.c:127
#2 0x000000000048e6b5 in cDvbTuner::Action (this=0x8b21d0) at dvbdevice.c:1000
#3 0x00000000005136f9 in cThread::StartThread (Thread=0x8b21d0) at thread.c:262
#4 0x00007ffff79686ba in start_thread (arg=0x7ffff3eaa700) at pthread_create.c:333
#5 0x00007ffff62fe82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 1 (Thread 0x7ffff7fe2740 (LWP 31453)):
#0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1 0x0000000000512eee in cCondWait::Wait (this=this@entry=0x7fffffffdf70, TimeoutMs=TimeoutMs@entry=10) at thread.c:71
#2 0x0000000000512f46 in cCondWait::SleepMs (TimeoutMs=TimeoutMs@entry=10) at thread.c:60
---Type to continue, or q to quit---
#3 0x00000000005135ae in cThread::Cancel (this=this@entry=0x8cf780, WaitSeconds=WaitSeconds@entry=5) at thread.c:331
#4 0x00007ffff490c88d in cVNSIStatus::Shutdown (this=this@entry=0x8cf780) at status.c:56
#5 0x00007ffff49011f7 in cVNSIServer::~cVNSIServer (this=0x8cf650, __in_chrg=) at vnsiserver.c:86
#6 0x00007ffff49012e9 in cVNSIServer::~cVNSIServer (this=0x8cf650, __in_chrg=) at vnsiserver.c:89
#7 0x00007ffff48ea863 in cPluginVNSIServer::Stop (this=0x805110) at vnsi.c:107
#8 0x00000000004dca35 in cPluginManager::StopPlugins (this=this@entry=0x7fffffffe270) at plugin.c:500
#9 0x000000000046a9cf in main (argc=, argv=) at vdr.c:1463

Cheers,
Michael

see log from syslog

lock_sequenze.txt

greetings
beinhart

Hello, I recently made the switch from using EasyVDR 3.0 as a frontend to Kodi v17.2 with this the vnsi plugin newest version thats in the repo.

My headless server is easyvdr 3.0 (VDR-Version: 2.2.0) with this plugin:

vdr-plugin-vnsiserver:
  Installiert:           2:1.5.2~git20170616-0easyVDR0~trusty

I use a Digital Devices GmbH Max S8 with 8 tuners in unicable mode on Astra 19.2E

After I made the switch two weeks ago I started to encounter no data errors in Kodi when trying to tune to a channel. This is sometimes randomly only once sometimes for a few minutes in a row and then it magically resolves itself again. This happens on all clients and as far as I have seen it only on one client at the time. Recordings also work fine all the time there was not a single missed/unusable one from vdr.

VNSI Server Pluging is started with -Pvnsiserver -d -t 4
I changed it from the default 10 sec timeout and no -d to see if it makes a difference.

I uploaded the whole VDR log here:
https://pastebin.com/gR7XFtTK

I tried to analyse it a bit already and my first guess was that the tuner its trying to tune to is not working somehow.

Since this was not issue for 2 years while watching with a VDR frontend my conclusion was that its somehow related to this plugin.

While writing this post and looking at all the other topics regarding the no data error I noticed that my VDR Loglevel was only on 2 I set to 3 now to get some more info out of it.

If it turns out that it is indeed an VDR problem and while the VDR frontend I never encountered the issue because it might just have switched to another tuner would it be possible for this plugin to do the same or does it rely on VDR giving out a tuner?

This is how it looks like in the logfile over the course of the evening:

cat /var/log/syslog.1 | grep -B 5 data | egrep 'data|device' | grep device -A 1
Aug 10 20:08:41 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 20:08:45 easyvdr vdr: [22374] VNSI: Channel: no data 16
--
Aug 10 21:17:24 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 21:17:28 easyvdr vdr: [22552] VNSI: Channel: no data 16
--
Aug 10 21:17:32 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 21:17:36 easyvdr vdr: [22555] VNSI: Channel: no data 16
Aug 10 21:17:38 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 21:17:42 easyvdr vdr: [22558] VNSI: Channel: no data 16
--
Aug 10 21:18:14 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 21:18:18 easyvdr vdr: [22561] VNSI: Channel: no data 16
--
Aug 10 21:18:25 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 21:18:29 easyvdr vdr: [22564] VNSI: Channel: no data 16
--
Aug 10 21:41:45 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 21:41:49 easyvdr vdr: [22639] VNSI: Channel: no data 16
--
Aug 10 21:41:58 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 21:42:02 easyvdr vdr: [22642] VNSI: Channel: no data 16
--
Aug 10 21:42:12 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 21:42:17 easyvdr vdr: [22645] VNSI: Channel: no data 16
--
Aug 10 21:42:22 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 21:42:26 easyvdr vdr: [22647] VNSI: Channel: no data 16
--
Aug 10 21:42:31 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 21:42:35 easyvdr vdr: [22651] VNSI: Channel: no data 16
--
Aug 10 21:42:50 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 21:42:54 easyvdr vdr: [22656] VNSI: Channel: no data 16
--
Aug 10 21:42:59 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 21:43:03 easyvdr vdr: [22660] VNSI: Channel: no data 16
Aug 10 21:43:06 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 21:43:10 easyvdr vdr: [22663] VNSI: Channel: no data 16
--
Aug 10 21:43:16 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 21:43:20 easyvdr vdr: [22666] VNSI: Channel: no data 16
--
Aug 10 21:57:42 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 21:57:46 easyvdr vdr: [22766] VNSI: Channel: no data 16
--
Aug 10 21:57:51 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 21:57:55 easyvdr vdr: [22769] VNSI: Channel: no data 16
--
Aug 10 23:04:37 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:04:41 easyvdr vdr: [22884] VNSI: Channel: no data 16
Aug 10 23:04:41 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:04:45 easyvdr vdr: [22887] VNSI: Channel: no data 16
--
Aug 10 23:04:56 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:05:00 easyvdr vdr: [22890] VNSI: Channel: no data 16
--
Aug 10 23:05:05 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:05:09 easyvdr vdr: [22893] VNSI: Channel: no data 16
--
Aug 10 23:05:13 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:05:17 easyvdr vdr: [22896] VNSI: Channel: no data 16
Aug 10 23:05:18 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:05:22 easyvdr vdr: [22899] VNSI: Channel: no data 16
--
Aug 10 23:05:34 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:05:38 easyvdr vdr: [22904] VNSI: Channel: no data 16
--
Aug 10 23:05:55 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:05:59 easyvdr vdr: [22911] VNSI: Channel: no data 16
--
Aug 10 23:06:04 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:06:08 easyvdr vdr: [22915] VNSI: Channel: no data 16
--
Aug 10 23:06:15 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:06:19 easyvdr vdr: [22917] VNSI: Channel: no data 16
--
Aug 10 23:06:24 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:06:28 easyvdr vdr: [22921] VNSI: Channel: no data 16
Aug 10 23:06:30 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:06:34 easyvdr vdr: [22924] VNSI: Channel: no data 16
--
Aug 10 23:06:44 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:06:48 easyvdr vdr: [22930] VNSI: Channel: no data 16
--
Aug 10 23:06:57 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:07:01 easyvdr vdr: [22934] VNSI: Channel: no data 16
--
Aug 10 23:07:07 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:07:11 easyvdr vdr: [22937] VNSI: Channel: no data 16
--
Aug 10 23:07:16 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:07:20 easyvdr vdr: [22939] VNSI: Channel: no data 16
--
Aug 10 23:07:24 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:07:28 easyvdr vdr: [22943] VNSI: Channel: no data 16
Aug 10 23:07:43 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:07:47 easyvdr vdr: [22947] VNSI: Channel: no data 16
--
Aug 10 23:11:19 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:11:23 easyvdr vdr: [22969] VNSI: Channel: no data 16
--
Aug 10 23:11:39 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:11:43 easyvdr vdr: [22973] VNSI: Channel: no data 16
--
Aug 10 23:11:47 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:11:51 easyvdr vdr: [22976] VNSI: Channel: no data 16
--
Aug 10 23:11:58 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:12:02 easyvdr vdr: [22982] VNSI: Channel: no data 16
--
Aug 10 23:14:15 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:14:19 easyvdr vdr: [22984] VNSI: Channel: no data 16
Aug 10 23:14:22 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:14:26 easyvdr vdr: [22991] VNSI: Channel: no data 16
Aug 10 23:14:30 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:14:34 easyvdr vdr: [22997] VNSI: Channel: no data 16
--
Aug 10 23:14:40 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:14:44 easyvdr vdr: [23000] VNSI: Channel: no data 16
--
Aug 10 23:15:10 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:15:14 easyvdr vdr: [23006] VNSI: Channel: no data 16
--
Aug 10 23:15:19 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:15:23 easyvdr vdr: [23009] VNSI: Channel: no data 16
Aug 10 23:15:23 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:15:27 easyvdr vdr: [23012] VNSI: Channel: no data 16
Aug 10 23:15:28 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:15:32 easyvdr vdr: [23015] VNSI: Channel: no data 16
Aug 10 23:15:43 easyvdr vdr: [22304] VNSI: Successfully found following device: 0x2897d60 (2) for receiving, priority=0
Aug 10 23:15:47 easyvdr vdr: [23018] VNSI: Channel: no data 16
--
Aug 11 00:27:59 easyvdr vdr: [23127] VNSI: Successfully found following device: 0x289e970 (3) for receiving, priority=5
Aug 11 00:28:03 easyvdr vdr: [23137] VNSI: Channel: no data 16
--
Aug 11 00:28:37 easyvdr vdr: [23145] VNSI: Successfully found following device: 0x289e970 (3) for receiving, priority=5
Aug 11 00:28:41 easyvdr vdr: [23148] VNSI: Channel: no data 16

Hello,
currently whenever you switch to a channel in Kodi timeshift gets activated instantly even though you don't need it. This means that any channel switch keeps recording its data to a file (all the time while you are watching the TV). It would be nice if the timeshift recording gets activated after you actually pause the video in Kodi. It would save the HDD and IMHO would perform better.

Similar change has been to the another PVR Kodi plugin in this commit
kodi-pvr/pvr.dvbviewer@2b8ab24

Thank you for considering this

I run on my vdr server the latest vdr-plugin-vnsiserver from git

initializing plugin: vnsiserver (1.5.2): VDR-Network-Streaming-Interface (VNSI) Server

The client logs following connect message:

10:27:56.223 T:140550380447488  NOTICE: AddOnLog: VDR VNSI Client: Logged in at '1503476876+7200' to 'VDR-Network-Streaming-Interface (VNSI) Server' Version: '1.5.2' with protocol version '11'

The server logs:

Aug 23 10:27:56 vnas vdr[4568]: [2363] VNSI: Welcome client 'XBMC Media Center' with protocol version '10'

Is this (protocol 10 vs. 11) something to investigate? As i having a simular issue as described in Issue #97 "no data error with VNSI"

If I can help further please advise.

I have both, VDR and Kodi, on one machine. VDR is in background for Live TV and to record programmed timers.

If the machine gets automatically booted for a recording, then with "Plain VDR" the machine is shut down as soon as the recording is done and if there was no user activity.

I know that Kodi has a built-in "inactivity timeout" feature, but I had to disable this as I often watch Twitch streams for many hours and don't want to press buttons on the remote control to keep Kodi running.

Is there any way to make Kodi detect that it was booted just for a recording (checks if the next recording is within X minutes on start) to make it trigger a shutdown as soon as the last recording is done?

I am the package maintainer for vdr-vnsiserver for Fedora and are using your repo for building the package. Currently I use a git hash to reference 1.1.0 but it would be better to use a tag/label, e.g. "1.1.0".

Could you please use tags/labels for better reference?

thanks!

Using vdr-plugin-vnsiserver with vdr 2.3.2 and kodi i get permanently segfaults:

kernel: [ 4806.910898] VNSITimers[5706]: segfault at 0 ip 00007f219837d9da sp 00007f2186ffcae8 error 4 in libc-2.23.so[7f21982df000+1bf000]

demuxer.c:628]: (style) Suspicious condition (assignment + comparison); Clarify expression with parentheses.

Source code is

while (len = m_VideoBuffer->Read(&buf, TS_SIZE, m_endTime, m_wrapTime) == TS_SIZE)

Maybe better code

while ((len = m_VideoBuffer->Read(&buf, TS_SIZE, m_endTime, m_wrapTime)) == TS_SIZE)

Hey,

My VDR kept crashing suddenly. Issue is located here:

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x7ffff1e7b700 (LWP 2174)]
0x00007ffff30beb0e in cVNSIClient::processRECORDINGS_GetDiskSpace (this=0x7fffb8001070) at vnsiclient.c:1669
1669 int Total = (FreeMB / (100 - Percent)) * 100;
(gdb) bt
#0 0x00007ffff30beb0e in cVNSIClient::processRECORDINGS_GetDiskSpace (this=0x7fffb8001070) at vnsiclient.c:1669
#1 0x00007ffff30c2868 in cVNSIClient::processRequest (this=0x7fffb8001070, req=) at vnsiclient.c:543
#2 0x00007ffff30c2a34 in cVNSIClient::Action (this=0x7fffb8001070) at vnsiclient.c:146
#3 0x00000000005142cd in cThread::StartThread (Thread=0x7fffb8001070) at thread.c:262
#4 0x00007ffff7974e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#5 0x00007ffff63ad38d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#6 0x0000000000000000 in ?? ()

Fix is:
bool cVNSIClient::processRECORDINGS_GetDiskSpace() /* OPCODE 100 */
{
int FreeMB;

if VDRVERSNUM >= 20102

int Percent = cVideoDirectory::VideoDiskSpace(&FreeMB);

else

int Percent = VideoDiskSpace(&FreeMB);

endif

int Total;

if (Percent < 100)
Total = FreeMB / (100 - Percent) * 100;
else
Total = 0;

Cheers,
Michael

Hi since i'm facing some problems with vdr 2.3.3 at the moment i wanted to try the dev 2.3.8

But it stops because of VNSI:

vdr: [30739] loading plugin: /usr/local/lib/vdr/libvdr-vnsiserver.so.2.3.8 vdr: [31395] ERROR: /usr/local/lib/vdr/libvdr-vnsiserver.so.2.3.8: undefined symbol: _ZNK7cTimers7GetByIdEi vdr: [30739] ERROR (ci.c,2990): (null): Ungültige Adresse vdr: [30739] exiting, exit code 2

ist it possible to fix? I tried it with 2.3.6 as well but it is the same.

Hi,
I have just tried to compile the plugin but got the folowing error:

$ git clone https://github.com/FernetMenta/vdr-plugin-vnsiserver
Cloning into 'vdr-plugin-vnsiserver'...
remote: Counting objects: 1288, done.
remote: Compressing objects: 100% (25/25), done.
remote: Total 1288 (delta 9), reused 0 (delta 0), pack-reused 1263
Receiving objects: 100% (1288/1288), 486.92 KiB | 235.00 KiB/s, done.
Resolving deltas: 100% (929/929), done.

$ cd vdr-plugin-vnsiserver/

$ make
g++  -std=c++11 -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"vnsiserver"' -DVNSI_SERVER_VERSION='"1.5.0"'  -o vnsi.o vnsi.c
g++  -std=c++11 -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"vnsiserver"' -DVNSI_SERVER_VERSION='"1.5.0"'  -o bitstream.o bitstream.c
g++  -std=c++11 -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"vnsiserver"' -DVNSI_SERVER_VERSION='"1.5.0"'  -o vnsiclient.o vnsiclient.c
vnsiclient.c: In member function ‘bool cVNSIClient::processTIMER_GetTypes(cRequestPacket&)’:
vnsiclient.c:1954:16: error: no matching function for call to ‘cResponsePacket::add_U32()
   resp.add_U32();
                ^
vnsiclient.c:1954:16: note: candidate is:
In file included from streamer.h:38:0,
                 from vnsiclient.c:31:
responsepacket.h:55:8: note: bool cResponsePacket::add_U32(uint32_t)
   bool add_U32(uint32_t ul);
        ^
responsepacket.h:55:8: note:   candidate expects 1 argument, 0 provided
make: *** [vnsiclient.o] Error 1

This is on Centos 7 with installed vdr 2.2.0. streamdev and dvbapi plugins have been compilled without any errors.

Any idea how to resolve this?

Thanks and regards, Casper.

Hello
With the change 3d6e4be vdr-2.2.0 does no longer compile.
This patch will correct it:

--- vnsiclient.c.org    2016-03-08 08:53:43.862787053 +0100
+++ vnsiclient.c        2016-03-08 09:02:12.106804520 +0100
@@ -1969,9 +1969,14 @@
     if (m_protocolVersion >= 9)
     {
       // channel uuid
-      const cChannel *channel = NULL;
+#if VDRVERSNUM >= 20301
       LOCK_CHANNELS_READ;
-      channel = Channels->GetByChannelID(recording->Info()->ChannelID());
+      const cChannel *channel = Channels->GetByChannelID(recording->Info()->ChannelID());
+#else
+      Channels.Lock(false);
+      const cChannel *channel = Channels.GetByChannelID(recording->Info()->ChannelID());
+      Channels.Unlock();
+#endif
       if (channel)
         resp.add_S32(CreateChannelUID(channel));
      else

hi please help me please i run this command in xbmc
$ git clone https://github.com/FernetMenta/vdr-plugin-vnsiserver
$ cd vdr-plugin-vnsiserver
$ make
$ sudo make install

but this error show me:
in file include from vnsiclient.c :26:0:
vnsiclient.h :87 :16 error virtical void cvnsiclient : :channelchange(const cchannel_) ' marked override but dos not override
virtical void cvnsiclient : :channelchange(const cchannel * channel ) ' override
makefile : 86:recipe for target 'vnsiclient.o' failed
make : *_* [vnsiclient.o] error 1

please help

When I try to compile, I get the follorwing error:

vnsitimer.c: In member function 'virtual void CVNSITimers::Action()':
vnsitimer.c:263:3: error: 'cStateKey' was not declared in this scope
cStateKey timerState;
^
vnsitimer.c:263:13: error: expected ';' before 'timerState'
cStateKey timerState;
^
vnsitimer.c:262:8: warning: unused variable 'modified' [-Wunused-variable]
bool modified;
^
make: *** [vnsitimer.o] Error 1

What can I do?

I have problem with message: VNSI-Error: cParser::AddPESPacket - max buffer size reached in log file after switching every DVB-S2 (mpeg4, h.264) encrypted channel on Eutelsat 36 satellite. In the Kodi gui a pop up window with message "Channel: no data" is shown. Accordingly, I can not watch these channels. But DVB-S encrypted channels working good.
It's not hardware or firmware problem because on the same system xvdr plugin (xvdr + vdr + oscam) working excellent. Problem only with vnsi + vdr + oscam.

I saw closed issue #55 but problem doesnot solved

What can i do?

My DVB-S2 card: TeVii S464 PCI
Ubuntu 16.04 x64

My versions:

dpkg -l vdr\*
ii  vdr                                      2.3.1-314~a26aae3-xenial  amd64                     
ii  vdr-plugin-dvbapi                        2.2.3-518~897c50e-xenial  amd64                    
ii  vdr-plugin-vnsiserver                    1:1.5.0-931~7ee66aa-xenia amd64     

Log after switching to Amedia channel:

Jul  8 14:23:24 ubuntu vdr: [6069] CAM 1: activating on device 1 with channel 11 (AMEDIA)
Jul  8 14:23:24 ubuntu vdr: [6069] VNSI: Successfully switched to channel 11 - AMEDIA
Jul  8 14:23:24 ubuntu vdr: [6069] VNSI: Started streaming of channel AMEDIA (timeout 10 seconds)
Jul  8 14:23:24 ubuntu vdr: [6071] cLiveStreamer stream processor thread started (pid=4068, tid=6071, prio=high)
Jul  8 14:23:24 ubuntu oscam[4066]: 14:23:24 244CF5DC c   (dvbapi) Demuxer 0 ecmpid 0 CAID: 0500 ECM_PID: 1006 PROVID: 040610
Jul  8 14:23:24 ubuntu oscam[4066]: 14:23:24 244CF5DC c   (dvbapi) Demuxer 0 ecmpid 1 CAID: 0500 ECM_PID: 106A PROVID: 040620
Jul  8 14:23:24 ubuntu oscam[4066]: 14:23:24 244CF5DC c   (dvbapi) Demuxer 0 ecmpid 2 CAID: 0500 ECM_PID: 1452 PROVID: 050A00
Jul  8 14:23:24 ubuntu oscam[4066]: 14:23:24 244CF5DC c   (dvbapi) Demuxer 0 ecmpid 3 CAID: 0500 ECM_PID: 1772 PROVID: 060A00
Jul  8 14:23:24 ubuntu oscam[4066]: 14:23:24 244CF5DC c   (dvbapi) Demuxer 0 ecmpid 4 CAID: 0500 ECM_PID: 183A PROVID: 060C00
Jul  8 14:23:24 ubuntu oscam[4066]: 14:23:24 244CF5DC c   (dvbapi) Demuxer 0 found 5 ECMpids and 3 STREAMpids in caPMT
Jul  8 14:23:24 ubuntu oscam[4066]: 14:23:24 244CF5DC c   (dvbapi) Demuxer 0 found channel in cache and matching prio -> start descrambling ecmpid 1
Jul  8 14:23:24 ubuntu oscam[4066]: 14:23:24 244CF5DC c   (dvbapi) Demuxer 0 trying to descramble PID 1 CAID 0500 PROVID 040620 ECMPID 106A ANY CHID PMTPID 0000 VPID 00CA
Jul  8 14:23:24 ubuntu vdr: [6070] device 1 receiver thread started (pid=4068, tid=6070, prio=high)
Jul  8 14:23:24 ubuntu vdr: [6072] device 1 TS buffer thread started (pid=4068, tid=6072, prio=high)
Jul  8 14:23:24 ubuntu vdr: [6071] VNSI: Created stream for pid=202 and type=7
Jul  8 14:23:24 ubuntu vdr: [6071] VNSI: Created stream for pid=302 and type=2
Jul  8 14:23:24 ubuntu vdr: [6071] VNSI: Created stream for pid=402 and type=2
Jul  8 14:23:24 ubuntu vdr: [6071] VNSI: Created stream for pid=502 and type=11
Jul  8 14:23:24 ubuntu vdr: [6071] VNSI: Audio stream change, pid: 402, channels: 2, samplerate: 48000
Jul  8 14:23:24 ubuntu vdr: [6071] VNSI: Audio stream change, pid: 302, channels: 2, samplerate: 48000
Jul  8 14:23:25 ubuntu vdr: [4151] VNSI: Requesting clients to load epg
Jul  8 14:23:25 ubuntu oscam[4066]: 14:23:25 244CF5DC c      (ecm) anonymous (0500@040620/289F/0836/56:EBD7F8C0283C3DED6DB1253806150C1B): found (1080 ms) by ntv+
Jul  8 14:23:30 ubuntu vdr: [4151] VNSI: Requesting clients to load epg
Jul  8 14:23:30 ubuntu vdr: [6070] CAM 1: activated!
Jul  8 14:23:30 ubuntu vdr: [6071] VNSI-Error: cParser::AddPESPacket - max buffer size reached, pid: 202
Jul  8 14:23:30 ubuntu vdr: [4068] info: CAM activated!
Jul  8 14:23:30 ubuntu vdr: [4068] ERROR: no OSD provider available - using dummy OSD!
Jul  8 14:23:32 ubuntu oscam[4066]: 14:23:32 244CF5DC c      (ecm) anonymous (0500@040620/289F/0836/56:2B3DD1853AEDEF185C6973EFF3E85921): found (404 ms) by ntv+
Jul  8 14:23:34 ubuntu vdr: [6071] VNSI: Channel: no data 16
Jul  8 14:23:35 ubuntu vdr: [4151] VNSI: Requesting clients to load epg
Jul  8 14:23:36 ubuntu vdr: [6071] VNSI-Error: cParser::AddPESPacket - max buffer size reached, pid: 202
Jul  8 14:23:40 ubuntu vdr: [4151] VNSI: Requesting clients to load epg
Jul  8 14:23:42 ubuntu oscam[4066]: 14:23:42 244CF5DC c      (ecm) anonymous (0500@040620/289F/0836/56:7216C4AB862EC5082B298E10E96818B4): found (565 ms) by ntv+

According to man vdr(5), in the timers.conf file "If the name contains any ':' characters, these have to be replaced by '|'. If the name shall contain subdirectories, these have to be delimited by '~' (since the '/' character may be part of a regular programme name)."
The plugin does not replace ':' characters by '|', so if a timer is created which contains a colon (eg "New: Downton Abbey"), the filename becomes simply "New".

Using the VNSI plugin, lately I had missed quite a few recordings, which is obviously quite annoying.

Looking into the vdr log shows messages of the pattern:

Mar 27 20:35:03 rsjlaa vdr[20036]: [20071] VNSI: Client with ID 12 connected: 127.0.0.1:37184
Mar 27 20:35:03 rsjlaa vdr[20036]: [3018] VNSI Client 12->127.0.0.1:37184 thread started (pid=20036, tid=3018, prio=high)
Mar 27 20:35:03 rsjlaa vdr[20036]: [3018] VNSI: Welcome client 'XBMC Media Center' with protocol version '8'
Mar 27 20:35:04 rsjlaa vdr[20036]: [20072] VNSI: Trigger EPG update for channel BBC NEWS, id: 2054409319
Mar 27 20:35:04 rsjlaa vdr[20036]: [20072] VNSI: Trigger EPG update for channel CBBC, id: 447096185
Mar 27 20:35:04 rsjlaa vdr[20036]: [20072] VNSI: Trigger EPG update for channel CBeebies, id: 471072513
Mar 27 20:35:04 rsjlaa vdr[20036]: [20072] VNSI: Trigger EPG update for channel BBC One Scot, id: 107324392
[...]
Mar 27 20:35:05 rsjlaa vdr[20036]: [20036] editing timer 2 (35 2158-2310 'The Night Manager')
[...]
Mar 27 20:35:14 rsjlaa vdr[20036]: [20036] timer 2 (35 2158-2310 'The Night Manager') modified (inactive)
[...]
Mar 27 20:35:14 rsjlaa vdr[20036]: [20072] VNSI: Timers state changed (14)
Mar 27 20:35:14 rsjlaa vdr[20036]: [20072] VNSI: Requesting clients to reload timers

I can't see any messages around that area that would explain the change of the timer to inactive.

I'm happy to look into other places if necessary.

Hallo FernetMenata ich habe deinen VNSI Server auf Debian im einsatz. Von einem Tag zum anderen hat er aufgehört zu funktionieren und produziert folgende Einträge im Syslog:

[4549] closing SVDRP connection
[4559] VNSI: Requesting clients to reload recordings list
[4559] VNSI: Recordings state changed (8333)
[4559] VNSI: Requesting clients to reload recordings list
[4559] VNSI: Recordings state changed (8334)
[4559] VNSI: Requesting clients to reload recordings list
[4559] VNSI: Recordings state changed (8335)
[4559] VNSI: Requesting clients to reload recordings list

Die Liste wird munter hochgezählt und im Kodi kann ich zwar die Kanalliste laden aber sobald ich einen Kanal auswehle passiert garnix, nicht mal eine Fehlermeldung.

Newest vdr-plugin-vnsiserver doesn't work with newest xbmc build since GUI API version isn't met:

ERROR: PVR - Add-on 'VDR VNSI Client' is using an incompatible GUI API version. XBMC minimum GUI API version = '5.3.0', add-on GUI API version '5.0.1'
WARNING: UpdateAndInitialiseClients - failed to create add-on VDR VNSI Client, status = 6
WARNING: UpdateAndInitialiseClients - failed to load the dll for add-on VDR VNSI Client, disabling it

Add-On can't be loaded due to this.

I did a git fetch today in the hopes of upgrading vdr from 2.2.0 to 2.3.1 I recompiled against both 2.2.0 and 2.3.1 and I get symbol errors at runtime. I can no longer run with 2.2.0 either.

When running with 2.2.0, I get this symbol error:
vdr: /usr/local/lib/vdr/libvdr-vnsiserver.so.2.2.0: undefined symbol: _ZNK4cOsd13MaxPixmapSizeEv

When running with 2.3.1, I get this symbol error:
vdr: /usr/local/lib/vdr/libvdr-vnsiserver.so.2.3.1: undefined symbol: Channels

Could I be doing something wrong in the build against vdr? My build against 2.2.0 had been working until todays update to the git head.

Best Regards,
Jim

Hi,

VDR 2.0.6 with git code of VNSI plugin. Switching a channel resulted in this crash (using gdb and then doing 'bt') - doesn't happen often, only sometimes. Not sure what other data could be of use.

vdr: malloc.c:4294: malloc_consolidate: Assertion `nextchunk->fd_nextsize->bk_nextsize == nextchunk' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffa2ffd700 (LWP 1231)]
0x00007ffff62ee4f5 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x00007ffff62ee4f5 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff62f1c5b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff633622d in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007ffff633711e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007ffff6338566 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#5 0x00007ffff633b0b5 in malloc () from /lib/x86_64-linux-gnu/libc.so.6
#6 0x00007ffff6c3fded in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7 0x00007ffff30bef2b in cVNSIClient::StartChannelStreaming (this=0x7fffa4005030, channel=0x89a400, priority=0, timeshift=1 '\001', timeout=10) at vnsiclient.c:168
#8 0x00007ffff30bfb54 in cVNSIClient::processChannelStream_Open (this=0x7fffa4005030) at vnsiclient.c:764
#9 0x00007ffff30c4fc2 in cVNSIClient::processRequest (this=0x7fffa4005030, req=) at vnsiclient.c:425
#10 0x00007ffff30c52b4 in cVNSIClient::Action (this=0x7fffa4005030) at vnsiclient.c:145
#11 0x00000000004ffb4d in cThread::StartThread (Thread=0x7fffa4005030) at thread.c:262
#12 0x00007ffff7974e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0*

Hello,
I watch TV on my VDR and if a Kodi client connect via VNSI the channelinfo (from the channel there is watched with Kodi) pop up on VDR. If i now press the button for Channelinfo on VDR, they also show the channelinfo of the Kodi client. In addition if I change the Channel on VDR it does not go to the next channel according to VDR but according to Kodi client.

See http://www.vdr-portal.de/board16-video-disk-recorder/board99-distributionen/board96-yavdr/130538-umschalten-vnsi-client/?s=c570a380397b40d191fbd7810b823d11ece8c990

The subj is printed to the syslog every 5 sec. Are there really any changes in the EPG every 5 sec?

Playing a record while recording will stop at the moment where the playback reaches the moment of starting playback.

I see still compile warnings with gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)

vnsiclient.c: In member function ‘bool cVNSIClient::processTIMER_Update(cRequestPacket&)’:
vnsiclient.c:1915:5: warning: ‘type’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     if (type == VNSI_TIMER_TYPE_VPS)
     ^

videoinput.c: In member function ‘virtual void cLivePatFilter::Process(u_short, u_char, const u_char*, int)’:
videoinput.c:202:17: warning: variable ‘ProcessCaDescriptors’ set but not used [-Wunused-but-set-variable]
            bool ProcessCaDescriptors = false;
                 ^

Long time ago there where changes in VDRs cVideoDirectory. Maybe you missed that. After your latest git changes, i couldn't compile anymore. This patch helps.

diff --git a/vnsiclient.c b/vnsiclient.c
index 904916f..48b7325 100644
--- a/vnsiclient.c
+++ b/vnsiclient.c
@@ -2480,7 +2480,7 @@ bool cVNSIClient::processRECORDINGS_DELETED_Delete() /* OPCODE 183 */
   cString recName;
   cRecording* recording = NULL;

-  cLockFile LockFile(VideoDirectory);
+  cLockFile LockFile(cVideoDirectory::Name());
   if (LockFile.Lock())
   {
     uint32_t uid = m_req->extract_U32();
@@ -2491,7 +2491,7 @@ bool cVNSIClient::processRECORDINGS_DELETED_Delete() /* OPCODE 183 */
     {
       if (uid == CreateStringHash(recording->FileName()))
       {
-        if (!RemoveVideoFile(recording->FileName()))
+        if (!cVideoDirectory::RemoveVideoFile(recording->FileName()))
         {
           ERRORLOG("Error while remove deleted recording (%s)", recording->FileName());
           m_resp->add_U32(VNSI_RET_ERROR);
@@ -2532,7 +2532,7 @@ bool cVNSIClient::Undelete(cRecording* recording)
     {
       if (access(recording->FileName(), F_OK) == 0)
       {
-        if (!RenameVideoFile(recording->FileName(), NewName))
+        if (!cVideoDirectory::RenameVideoFile(recording->FileName(), NewName))
         {
           ERRORLOG("Error while rename deleted recording (%s) to (%s)", recording->FileName(), NewName);
         }
@@ -2589,7 +2589,7 @@ bool cVNSIClient::processRECORDINGS_DELETED_Undelete() /* OPCODE 184 */
 {
   int ret = VNSI_RET_DATAUNKNOWN;

-  cLockFile LockFile(VideoDirectory);
+  cLockFile LockFile(cVideoDirectory::Name());
   if (LockFile.Lock())
   {
     uint32_t uid = m_req->extract_U32();
@@ -2622,7 +2622,7 @@ bool cVNSIClient::processRECORDINGS_DELETED_DeleteAll() /* OPCODE 185 */
 {
   int ret = VNSI_RET_OK;

-  cLockFile LockFile(VideoDirectory);
+  cLockFile LockFile(cVideoDirectory::Name());

   if (LockFile.Lock())
   {
@@ -2631,7 +2631,7 @@ bool cVNSIClient::processRECORDINGS_DELETED_DeleteAll() /* OPCODE 185 */
     for (cRecording *recording = DeletedRecordings.First(); recording; )
     {
       cRecording *next = DeletedRecordings.Next(recording);
-      if (!RemoveVideoFile(recording->FileName()))
+      if (!cVideoDirectory::RemoveVideoFile(recording->FileName()))
       {
         ERRORLOG("Error while remove deleted recording (%s)", recording->FileName());
         ret = VNSI_RET_ERROR;

Whit the newest commit(dccf71e) i get this Error and VDR restarts:
Jul 22 19:36:21 [vdr] [20331] DVB API version is 0x050A (VDR was built with 0x050A)
Jul 22 19:36:21 [vdr] [20331] frontend 0/0 provides DVB-C,DVB-T with QAM16,QAM32,QAM64,QAM128,QAM256 ("STV0367 DVB-C DVB-T")
Jul 22 19:36:21 [vdr] [20331] ERROR: can't open DVB device 0/0
Jul 22 19:36:21 [vdr] [20331] frontend 0/1 provides DVB-C,DVB-T with QAM16,QAM32,QAM64,QAM128,QAM256 ("STV0367 DVB-C DVB-T")
Jul 22 19:36:21 [vdr] [20331] ERROR: can't open DVB device 0/1
Jul 22 19:36:21 [vdr] [20331] frontend 1/0 provides DVB-C,(null) with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("Philips TDA10023 DVB-C")
Jul 22 19:36:21 [vdr] [20331] ERROR: can't open DVB device 1/0
Jul 22 19:36:21 [vdr] [20331] found 3 DVB devices

With commit 73307d1 all is OK.

Hi FernetMenta,

I am on openmediavault 3.0.13 (debian jessie 8.4, 4.4.0-0.bpo.1-amd64) and use the plugins omv-vdr 3.0.2, omv-vdr-extras 3.0.1 and omv-vdr-vnsiserver 3.0.0 (v1.3.1).

root@:~# vdr -V
vdr (2.0.3/2.0.0) - The Video Disk Recorder
epgsearchonly (0.0.1) - Direct access to epgsearch's search menu
epgsearch (1.0.1.beta3) - search the EPG for repeats and more
live (0.2.0) - Live Interactive VDR Environment
xineliboutput (1.1.0) - X11/xine-lib output plugin
quickepgsearch (0.0.1) - Quick search for broadcasts
conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu
streamdev-server (0.6.0-git) - VDR Streaming Server
vnsiserver (1.3.1) - VDR-Network-Streaming-Interface (VNSI) Server

As the frontend I use a windows 10 x64 (vnsiclient v1.11.14) machine with kodi 16.0 (with 16.1rc2 I have the same problem).

LiveTV works as expected, but when I try to open "system - tv - client specific - client specific settings" I get the following message.

Error: Exception caught on main loop. Exiting

In the following thread you find a screenshot of the error message:

http://www.vdr-portal.de/board60-linux/board62-software/board95-xbmc-kodi/p1270231-vdr-vdr-plugin-vnsiserver-kodi-kein-tv/#post1270231

Because of this it's not possible to configure the timeshift.

Where is the problem?

Greetings Hoppel

I'm using VDR Manager ( http://projects.vdr-developer.org/projects/vdr-manager/wiki ) to read EPG, stream recordings etc. But any other VDR client is also affected (I guess).

When I watch TV using Kodi, it would be awesome if I could switch channels using another VDR client.
At this time, the stream just stops.

Maybe vdr-plugin-vnsiserver could try to detect the active channel change and continue playback?
I think it would be nice if different clients could co-exist nicely, considering the server-client architecture of VDR.

Hi, i have frequent issues with the vnsi server under KODI 17 rc2. It works sometimes and somtimes not. It is in a loop of fetching channels. My syslog says frequently:

Jan 4 20:20:58 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:21:02 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:21:03 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:21:07 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:21:08 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:21:12 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:21:13 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:21:17 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:21:18 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:21:22 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:21:23 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:21:27 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:21:28 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:21:32 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:21:33 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:21:37 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:21:38 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:21:42 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:21:43 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:21:47 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:21:48 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:21:52 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:21:53 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:21:57 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:21:58 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:22:02 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:22:03 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:22:07 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:22:08 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:22:12 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:22:13 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:22:17 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:22:18 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:22:22 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:22:23 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:22:27 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:22:28 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:22:33 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:22:33 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:22:38 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:22:38 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:22:39 superserver vdr: [2618] VNSI: Requesting clients to reload channel list
Jan 4 20:22:43 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:22:43 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:22:48 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:22:48 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:22:53 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:22:53 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:22:58 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:22:58 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:23:03 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:23:03 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:23:08 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:23:08 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:23:13 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:23:13 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:23:13 superserver vdr: [2618] VNSI: Requesting clients to reload channel list
Jan 4 20:23:18 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:23:18 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:23:23 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:23:23 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:23:28 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:23:28 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:23:31 superserver vdr: [2635] SVDRP < 127.0.0.1:50823 client connection accepted
Jan 4 20:23:33 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:23:33 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:23:33 superserver vdr: [2635] SVDRP < 127.0.0.1:50823 connection closed
Jan 4 20:23:36 superserver vdr: [2618] VNSI: Requesting clients to reload channel list
Jan 4 20:23:38 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:23:38 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:23:43 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:23:43 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:23:48 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:23:48 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:23:53 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:23:53 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:23:58 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:23:58 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:24:03 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:24:03 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:24:08 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:24:08 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:24:13 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:24:13 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:24:18 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:24:18 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:24:23 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:24:23 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:24:28 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:24:28 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:24:33 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:24:33 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:24:38 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:24:38 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:24:43 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:24:43 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:24:48 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:24:48 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:24:53 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:24:53 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:24:58 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:24:58 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:25:03 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:25:03 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:25:08 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:25:08 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:25:13 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:25:13 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:25:18 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:25:18 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:25:23 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:25:23 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:25:28 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:25:29 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:25:33 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:25:34 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:25:39 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:25:39 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:25:44 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:25:44 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:25:49 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:25:49 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:25:54 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:25:54 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:25:59 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:25:59 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:26:04 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:26:04 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:26:09 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:26:09 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:26:14 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:26:14 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:26:19 superserver vdr: [2618] VNSI: Requesting clients to load epg
Jan 4 20:26:19 superserver vdr: [2618] VNSI: Requesting clients to reload timers
Jan 4 20:26:19 superserver vdr: [2598] ERROR: invalid value for parameter 'M'
Jan 4 20:26:19 superserver vdr: [2598] ERROR: invalid value for parameter 'M'
Jan 4 20:26:19 superserver vdr: [2603] ERROR: invalid value for parameter 'M'
Jan 4 20:26:19 superserver vdr: [2609] ERROR: invalid value for parameter 'M'

Hello,
currently iam using xvdr because earlier it was more stable on openelec x86_64 and raspberry pi and also faster. But it has not so much features as vnsi. Also the channel handling is a bit heavy with vnsi when you have 4 satelites with more than 4500 tv/radio channels. I have playing with vnsi and have got filtered the channels which i am interested in. Also i have a script written for xvdr which is doing nearly the same. But more for my needs. When i am comparing the solutions of boths i see some benefits in xvdr: it is filtering the channels on server side and the channel import is a lot faster because from the over 4500 channels it has filtered out a lot and "only" round about 1800 channels and epg data are imported. VNSI seems to filtering it on client side. All data is imported... and on a raspberrypi it is also slower therefore. Also a script is more flexible. For example i want new channels sorted into the last position of the group where it member of if.
I don't know how much work it would be to import this functionality, but as an option it would be great. Everyone could do what he wants. Handling it via GUI or via script.

thanks

With latest Git (7ee66aa) I observe sometimes, that the client does not play audio after channel switch. switching channels forward and back, audio is played then. It seams not related to scrambled or not scrambled

Any idea?

Some days ago, the following happened:

• I have two recordings with exactly the same name (which would show up as two equal entries in plain VDR and is grouped into a folder on Kodi side with your latest changes).
• I entered this directory (non-visible in VDR, visible in Kodi) and deleted one recording.
• Now Kodi somewhat reacted unexpected and threw me out of the directory.
• Searching for the second recording now was unsuccessful. Seems like both are gone.

I'm not 100% sure if this really is a major problem and I don't have any more recordings, I want to loose. So please just double check that your new code (with the directories, usually not visible directly in VDR) really works the way it should, especially if it gets to deleting recordings.