Kodi Community Forum

Hi guys,
I'm getting crazy around some troubles I'm experiencing with VDR and XBMC. My configuration is this:

Backend (VDR):
Intel DN2800MT
Kingston 4GB RAM
Terratec Cinergy T PCIe Dual HD
GNU/Linux Ubuntu 12.04 (Precise Pangolin)

Frontend (XBMC):
Rasberry Pi

I tried both TVheadend and VDR on the backend and the last one seems to be more stable although I'd prefer using TVH. However VDR is the actual configuration and I'm not planning to head back for now. I'm using yaVDR PPA (unstable-vdr).

I tried using either VNSI and XVDR for streaming live TV but I'm having issues with both of them: XVDR has major a/v sync issues so I discarded it; VNSI seems to work good but sometimes it just stops working. Here's the VDR log at the time this happens:

Quote:Jun 22 14:01:46 jupiter vdr: [4221] VNSI: Requesting clients to reload channel list
Jun 22 14:01:47 jupiter vdr: [6121] VNSI-Error: cxSocket::read: read() error at 0/4
Jun 22 14:01:47 jupiter vdr: [4221] VNSI: Requesting clients to reload channel list
Jun 22 14:01:47 jupiter vdr: [6124] VNSI: exit streamer thread
Jun 22 14:01:47 jupiter vdr: [6124] cLiveStreamer stream processor thread ended (pid=4193, tid=6124)
Jun 22 14:01:47 jupiter vdr: [6125] TS buffer on device 1 thread ended (pid=4193, tid=6125)
Jun 22 14:01:47 jupiter vdr: [6122] buffer stats: 69936 (1%) used
Jun 22 14:01:47 jupiter vdr: [6122] receiver on device 1 thread ended (pid=4193, tid=6122)
Jun 22 14:01:47 jupiter vdr: [4221] VNSI: Client with ID 21 seems to be disconnected, removing from client list

I played with Xbian, Raspmc and OpenElec (all stable versions) and it appears to be the same on all of them. The stream stops and XMBC takes me back to the TV programs list. If I just start a new streaming session everything seems to work again (until the next stop).

What should I do? With streamdev it seems it work flawlessy on my desktop PC.

Seems to be this issue: http://forum.xbmc.org/showthread.php?tid...pid1444725

This is a problem in the socket layer and affects not only vnsi. I will look into it next week.

(2013-06-22, 16:59)FernetMenta Wrote: [ -> ]This is a problem in the socket layer and affects not only vnsi. I will look into it next week.

Ok good. Thank you.

BTW: I would like to help you in testing VNSI4. Is there something already cooked or I have to build everything (OE and VDR)? Compile time on RPi is... I don't know the right term... XD

Check out this thread: http://forum.xbmc.org/showthread.php?tid=167359
Since vnsi4 is in opdenkamp repo there are already builds.

(2013-06-23, 08:55)FernetMenta Wrote: [ -> ]Check out this thread: http://forum.xbmc.org/showthread.php?tid=167359
Since vnsi4 is in opdenkamp repo there are already builds.

Tried the last build and of course now the VDR plugins tells me:

Quote:VNSI-Error: Client 'XBMC Media Center' have a not allowed protocol version '4', terminating client

Which is good. Now, in order to compile the VDR plugin from your git repo what should I do?

EDIT: Sorry, I didn't see the sticky thread. I followed the instruction and I started compiling the plugin BUT it fails like this:

Quote:/usr/bin/ld: vnsi.o: relocation R_X86_64_32S against `vtable for cPluginVNSIServer' can not be used when making a shared object; recompile with -fPIC
vnsi.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libvdr-vnsiserver4.so] Error 1

What should I do? My system is:

Quote:Linux jupiter 3.5.0-34-generic #55~precise1-Ubuntu SMP Fri Jun 7 16:25:50 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

what version of vdr do you use? how did you get the sources of vdr. please elaborate on your build steps.

I have updated the sticky. for vdr > 1.7.33 type only make

I'm using VDR 2.0.2 from yaVDR PPA. I got the sources there. BTW typing only "make" did the trick but still no joy:

Quote:Jun 23 11:29:11 jupiter vdr: [29410] VNSI: Client with ID 0 connected: 192.168.1.250:41265
Jun 23 11:29:11 jupiter vdr: [29420] VNSI: Welcome client 'XBMC Media Center' with protocol version '4'
Jun 23 11:29:12 jupiter vdr: [29410] VNSI: Requesting clients to reload channel list
Jun 23 11:29:17 jupiter vdr: [29410] VNSI: Recordings state changed (2)
Jun 23 11:29:17 jupiter vdr: [29410] VNSI: Requesting clients to reload recordings list
Jun 23 11:29:17 jupiter vdr: [29409] XVDR: Recordings state changed (2)
Jun 23 11:29:19 jupiter vdr: [29409] XVDR: Starting garbage collection in recordings cache
Jun 23 11:29:41 jupiter vdr: [29410] loading /var/lib/vdr/plugins/vnsiserver4/allowed_hosts.conf
Jun 23 11:29:41 jupiter vdr: [29410] VNSI: Client with ID 1 connected: 192.168.1.250:41269
Jun 23 11:29:41 jupiter vdr: [29423] VNSI: Welcome client 'XBMC Media Center' with protocol version '4'
Jun 23 11:29:41 jupiter vdr: [29423] VNSI: LiveStreamer::Close - close
Jun 23 11:29:41 jupiter vdr: [29424] receiver on device 1 thread started (pid=29382, tid=29424, prio=high)
Jun 23 11:29:41 jupiter vdr: [29423] VNSI: Successfully switched to channel 4 - Rai 4
Jun 23 11:29:41 jupiter vdr: [29426] cLiveStreamer stream processor thread started (pid=29382, tid=29426, prio=high)
Jun 23 11:29:41 jupiter vdr: [29423] VNSI: Started streaming of channel Rai 4 (timeout 10 seconds)
Jun 23 11:29:41 jupiter vdr: [29427] TS buffer on device 1 thread started (pid=29382, tid=29427, prio=high)
Jun 23 11:29:41 jupiter vdr: [29405] VNSI: Video Input - new pmt, attaching receiver
Jun 23 11:29:41 jupiter vdr: [29426] VNSI: Created stream for pid=433 and type=7
Jun 23 11:29:41 jupiter vdr: [29426] VNSI: Created stream for pid=443 and type=2
Jun 23 11:29:41 jupiter vdr: [29426] VNSI: Created stream for pid=543 and type=2
Jun 23 11:29:41 jupiter vdr: [29426] VNSI: Created stream for pid=585 and type=11
Jun 23 11:29:55 jupiter vdr: [29423] VNSI: cxSocket::read: eof, connection closed
Jun 23 11:29:55 jupiter vdr: [29426] VNSI: exit streamer thread
Jun 23 11:29:55 jupiter vdr: [29426] cLiveStreamer stream processor thread ended (pid=29382, tid=29426)
Jun 23 11:29:55 jupiter vdr: [29423] VNSI: LiveStreamer::Close - close
Jun 23 11:29:55 jupiter vdr: [29427] TS buffer on device 1 thread ended (pid=29382, tid=29427)
Jun 23 11:29:55 jupiter vdr: [29424] buffer stats: 60724 (1%) used
Jun 23 11:29:55 jupiter vdr: [29424] receiver on device 1 thread ended (pid=29382, tid=29424)
Jun 23 11:29:55 jupiter vdr: [29410] VNSI: Client with ID 1 seems to be disconnected, removing from client list

What's the problem now?

that both xvdr and vnsi are running perhaps?

I was told this should work. From the snippet of the log it is not clear if the user terminated connection or this was done automatically. In case of the latter it points to https://github.com/opdenkamp/xbmc-pvr-addons/pull/181

(2013-06-23, 11:41)FernetMenta Wrote: [ -> ]What's the problem now?

Still the same: after some time the stream buffer is emptied and it stops. May it be related to bad signal? I mean: what if the signal is too low to fill the buffer in time to stream the data back to the RPi? It is not something it does after X seconds. It's a random behaviour but it always happens after some time.

(2013-06-23, 15:40)opdenkamp Wrote: [ -> ]that both xvdr and vnsi are running perhaps?

Do they not get along together?

If signal is too low and the buffer runs dry, playback is just kind of paused. Once the signal is back it will continue.
I think you hit the problem I posted the link. If you post a XBMC debug log, we can verify.

(2013-06-23, 22:08)FernetMenta Wrote: [ -> ]If signal is too low and the buffer runs dry, playback is just kind of paused. Once the signal is back it will continue.

Thank you for the explanation.

(2013-06-23, 22:08)FernetMenta Wrote: [ -> ]I think you hit the problem I posted the link. If you post a XBMC debug log, we can verify.

Lucky me!

Here's the log. Plese tell me if it's good or I have to redo it with some specific settings (I just enabled "debug" log in the "system" settings and I got the file from /storage/.xbmc/temp/xbmc.log as the OSD pointed out.

EDIT: I checked out the log and it seems the connection was lost around line 1765. The first part of the log was not syncronized with NTP: I sat up NTP client and I did the test again.

This is the indicator that I was right with my assumption. The good news is that we know the cause and will fix soon.