SageTV Client issues

[Steerpike]

I'm running the SageTV client over a wireless (802.11g) network. I've been mainly using it to setup recordings, but recently I've been using the client to watch recorded shows.

I've noticed the playback is not at all smooth. It's not so much that frames are dropped, but rather, scrambled perhaps? It's as if some frames are getting ahead of others maybe.

Anyway, not wanting to blame Sage Client for this, I viewed the same recorded show using WinDVD, over the same network; playback is very smooth (both Sage and WinDVD get the occasional stutter due to wireless dropout, and I can accept that).

I'm using windows XP Pro, and have the task manager / Networking tab open, and can view network utilization; it hovers around 20%. If, by comparison, I copy a massive video file over the wireless network, utilization goes up to around 50%. CPU utilization is low, by the way (under 50%) in either case. Also, when copying massive files (4GBytes), I get a measured bitrate of about 20 Megabits per second, which is above the required data rate.

So basically, winDVD plays a given file much better than Sage Client. Is this a known issue, and can anything be done? One thought I had was, can the amount of data buffered by the client be increased? Since my overall throughput is adequate, could it be the Sage client is not buffering enough data to accomodate minor glitches?

Thanks!

[Mark SS]

I had similar problems until someone highlighted the following registry keys:

HKEY_LOCAL_MACHINE\Software\Frey Technologies\Common\DSFilters\MpegDeMux Buffersize & NumBuffers

Suggestion is to increase size of NumBuffers but I had best results with increasing both, worth experimenting though. Buffer size of 262144 and NumB uffers 256 works for me.

[Steerpike]

Thanks Mark - the key names suggest this should hit the spot!

My initial values for these elements are:
BufferSize = 65536 (10000 hex)
NumBuffers = 64 (40 hex)

I will experiment. What was your observation if you went 'too far' (increased beyond what you recommend above)? Did it just fail to get any better, or, actually degrade in some way?

Also - are you running wireless or wired? Even wired, with my default installation, playback leaves something to be desired in the smoothness department, compared to WinDVD.

OK - off to experiment now!

[GTwannabe]

I had some problems with smoothness with the SageTV client on my laptop when running on the battery. The problem was that my video chipset was clocking down to save battery power. When clocked down, it didn't have enough oomph to hardware accelerate MPEG playback.

Rather than increase the video clockspeed and decrease battery life, I switched the video decoder. I'm now using the Nvidia Video Post Processor on the laptop, which uses the CPU (clocks dynamically based on load) instead of the GPU (clock rate based on power source).

[Steerpike]

Originally Posted by GTwannabe

I had some problems with smoothness with the SageTV client on my laptop when running on the battery. The problem was that my video chipset was clocking down to save battery power. When clocked down, it didn't have enough oomph to hardware accelerate MPEG playback.

Rather than increase the video clockspeed and decrease battery life, I switched the video decoder. I'm now using the Nvidia Video Post Processor on the laptop, which uses the CPU (clocks dynamically based on load) instead of the GPU (clock rate based on power source).

Interesting! I was not aware that the GPU would switch speeds (I know all about the CPU clocking down) ... I'm using a Dell Latitude D600 (which has an ATI Radeon 9000 Mobility, and a Pentium M CPU). Anyway, I'm running on wall power, not battery, so I think that should not be my current issue. But good to know!

I have messed about with the 'NumBuffers' and 'BufferSize' figures to no avail. But based on your post, I decided to switch Video Decoders, and my problem seems to be solved! Smooth playback now!

I was using the 'Intervideo Video Decoder', but tried the only other alternative on my laptop client - 'SageTV MPEG Video Decoder'. That was the 'solution'.

This is actually not good for me, overall, because I need Closed Captions, and I have to use 'Intervideo' to get them to work. But at least I know what area my problem is in!

NOTE: the problem I see, when using InterVideo decoder, reminds me of the problems you get when you don't correctly set 'top field first' or 'bottom field first' when transcoding interlaced video - the image gets 'out of order'; for example, if a car is driving across the screen, it appears to be jumping back and forth! So this is not a buffering problem, but some other kind of problem, I believe. Is there a way to 'tune' the InterVideo Decoder to make it usable, so I can continue to use Closed Captions?

Also - versions. In researching this, I see many posts about different issues with different versions. What version do I have ? When I launch SageTV Client, it says 'Sage TV Client Version 4'. But the executable file 'properties' suggest a file version of 2.0.0.1, 'Product Version' 2.0, etc.
Is there a definitive 'about' screen that tells me what version I have, so I can correlate the various posts to my version?

here are some posts I found that refer to version-specific issues, for what it's worth:
http://forums.sagetv.com/forums/showthread.php?t=8480

http://forums.sagetv.com/forums/showthread.php?t=10164

[thatdude90210]

Don't worry about the "file version" number, I see the same thing here. You have the correct client -- if you had the wrong version of the client, it wouldn't be able to connect to SageTV 4 anyway.

From experience, I found that Cyberlink's Powerdvd decoder using overlay works best with ATI video cards/chips. It gives the smoothest playback with the least cpu usage. It might be available from one of their download/trial PowerDVD versions (when trial period is up, the decoder should still be usable).

[Steerpike]

Can anyone tell me what I might expect if I set either the numBuffers or BufferSize values too large? I'm running right now with BufferSize of 262144 and NumBuffers 256; It's working pretty good, with occasional stutter (very occasional). I'd like to increase these guys but would like to know what to look out for. I have a gig or RAM and a fast processor. Thanks!

[mantisgb]

That if you increase the buffer size and number of buffers it will simply take longer to show you live TV or start playback while it loads into the buffer.

You would need to know exactly how the client works but I guess generally the smaller the buffer the more responsive it will seem.

[Dekard]

Originally Posted by Steerpike

Can anyone tell me what I might expect if I set either the numBuffers or BufferSize values too large? I'm running right now with BufferSize of 262144 and NumBuffers 256; It's working pretty good, with occasional stutter (very occasional). I'd like to increase these guys but would like to know what to look out for. I have a gig or RAM and a fast processor. Thanks!

I like this question a lot. I'd tend to think you'll be ok with larger buffers, but there is no telling. Its a shame you have to use a wireless network though. I've got several and I've setup my fair share and I've just never found them to be stable and reliable. Not to say its not possible, just that in any given environment I prefer wired if at all possible. YMMV.

[lovingHDTV]

Originally Posted by Mark SS

I had similar problems until someone highlighted the following registry keys:

HKEY_LOCAL_MACHINE\Software\Frey Technologies\Common\DSFilters\MpegDeMux Buffersize & NumBuffers

Suggestion is to increase size of NumBuffers but I had best results with increasing both, worth experimenting though. Buffer size of 262144 and NumB uffers 256 works for me.

Anyone know if these setting affect the storage buffer size or just playback buffering?

thanks,

[Steerpike]

Originally Posted by Dekard

I like this question a lot. I'd tend to think you'll be ok with larger buffers, but there is no telling. Its a shame you have to use a wireless network though. I've got several and I've setup my fair share and I've just never found them to be stable and reliable. Not to say its not possible, just that in any given environment I prefer wired if at all possible. YMMV.

I'm stuck with wireless, I'm afraid - viewing room in question is a) 40' from the ground, b) has bedrooms below, c) vaulted ceilings above, d) hardwood floors ... and no ethernet outlet. Have considered ethernet-over-powerlines but not practical I don't believe.

I went out and bought the most elaborate wireless access point I could find - a linksys 802.11g with 'SRX 400' (has three antennas!). My Client has a corresponding PCI-card wireless network adapter, with a detached triple antenna (that is, antenna can be located anywhere, not tied to back of PC). The windows tray icon 'claims' (and I know this number is not something I should overly rely on, but it is a good 'relative' measure) 108 Mbps, and strength 'very good'.

I've been watching the 'network performance' tab of the task manager, and - to my surprise - the network utilization, while watching live TV in Sage, is a very steady 10% - and image stability great. But what happens is, about once every few minutes, the image will freeze then play 'catchup', or just freeze and resume, and in the network monitor I will see that there was a momentary drop in utilization then a spike up to about 25% utilization, then a return to stability. Of course, wireless can be affected by a million things, but I live in a relatively low-population area, with only one neighbor showing up as having a wap, and I've made sure my cordless phone is not competing, and I'm not running microwaves, etc, when these glitches occur.

So I'm not convinced the wireless network is the source of my glitches, at this point. I have not yet correlated the network utilization display to the 'glitches' - for all I know, utilization is dropping as a result of a Sage glitch, rather than sage being impacted due to a network issue. I'll try to observe this area some more.

Reading other posts on this topic, I"ve ensured I'm running the latest java run time (1.5) on both client and server.

The client is a brand new AMD 3000+, the server is an older P4 1.6 GHz.

Anyway, I'm willing to crank up the buffer parameters indefinitely, as I don't care about 'responsiveness' at this point, but just wondered if at some point there are 'other issues' that may creep in that I should be aware of. As an ex-programmer, I know you can't just keep grabbing resources without eventually running into other constraints and issues.

Sitting here now, testing this as I type, I've gone at least 20 minutes without even a hint of a glitch ...!

[lovingHDTV]

Do you use any third party drivers to manage your wireless connections or do you only use XP? I know that on my work laptop I had to disable the XP from trying to control my wireless connections. Periodically it would try to control the connection and mess up my Cisco Aironet app. I would notice this happening because my VPN connection would drop. After disabling XP everything works fine.

[Dekard]

Why do you feel that ethernet over power line would be the wrong choice? Technically Sage can stream as low as 5 mbs, so if you could get 10+ you should be cool..

[GTwannabe]

Originally Posted by Dekard

Why do you feel that ethernet over power line would be the wrong choice? Technically Sage can stream as low as 5 mbs, so if you could get 10+ you should be cool..

Ethernet over powerline is pathetically slow (nowhere near rated speed) and unreliable.

If you're having trouble with wireless, I suggest the following:

1. If possible, try to make a straight shot from the access point to the client. Avoid water pipes, metal objects, metal siding/mesh, etc between the devices.

2. Determine the optimal channel for your wireless LAN. 802.11B and G only have 3 non-overlapping channles: 1, 6, and 11. Ideally, you want to use one of those. Download a copy of NetStumbler and view the wireless networks in your neighborhood. You want to be at least 5 channels away from your neighbors' LANs. Most access points default to channel 6, so 1 and 11 should be free. 1 will have the best range, 11 will be a little shorter.

3. Avoid things like microwaves, 2.4ghz cordless phones, etc.

4. XP SP2's wireless manager periodically disconnects and scans the other channels for access points. This can cause hiccups. Using a 3rd party wireless manager instead of the XP Wireless Zero Config service can fix this.

5. The antennae on PCMCIA wireless cards are less than ideal due to space limitations. If your laptop has a MiniPCI slot and internal antenna(e), you should use them instead of PCMCIA.

[Dekard]

Originally Posted by GTwannabe

Ethernet over powerline is pathetically slow (nowhere near rated speed) and unreliable.

If you're having trouble with wireless, I suggest the following:

1. If possible, try to make a straight shot from the access point to the client. Avoid water pipes, metal objects, metal siding/mesh, etc between the devices.

2. Determine the optimal channel for your wireless LAN. 802.11B and G only have 3 non-overlapping channles: 1, 6, and 11. Ideally, you want to use one of those. Download a copy of NetStumbler and view the wireless networks in your neighborhood. You want to be at least 5 channels away from your neighbors' LANs. Most access points default to channel 6, so 1 and 11 should be free. 1 will have the best range, 11 will be a little shorter.

3. Avoid things like microwaves, 2.4ghz cordless phones, etc.

4. XP SP2's wireless manager periodically disconnects and scans the other channels for access points. This can cause hiccups. Using a 3rd party wireless manager instead of the XP Wireless Zero Config service can fix this.

5. The antennae on PCMCIA wireless cards are less than ideal due to space limitations. If your laptop has a MiniPCI slot and internal antenna(e), you should use them instead of PCMCIA.

Not bad.

[rfutscher]

I had a problem where every 20 minutes or so my client would pause for up to a minute then resume. gradually falling further and further behind real time. I have a wired 1Gb network connection. The problem went away with the latest beta (.12).

[salsbst]

Bump (for those wondering why Sage is stuttering after a really clean install during upgrade to v6).

I still have more stuttering than under v5, but it seems like that's mostly because the CPU is heating up. The major HDTV stuttering that I was having after wiping SageTV install clean is gone now. I used Buffer size of 262144 and NumBuffers 256, as Mark SS found to be good. Big improvement.

[AngelofDeth]

Originally Posted by Steerpike

So I'm not convinced the wireless network is the source of my glitches, at this point. I have not yet correlated the network utilization display to the 'glitches' - for all I know, utilization is dropping as a result of a Sage glitch, rather than sage being impacted due to a network issue. I'll try to observe this area some more.

You should probably probably check that your linksys isn't dropping an inordinate amount of packets when you see these "glitches". Perhaps its dropping packets for a small amount of time, and increasing the buffer is just hiding the problem. Linksys routers are known for crapping out. I have a WRT54G, which works fine, but the first one I got worked reliably for a few days.

[salsbst]

AngelOfDeth, you replied to a post from April, so if you don't get a response, don't be shocked.

I just want to say that NumBuffers was not a panacea. I still have major stuttering on HDTV recorded from firewire. SDTV recorded from firewire usually either kills the Sage process or makes it hang on a black screen. This wasn't a problem under v5 -- I think the demux is a little freaky in 6.0.15.

[AngelofDeth]

Originally Posted by salsbst

AngelOfDeth, you replied to a post from April, so if you don't get a response, don't be shocked.

I hate it when I do that, I usually check the dates so as not to do something so stupid.