Hopefully someone will be able to shed some light on my problem. I am having trouble with choppy video playback (video and sound pauses about once every second). I know there are many threads posted in this forum on this topic, but have not found a solution that works for me. Hopefully someone who understands this a bit better might be of some help.

Setup:
R5F27
Celeron 1000MHz
256 RAM
S1854 Trinity 400 Motherboard (VIA Apollo Pro 133 Chipset)
Asus V6600 Video Card using tvout (Nvidia Geforce 256)
PVR-150 mce
Seagate 500 GB IDE drive
Trendnet TEW-42UB wifi USB network dongle (using ndiswrapper)

I forced the install of the 7185 Nvidia drivers. I have set my capture resolution to 720x480, turned VBI off, and turned deinterlacing off. My video resolution is set to 640x480 (also tried others). Delete files slowly is enabled. I tried moving the card to another slot and the bios tweaks for the pvr-150 (on the hauppauge site)

At first I chalked this one up to the VIA chipset DMA error thing (and/or old hardware). But the weird thing is playback is fine with the same video file using mplayer. Also playback with internal player works when I do not install the USB network dongle(even live tv works at a lower bitrate). Is ndiswrapper just eating up too much of my resources? And why only with the internal player. I have not tried another network card as of yet.

I looked through some log files, but I really don't know what I am doing. Is there certain ones I should look through for networking errors, or conflicts?

Is this a box that ran fine before and is now getting choppy? or is it a newly configured box?

From the PVR-150 I presume you're doing only SD... Is any thing else running on this box? The specs look maybe a tad low-end, but within reason for a 1-tuner KM system. Maybe it needs more RAM???

Sorry I'm not more helpful...

Also look at the alternate MPEG decoders. Some folks have reported that making a significant difference.

Thanks for the quick responses



It is newly configured,SD, with nothing else running.



none seem to yield better results. Also tried almost every combination of options I could think of.

Thanks for all the suggestions I will keep plugging away and keep you posted

Oh wait, I missed the bit about the USB dongle before...

USB is evil. It's cheap and terribly convenient, but you pay the cost in CPU time and interrupt handling. If you compare the CPU usage and the like between normal internal drives and USB storage, or normal NICs and USB connectors using top you'll be shocked at how expensive it is. Add something like the NDIS wrapper layer which has to run alien drivers in a cocoon and a system which would normally be fine for SD usage can suddenly have trouble. There are two parts to the problem, first USB causes _lots_ of interrupts - that's just the nature of the beast and there's not much way around it, second the wrapped alien drivers increase the overhead for handling each of those interrupts - here a faster machine can hide some of that but... Actually make that 3 parts, the final piece is that video recording and playback is essentially a real-time business, if it doesn't get the CPU slice it needs when it needs it, you'll see a glitch.

Try ssh-ing into the machine and running top while you're trying to watch something. That should give you a feeling for how bad the problem is. Also check the log files to see if you're getting FE or BE errors about buffer overflows and things not reading fast enough. http://www.knoppmythwiki.org/index.php?page=CheckingLogFiles

You may be able to get some relief by allowing MythTV to run with root privileges so that it can request RT priority and/or increasing the buffer sizes used.

For troubleshooting I would test with more memory to see if that
helped.

Between R5C7 and R5E1 I had a pentium 433 with a PVR-350 that ran
ok with 256 meg of ram. But note that it did not have to do any
encoding or decoding with the CPU.

You might try doing your commercial flagging later rather than
at the same time as it is recording.

Does it record ok as long as you are not watching at the same time?

Does it play back ok as long as you are not recording at the same time?

-- wifi digression follows --

You can probably ignore the rest of this if all you ever want to do with
the wifi is download the program guide.

I see too that you are running wifi. If you intend to run other
front ends over the wifi be aware that it is a limiting factor too.
Plan on only one carefully tweaked front end at a time being
usable over 802.11g wifi (forget about trying 802.11b)

I have 2 laptops (2 separate households) running wifi on Ubuntu Gutsy.

They work most of the time, but sometimes get choppy.

I have tested network throughput at various times and even though
I know that these wifi setups will pump a consistent 2 megabytes per
second and myth is asking for a little less then that, it is the wifi
that is the issue.

If Mythtv would just buffer the stream a little more it would always
work smoothly. I have proven this by switching it to a wired LAN and
the problem never happens although the throughput never goes over
2 megabytes per second on the wired LAN either.

Cliff

_________________
R5F27 using R5F1 Nvidia drivers
HD-5500 analog from NTSC Sat Rx, with OTA DVB too
GeForce MX-440 SVideo tvout to a TV
Older dual core 3.4ghz Intel CPU
Asus P5PE-VM Motherboard
2 GB RAM
1 TB LVM2
VirtualBox
Samba

The key is that average bandwidth, peak bandwidth and latency requirements are three different things and only loosely related.

recording works fine. Playback alone with no recording taking place is choppy. However playback with mplayer works fine.


all I want to do is dowload the guide. I have no plans for a seperate front end at this time


Update:
I temporarily installed a pci wired network card and my problems go away. I guess my next step may be to find a cheap pci wifi card that works with Knoppmyth.

I have been really busy with work but I finally had time to look at this again



I finally gave this a go, and it seems to help with playback. Livetv is still a bit choppy, but better. I used the following code



Is there a better way of doing this.

Indeed. My point is that the wifi will sustain 2 mbytes/sec and this
configuration of mythtv only needs 1 mbyte/sec, so all that would need
to be done to convert a failing latency issue into a passing average
bandwidth issue is to increase the frontend buffer size to the point that any
seeking around is done in the local buffer.

This makes two reasonable sounding assumptions that I can think of:
- any seeking that must be done (I can't say without looking
at the source that it even does any seeking at all) does not constantly
jump around huge distances as this would require the buffer to be huge.
- the actual problem is not something as basic as the network protocol
being so inefficient that it will never work (something like hard coded
32 byte packets with individual acknowledgements)

Cliff

_________________
R5F27 using R5F1 Nvidia drivers
HD-5500 analog from NTSC Sat Rx, with OTA DVB too
GeForce MX-440 SVideo tvout to a TV
Older dual core 3.4ghz Intel CPU
Asus P5PE-VM Motherboard
2 GB RAM
1 TB LVM2
VirtualBox
Samba

Well a "sustained rate" of 2Mb/sec is a long term average after all. If you live in a densely packed and/or electronically noisy area that could be papering over some very substantial gaps and buffering will only cover so much. You can certainly try bumping the buffers way up, but at some point you'll run out of RAM for other things. <shrug>

BTW - I've actually had similar issues in the past with a bad networking cable. The average rates were fine, but periodically there would be these drop outs, and both ends would have to get their act back together and renegotiate and reestablish the link resulting in network stalls. Replacing the cable fixed the stall problem. Replacing the badly crimped connector (custom made cables) fixed the cable. The problem with WiFi is that your "cable" is ALWAYS at least a little bit flaky.