pipelka / vdr-plugin-xvdr

DISCONTINUED - XVDR Plugin for VDR
GNU General Public License v2.0
43 stars 22 forks source link

recordings on nfs share fail to play #47

Closed dajoe closed 11 years ago

dajoe commented 12 years ago

I run vdr 1.7.22 on a separate machine which saves the recordings to a nfs share (actually, it is a virtual machine on the same system as xbmc runs on). I use Pipelka's xbmc branch, xvdr pvr addon and vdr plugin in the latest git revision.

when I try to replay a recording, xbmc hangs until timeout and the vdr machine's log gets flooded with error messages like:

Feb 3 23:10:42 vdr vdr: [11000] XVDR: file failed to open Feb 3 23:10:42 vdr vdr: [11000] XVDR: openFile called for index 0 string:/mnt/media_deimos/recordings/Amadeus/2011-12-25.20.13.46-0.rec/00001.ts Feb 3 23:10:42 vdr rsyslogd-2177: imuxsock begins to drop messages from pid 10810 due to rate-limiting Feb 3 23:10:55 vdr rsyslogd-2177: imuxsock lost 2557 messages from pid 10810 due to rate-limiting

I looked into the code and replaced the line in recordings/recplayer.c: m_file = open(m_fileName, O_RDONLY | O_NOATIME); with m_file = open(m_fileName, O_RDONLY);

I don't quite understand what I did but it helped. Now it works. It did work when vdr and xbmc were on the same system, though.

Best regards, Johannes .

carsten12 commented 12 years ago

Are the nfs shares going into sleep mode? If so, you could try to increase the timeout value in the addon.

On the other hand I use quite the same setting (although the XBMC is physically on a different machine) and I use SAMBA successfully to do so.

O_NOATIME will prevent that the access to the file is loged. Which could lead to the assumption that the share is not mounted with write access or some other access problems occured...

dajoe commented 12 years ago

You are right. The problem was that idmapd did not start on the virtual machine (ubuntu precise), since /var/lib/nfs/rpc_pipefs has moved to /run/rpc_pipefs with the update from natty to oneiric, I think. The old path was still wrongly set in /etc/idmapd.conf. This resulted in invalid ownership settings in the mounted nfs directory.

Now, O_NOATIME works and the recordings are accessible.

Mysterious to me though, that vdr did have write access to that directory. Recording worked propoerly...

AndreyPavlenko commented 11 years ago

I'm getting the same error (file failed to open) if my /var/lib/video.00 is symbolic link to a directory, located on different (NTFS) partition on the same hard drive: /var/lib/video.00 -> /mnt/hd/share/Video/Recordings

AndreyPavlenko commented 11 years ago

Moreover, the same error if I change the VDR video dir to -v /mnt/hd/share/Video/Recordings:

Mar 7 23:44:06 htpc vdr: [13133] XVDR: openFile called for index 0 Mar 7 23:44:06 htpc vdr: [13133] XVDR: openFile called for index 0 string:/mnt/hd/share/Video/Recordings/CNN_International/2013-03-07.23.43.29-0.rec/00001.ts Mar 7 23:44:06 htpc vdr: [13133] XVDR: file failed to open

pipelka commented 11 years ago

@AndreyPavlenko Does removing the O_NOATIME flag fix the problem for you ?

AndreyPavlenko commented 11 years ago

Yes, it does.

pipelka commented 11 years ago

Seems NTFS doesn't like the NOATIME mount flag. I'll add a fallback.