I'm not really a big fan of the pixelation during the FF and REW of libmpeg2.

_________________
Currently running: R5.5, HD5000 x 2, PVR150, Athlon 64 3000+, Chaintech VNF4, 1GB RAM, 2 x 250GB in LVM, MSI NX6200TC -> AA 9A60 -> HDTV

Why not just use 30-second skip? I virtually never use fast-forward or rewind as 30-sec skip forward is a lot faster (and of course, flagging and skipping commercial blocks is faster still).

Typical *nix- deleting a file does not delete it until every process has released the file. To get rid of a large file that is in use someplace, use:

(just the greater-than sign, then the file name from any prompt)
This will erase the data in the file, while leaving the file handles intact for running programs to continue to use. While the file size seen by "ls" does not always change, it becomes a "sparse file" which takes up very little physical disk space.

Once you've deleted a file in use, you loose track of the file handle from the prompt- only the running process with that file open knows how to access that file anymore. Typically a reboot is required to recover that disk space.

Zeph

I agree with you, but in my experience, XvMC isn't stable enough yet (I get freezes and stutters with it, as well as black&white OSDs), and the default mpeg2 decoder uses about 10-15% more CPU than libmpeg2. I'm waiting for XvMC to work better, and then I'll switch from libmpeg2.

_________________
KnoppMyth R5.5
MythiC Dragon v2.0
Join the KnoppMyth Frappr!

I find the standard decoder to be more more stable than libmpeg2. If I fast-forward a recording and then hit the play button to continue watching, it makes the video hiccup repeatedly. The only way to fix the problem is to stop the recording, go back to the main menu, and restart it.

The standard decoder does not cause this problem for me.

_________________
Currently running: R5.5, HD5000 x 2, PVR150, Athlon 64 3000+, Chaintech VNF4, 1GB RAM, 2 x 250GB in LVM, MSI NX6200TC -> AA 9A60 -> HDTV

I don't see those hiccups with libmpeg2, but with the standard decoder, I can't fast-forward for very long in HD content until it auto-pauses. It's not a freeze - I can start playback again and fast-forward from there, but it's kludgy to restart fast-forwarding. libmpeg2 has pixellated fast forward and reverse but doesn't pause on me like that.

Really, when XvMC doesn't freeze, it's the best (Much like "When my pants aren't on fire, they are comfortable." I suppose.)

_________________
KnoppMyth R5.5
MythiC Dragon v2.0
Join the KnoppMyth Frappr!

Hello all,

I have a very similar setup to ed3120. I have an Athlon 64 3200+ with 1 Gig of ram and a Nvidia 6150 based motherboard. It took me about 5 months to get a working system (long story bad WAF). However, I now have a working system with 1 little tiny glitch that I would like to fix.

I have all the same settings as ed3120 and am displaying to a 1080i HDTV set. My set cannot display 720p and I expect that would fix my problems but isn't an option.

When the scene pans horizontally, the image displays what I call tearing, that is an imaginary horizontal line separates the top and bottom at the line and the two sections do not pan together, but then catch up as the pan ends.

I have an HDTV tuner into the same TV and never see that when using it. Do others see this? Is there a way to make the playback look as good as a native HDTV tuner going to the TV set?

I have converted the recording partition to use the XFS filesystem, I have interlacing turned off. I have turned xVMC on/off, I have tried libmpeg2 vs default, etc. From what I understand this machine should have plenty of horsepower to play back 1080i butter smooth. I have also tried sticking in a 6200TC video card but it looks no different than the builtin video. I am using the 8xxx driver and that may be my problem.

However, I am loathe to stick in the 6200TC and then revert the driver to 7676 because the last time I did that I roached the system and my wife doesn't want me spending any time on the system and a full re-build would make me very sad.

By the way. I tried using a program to backup Myth, but it didn't work. Is there any program like Ghost that can be used so that I can always restore the system if I wreck it?

P.S. I would like to put in a quieter power supply in the box. However, I have a MicroATX case. Any recommendations?

Thanks,
Rick Wirch

Look in to Mondo backup- I have used it successfully on my Myth box.

Is it at least an option to test on a monitor that can do at least 1280x720 resolution? And if you have a monitor that does at least 1920x1080, you can test at full resolution, too.


It's similar enough to the Dragon specs that this should be true.


The 6200TC works with newer drivers, too - anything up to driver 1.0-8762 which is currently the latest. So you can try that, too. That also has a newer XvMC module, too, so you can try it out and see if there's any difference.

_________________
KnoppMyth R5.5
MythiC Dragon v2.0
Join the KnoppMyth Frappr!

Wirchrick, have you experimented with the 'sync to vblank' settings for xvideo in the nvidia-settings program yet?

To reduce tearing, you need three things

1) Sufficient CPU... my Athlon 3200+ can do 720p without XvMC, but just barely. XvMC helps a lot. Maybe a full 64-bit system would help, but that's going way beyond KnoppMyth.

2) Sync to vBlank; you need the 8762 nVidia drivers for this on a 6150 or 6200 board.

3) Real time threads. This is the tough one. You don't want to run mythtv as root and in any case, myth's real time threads are buggy enough to lock the system solid (I think it's actually QT mutexes which are the problem).

My solution was to install the 'ck' patches to the kernel for "soft real time" threads. -- http://kernel.kolivas.org. This allows non-root threads to run with real-time priority provided they don't eat more than 70% of the CPU. If they do that, they lose their priority temporarily. That solves the lock-up problem.

The reason you get problems without real-time threads is that the decoder and/or other processes can run for long periods of time (the Linux scheduling quantum is huge relative to a frame) in-between frames, and then the video output subsystem tries to catch up by not syncing anymore. With real-time threads, those other processes run only while the video output process is waiting for the vertical blanking interval.