2012-12-24, 17:24
I'm pretty sure this is a bug, but other people will have a better idea whether it's a *new* bug.
I have my DVDs ripped in VIDEO_TS format to a NAS box, which then exports them again, both via NFS and SMB.
I have the NFS mount actually mounted on my Linux box, but would prefer to use nfs:// as a path, in order to keep compatibility with my Windows machines (who can't see all the filenames cleanly over SMB, due to filename restrictions).
ETA: I'm using XBMC 12.0-RC2, on a Ubuntu 12.10 install.
Here are four (my, you are lucky!) different logs. In each case, I've started from a clean Movie Library, added the Video source, and the DVD of "Hugo" (the shortest filename I've got, in case that was part of the problem), and then attempted to play it. After each session, I cleared the source out again (but didn't bother to log that).
1. mounting the NFS export directly under Linux: http://paste.ubuntu.com/1462108/ This works.
2. mounting the NFS export using XBMC's own nfs internals. http://paste.ubuntu.com/1462140/ This fails.
3. mounting the SMB export using XBMC's on SMB internals. http://paste.ubuntu.com/1462145/ This also fails.
I did notice in those two failing logs (line 853 in the second log, line 870 in the third) that there's an extra notification:
INFO: msg: libdvdread: Attempting to use device /home/tommy/.Private mounted on /home/tommy for CSS authentication
So I moved that directory out of the way, and tried
4. mounting the NFS export using XBMC's own nfs support. http://paste.ubuntu.com/1462202/ This works again (although I was surprised to see it still attempting to read .Private, but at least this time it's happy to continue after the failure).
I'd suggest that cases two and three ought to "fail with success" in the same way that the fourth one does. But, to be honest, I don't understand why there's a functional difference between a "local" file and a remote one in the first place (assuming that there's no DVD decryption involved in any of them). There's certain a risk with .Private clashing (as it does in my case), with the encrypted date for eCryptfs, which now offered on installation of Ubuntu.
I have my DVDs ripped in VIDEO_TS format to a NAS box, which then exports them again, both via NFS and SMB.
I have the NFS mount actually mounted on my Linux box, but would prefer to use nfs:// as a path, in order to keep compatibility with my Windows machines (who can't see all the filenames cleanly over SMB, due to filename restrictions).
ETA: I'm using XBMC 12.0-RC2, on a Ubuntu 12.10 install.
Here are four (my, you are lucky!) different logs. In each case, I've started from a clean Movie Library, added the Video source, and the DVD of "Hugo" (the shortest filename I've got, in case that was part of the problem), and then attempted to play it. After each session, I cleared the source out again (but didn't bother to log that).
1. mounting the NFS export directly under Linux: http://paste.ubuntu.com/1462108/ This works.
2. mounting the NFS export using XBMC's own nfs internals. http://paste.ubuntu.com/1462140/ This fails.
3. mounting the SMB export using XBMC's on SMB internals. http://paste.ubuntu.com/1462145/ This also fails.
I did notice in those two failing logs (line 853 in the second log, line 870 in the third) that there's an extra notification:
INFO: msg: libdvdread: Attempting to use device /home/tommy/.Private mounted on /home/tommy for CSS authentication
So I moved that directory out of the way, and tried
4. mounting the NFS export using XBMC's own nfs support. http://paste.ubuntu.com/1462202/ This works again (although I was surprised to see it still attempting to read .Private, but at least this time it's happy to continue after the failure).
I'd suggest that cases two and three ought to "fail with success" in the same way that the fourth one does. But, to be honest, I don't understand why there's a functional difference between a "local" file and a remote one in the first place (assuming that there's no DVD decryption involved in any of them). There's certain a risk with .Private clashing (as it does in my case), with the encrypted date for eCryptfs, which now offered on installation of Ubuntu.