Howdy all. I've been away from linux for awhile (yeah, boo for me) and got back into it lately but I'm having an absolutely heinous problem that's keeping me from wiping windows until I can solve it.

I'm running Gentoo and I'm using stable packages. I have kernel 2.6.23 with userspace vesa framebuffer support compiled into the kernel. I'm booting in a 1440x900 framebuffer and life is grand.

If I play a video with mplayer and only set the -vo fbdev and no other options (original size in top left corner of screen in), everything is fine. If I play fullscreen (using mplayer -vo fbdev -fs -zoom -x 1440 -y 900 Movie.avi) it will work fine, the first time. With some movies, it plays fine from then on out. With others, I can watch a movie once, and everytime after that it freezes. Now I don't mean kinda freezes, I mean hard lock. It goes zombie, PPID is init, and it can't be killed. I have to switch to another tty and get on with life. But until I reboot, I can't play that video again.

I dunno if that's clear. I'm not sure it is. Let's say I have 2 videos. Video1.avi, Video2.avi. I boot up my box and log in. Now I play Video1.avi in fullscreen, and it works fine. Then I watch it again, no problem. 3rd time, works like a charm. I could watch this video all day. Then I play Video2 in fullscreen, and it works fine. Try to watch it again, and mplayer locks up HARD. Go to a different tty and log in, try to watch Video1, and mplayer locks up hard again. once it locks up hard, it won't play a movie again.

I would look for inconsistencies with these video files, but they are all encoded by the same person on the same hardware using the same software and settings. I've put them on different media (originally on external USB HDD, tested by copying the files to internal HDD). The external drive is NTFS, the internal was FAT32. Both work fine in Windows using Media Player.

Here's where it gets strange. If I try to copy the files using Linux, the cp command goes zombie. :S Again, works fine in windows, and this is copying from the uncompressed, unencrypted NTFS partition to a FAT32 partition, file size is under 800MB. So I thought something wrong with the file. But again, I can copy it fine with Windows. I ran scandisk on the drives, no errors.

So I went to the mplayer website and read about submitting bug reports. They said submit the first 5MB of the file since most problems can be diagnosed there. So I made a test. I ran dd if=Video1.avi of=~/smallfile bs=1024k count=5 and then played smallfile. Worked fine. Play it again, worked fine. It runs perfectly. So I tried a larger file: dd if=Video1.avi of=~/smallfile bs=1024k count=10 and then with count=200 and with count=400 and then with count=600, and it worked fine every time. I can dd it, play the new file 20 times if I want to, and mplayer doesn't freeze.

But, if I try to dd the whole file, dd goes zombie. Whether I use the external HDD (NTFS) or the internal HDD (Fat32) I moved it to. I literally have no idea what's going on. Do I have like....80% of files are bad files but play and can be copied fine in Windows or is it not a file problem? If not a file problem, why just these files? How can I test the files to see if they are ok? And most importantly, how can I get mplayer to quit locking up on me?

A man can't by if he can't watch his movies. And right now Linux isn't letting me watch my movies. :-(

Please tell me someone here can help me out. I REALLY want to take Vista and XP off my machine and not hate my computer anymore.

May be there is some problem with NTFS driver? (Your file is on NTFS partition, right?) May be the read operation gets stuck after continuously reading the file? Try dd-ing the file with different sizes and see if there is some file-size barrier. (It is also possible that it is random...)

I know that when I/O error occurs, no error is shown at terminal (I know this because I have my Gentoo installed on a USB hard-disk, and when I accidentally unplug it, the whole system still works, but mplayer, or cd, or cp, basically anything I/O related gets hanged).