Right - it's because it's just playing the .VOB files (02_08 as the first one apparently). This is not going to play the whole movie properly anyway (and if it is, it's luck).
The problem, therefore, is a bad libdvdread/nav. Have you tried something other than NFS, to rule out some weirdness there?
Per the original thread [
http://forum.xbmc.org/showthread.php?tid...pid1176369], yes, I tried SMB, and it did not work. That is when I discovered that going through Video --> Files did work. That said, I have not tried it with the latest monthly, so I will give it a go too and post a log.
OK, so I replaced my one of my NFS sources with its SMB equivalent. First, in library mode (Movies) I played an ISO (Cool Runnings) just to make sure it worked (it did). Then, I tried to play Crimson Tide.dvdmedia. Nothing happened, like with NFS.
Pastebin:
http://pastebin.com/qz0mfujc
Looking in my own logs, without user:password filtering, and comparing it to what's been posted in this thread, it looks like libdvdread is not using the authentication tokens and failing to gain access to the remote share. Is this a display error, or is this possibly where the VIDEO_TS support is broken?
nfs doesn't need user:password authentication ... thats not the issue then i guess - but something else wonky in libdvdread in conjunction with our vfs.
Well, in my case, it's all smb access for remote content. And, there are perfectly good files that are getting "no such file" errors. Is it possible that filename checking (only in library mode) was changed in a way to make it over-sensitive to non-alphanumeric characters? For example, I have "Contact.(1997).avi" in my movie collection. Library mode claims the file no longer exists, but files mode plays it fine.
Now, I have been using nightly builds of OSX x86_64 (I'm on Lion, 10.7.5, if that makes any difference), so I don't know if this is a known problem or not. If an additional log post is desired, let me know and I'll do what I can.
Additional thought on the "no such file" errors. Is it possible that the error is in the library scanning? Recently, one of the nightly builds needed to convert or rebuild my library. Even with manually updating the library, there are entire sections that seem to be skipped/ignored. The media sources all work in files mode, but I don't know that library mode is reading the source definitions correctly.
Just tried the first Frodo beta. Still no joy. I'm going to try Eden on one of my Macs, just to see if I was dreaming that this was not an issue on that version.
Eden worked fine for VIDEO_TS.IFO processing. I used to watch many such DVD rips (of my own DVDs) until I upgraded my audio system. Why listen to stereo only when toslink 5.1 hardware is available? Thus, when Eden had the audio issues preventing good sound, I started using Frodo nightly builds. Initially, VIDEO_TS.IFO was working on Frodo, then development continued which broke it.
As it turned out, the .ISO and filename issues I was experiencing was caused by an improper conversion of my library. After killing what I had and recreating it from scratch, those problems vanished, but the VIDEO_TS.IFO issue continues. I swear, it's like any attempt to play a DVD-like structure is assumed to be a unique device/file, thus fails when trying to open the VIDEO_TS directory.
I installed Eden this morning, on one of the same computers that was having problems playing .dvdmedia "files" with Frodo, and it worked flawlessly with NFS. So:
1. I was not dreaming (yea!)
2. Something has changed in this area from Eden to Frodo
That said, I seem to recall that this was not always the case with Frodo, so I am going to try some of the earlier monthlies, to see if I can figure out where the change occurred.
OK, so I started with Frodo Alpha 3; no joy.
Went to Frodo Alpha 1, .dvdmedia playback worked!
Went to Frodo Alpha 2, .dvdmedia did NOT work.
So, something was changed between Alpha 1 and Alpha 2 that broke .dvdmedia playback.
Ok i have tracked the offending commit down. Its when we switched from osx 10.4sdk to osx 10.6 sdk. The real cause is hard to find cause we do some really dirty things for getting libdvdread to access files via our own vfs handlers. In the worst case (if nobody finds the time for tracking it down and fixing it) this will result in a regression for frodo.
Thanks for tracking it down! Does this mean that perhaps this might be working again--either if someone find the fix, or if it is regressed--in the next beta? Not sure how, entirely, the development cycle works for XBMC, so perhaps this is asking too much.
In any regard, I think I might go back to alpha 1 until this is fixed.
Mhh lucky 180 degree turn. Will be fixed in next nightly...