On Mon, Apr 16, 2012 at 05:10:35AM -0700, Fernando de Oliveira wrote: > Hi, Ken, I'm back. Forgive me if what follows looks silly, but you know I > still have much to learn. I can say one thing: I remember having exactly this > same problem, but much long ago, and did not solve it intentionally, upgrade > after upgrade made it disappear, or installed something, but repeating, it > was long ago >
We all get problems in the areas we aren't experienced with. Until someone is able to correctly determine what is actually causing hte problem, fixes come (and sometiems go) by magic as we change other things. That's why discussion is good. > Answering your question above, yes and no. > ;-) > You wrote (15-04-2012 20:08): > > > The disk is SATA, so using libata. All the googling I did in the > > past suggests DMA is always on with libata for SATA devices (but see > > below). > > and > > > I haven't found one. 'hdparm -t' reports > 112 MB/sec for the > > disk, so I think DMA is definitely in use. However, it only reports > > between 2 and 3 MB/sec for the DVD drive on /dev/sr0. BUT, that > > plays fine (with minimal cpu load) if I use vlc without the DVD > > menus, and similarly plays fine in xine. The wait for the buffer to > > fill was on the hard disk. > > With the iso image, these would be tested (whenever there is an equivalent) > in another hardware, so if the problem (probably) remains, you are 100% sure > it has to be some software problem. > I'm fairly sure it's not the hardware - this *isn't* the original "can't successfully play a DVD in vlc" problem (that is bypassed by opening without the menu), it's the related "vlc has atrocious performance playing a vob file from my hard disk" problem. The hard disk works fine, and the vob file is usable in other contexts, the problem seems to be vlc's buffering which is why with a bigger buffer it waits a longer time, then plays the length of the buffer, then slowly refills it. Looking at a VOB for one track, it's 55 MB for a playing time of 1min09, and it's on the drive that hdparm can read at 110MB/S. But buffering for 10 seconds (about 8MB of data, I suppose) using --file-caching=10000 takes in excess of 35 seconds to load each bufferful (longer for the first buffer). Conversely, if I try to turn off the buffer with a size of 0, I'm back to the default behaviour - it plays a second or two, waits several seconds, then plays another second or two. > Another thing I notice, in 15-04-2012 13:17, you wrote: > > > Note that I don't have lua, I configured it with > > --disable-lua --disable-libgcrypt --disable-remoteosd > > > > From memory, my first build was on a system that did have > > libgcrypt, so that switch is probably irrelevant. > > As you know, DVD's are encrypted, I have no idea, but shouldn't libgcrypt be > relevant? > Google thinks that libgcrypt is required for the RemoteOSD plugin. "RemoteOSD is a VNC client implemented as video-filter. It is intended to use VLC as streaming client for the streaming server VDR with ffnetdev streaming plugin and shows the OSD menu of the VDR." > I final thought: does vlc build its own ibdvdcss? I have this installed and > remember it is essential to reading DVD. > Most packages are reluctant to include copies of libdvdcss, so it is found at runtime. If I didn't have it, I wouldn't be able to play DVDs in any player. And the vob is decrypted. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
