Well, I thought I had it licked from this thread: http://mysettopbox.tv/phpBB2/viewtopic.php?t=14235&sid=32790bf8030583644acc8d86c888e5dd

... but apparently not.

I've added more memory (RDRAM, in case that's important) so now it's sporting a fancy 768 MB with the 1.2GHz P4. I would assume this would be able to handle a simple frontend/backend setup, but sure enough there's some glitches.

I realized the problem while trying to figure out why non-transcoded recordings play back fine, but transcoded recordings stutter. Apparently it wasn't a memory issue, but more of a CPU usage issue. When CPU load gets too high the stuttering starts (for example, while watching a non-transcoded show, there is no problems until the OSD comes up for volume changes, etc.). For watching transcoded shows I'm using XvMC, as the stutter isn't as bad as with ffmpeg or some of the others.

'top' shows only ~30% CPU usage while watching a transcoded show. Jumps to about 45% for watching LiveTV with a recorded show being transcoded in the background.

This effect bleeds over into LiveTV, though, so I'm not 100% sure that this is the cause.

Is there any way to fix this? I found a 1.8 GHz processor for the same machine for relatively cheap, but I don't want to spend the money if I don't have to. Does the graphics card (PCI GeForce FX5200) have anything to do with the decoding of transcoded episodes, or LiveTV?

I'm at work right now, but could post more info/specs later if it might help.

Any ideas?

Thanks!

_________________
- Anthony
- P4/1.8GHz, 768MB RAM, PVR-150, GeForce FX 5200

Have you added hard drive optimisations (optimizations if you're North American)?
On my machine it'll work ok without them, but is much smoother all round with them. Now, the link... ah here we go: http://www.knoppmythwiki.org/index.php?page=Optimize+Hard+Drive+Performance

_________________
Version:R8
Intel C2D 7400, Nvidia 5600 via HDMI to Samsung B37B650TW (PAL), Asus P5QL-E mobo, 4Gb PC6400 DDR2 ram, Samsung Spinpoint 500 Gb & 1Tb drive, Nova-HD-S2 (x2)

Tried, no luck.

Any possibility that it might be memory? I noticed in top (if you haven't figured it out, I just discovered how to use it, hehe) that nearly all of the memory is being used -- is this fairly common?

_________________
- Anthony
- P4/1.8GHz, 768MB RAM, PVR-150, GeForce FX 5200

I doubt it. 512MB is plenty for my FE/BE, and you've got even
more than that.

I hope so! You wouldn't want to spend hard-earned cash on RAM
and then have an OS not use it. I would guess that most of it
is being used to cache disk blocks. It's the number on the
right-hand side where it says "cached".

Here's what top shows on my Myth box:


That shows that 471MB is being used out of 479MB available
(available memory doesn't include RAM used by the kernel). Of
that 471MB, 325MB is being used as disk cache, and 2.6MB is
used for other buffers. That means that applications are using
about 143MB out of my 512MB.

As somebody else once said: "If you don't want Linux to use all
of your RAM, pull some of it out -- and send it to me."

_________________
Grant

Well, I have a 1.8 GHz processor in the mail. (At $23 with no shipping, I figured it wouldn't hurt.) We'll see if that fixes it, I suppose!

Thanks for the info on the memory -- love that quote!

_________________
- Anthony
- P4/1.8GHz, 768MB RAM, PVR-150, GeForce FX 5200

I've had the same problem from a couple of different areas.

First off, I have a lower end machine as well. Its a P700 running 256MB of RAM! It works pretty well, but I had to turn off a couple of things.

One thing that was causing stuttering audio was if I had commercial tagging going on in the background. Turning that off fixed one problem.

The other fix you might try is, since you have a Hauppage150 like I do, is turn the closed captioning off. That has been known to cause stuttering in the video and video. You can do that by going to the general page in Mythsetup. I think it's on page one or two.

Hope that helps!

--TheErk

EDIT: I just remembered...I had some issues with stuttering without the "delete files slowly" option checked which is also in General on Mythsetup if memory serves.

I'm at a total loss here ...

I just dropped in a new processor, so now it's a P4 running at 1.8 GHz with 768 megs of RAM. Can anyone at all think of why a transcoded recording would stutter on playback?

LiveTV works fine, and untranscoded recordings play fine. As soon as it transcodes it, I have get stuttering audio that renders the recording useless. (The file will play fine on my Windows box, which makes it even more frustrating.)

I can't seem to figure out which software is being used for playback -- mplayer? ivtv? If so, are there some sort of settings I can adjust?

I've tried every decoder (ffmpeg, XvMC, etc.) and they all react the same.
I can very easily disable transcoding, but it sort of defeats the purpose, I think.

Here's the more notable transcoding settings that might have some affect:

Bitrate: 2200
Max quality: 2
Min quality: 15
Max quality diff between frames: 3
Scale bitrate for frame size (on)

Audio codec: mp3
Sampling rate: 32000
MP3 quality: 7
Volume: 90

I think these were all default. Would changing something here make a big difference?

I really hope I'm missing something obvious!

Y'all are the best. Hopefully someone can come up with an idea!

Thanks!

_________________
- Anthony
- P4/1.8GHz, 768MB RAM, PVR-150, GeForce FX 5200

This wiki page contains a lot of excellent hints for reducing the latencies which cause this kind of problem. http://www.knoppmythwiki.org/index.php?page=PerformanceOptimizeHowTo

Anthony, I suspect it is a bug in the transcoding, but would try something like this: before and after, to see what differences there are.

Can mplayer or xine play the transcoded recordings without the stutter?

_________________
| Nigel Pearson, nigel.pearson.au@gmail.com
| "Things you own end up owning you" - Tyler, Fight Club

What format are you transcoding to? ie, are you doing a lossless mpeg2->mpeg2 transcode or are you transcoding mpeg2->mpeg4? Based on some of your posts in this thread, I suspect you are transcoding the mpeg4. If so, keep in mind that your source video is interlaced. While I don't use myth's trancoding procedures, I've used mencoder to transcode mpeg2 to xvid (mpeg4). I found that I got the best results by using the correct deinterlacing filter during the transcode proccess. I don't believe that mythtv allows one to do this, but there are options in the transcode setup screens that are meant to deal with interlacing issues. I would try playing with those to see if they help.

Marc

tjc --

I tried increasing the ivtv buffers (though I could not verify they were actually set in /var/log/kern.log) with no effect. I already have it set to delete files slowly -- do you think switching the filesystem might help? (And if so, do these instructions still apply with R5F27: http://www.knoppmythwiki.org/index.php?page=Filesystem+switch)

I'm not sure if anything else on that page would be helpful, as my errors constant, rather than occasional.

nigelpearson --

Here's the output from mplayer -identify (some random untranscoded show).mpg:
http://files.cipolone.org/mythtv/mplayeroutpre.txt

Here's the output from mplayer -identify (some random already transcoded show).nuv:
http://files.cipolone.org/mythtv/mplayeroutpost.txt.

Only difference as far as audio goes is in the bitrate -- pre is 384 kbit and post is 128 kbit. However, both times mplayer was stuttering on the audio. When I play an untranscoded recording in the MythTV front end, it plays just fine. Is MythTV using mplayer by default, or does it have its own built-in?

xine does not play the .nuv files at all (though it does make some awesome alien-like sounds that I'd like to sample!) with just xine (randomfile).nuv.

Any other suggestions?

Thanks for your help!

_________________
- Anthony
- P4/1.8GHz, 768MB RAM, PVR-150, GeForce FX 5200

The simple DB configuration changes make a big difference. A large number of the problems and fixes in the MythTV 0.20.x branches are related to DB latency issues.

Please check the size of the transcoded file (ls -l filename) and post the results. According to the mplayer output, you are transcoding to divx at a bitrate of 13.2 mbits/second. That would be a very high bitrate and would result in the trancoded file being larger than the original file, if this information is correct.

Marc

Let me ask a few more questions:

1. Why do you want to transcode your recordings from mpeg2 -> mpeg4? ie, what objective are you trying to achieve?

2. What are you watching the recordings on? A TV set or a computer display? Whichever you use, please provide some details. ie, screen size, resolution, etc.

I noticed that your source files are 480x480, 6 mbits/second. That is a very high bit rate and will result in large files. If your objective is to save disk space, as a first step I would simply modify your recording parameters to 720x480, 3300 kbits/second. This will cut the size of your files almost in half and still yield a result that I find acceptable on a 50" TV.

Marc

OK, to try to help you diagnose the problem I just used myth transcode on an episode of "Sex and the city". It player well both with the myth frotn end and using a windows version of mplayer. The size of the file was reduced from 830MB to 314MB. The bitrate reported by mplayer appears to be bogus -- no need to pursue that. This is the first time I've tried this on R5F27 -- on prior versions I did not see the good results I am seeing here.

Assuming you are on R5F27, a difference I see is that I am recording at 720x480, 3300 kbits/sec. and the transcode bitrate is 1300, not 2200. Perhaps switching form 480x480 to 720x480 and changing the bitrates to see what happens -- worth a try?

Marc