|
SageTV Beta Test Software Discussion related to BETA Releases of the SageTV application produced by SageTV. Questions, issues, problems, suggestions, etc. regarding SageTV Beta Releases should be posted here. |
|
Thread Tools | Search this Thread | Display Modes |
#1
|
|||
|
|||
Client problem: Lockups when seeking
Occasionally when seeking the client hangs, consuming 100% CPU. I have to kill it from the task manager. Has anyone else run into this?
|
#2
|
|||
|
|||
Yes, I've been experiencing this (2.0.15 and 2.0.16RC1). It seems to happen most when I press the channel up/down button fast a number of times.
Andy. |
#3
|
|||
|
|||
Hi,
I believe it is a video driver issue. I am using the client two computers. Computer #1 has an NVidia video card and does not have the lockup issue. Computer #2 is using the newest version of ATI's catalist software for the AIW 7500 video card. When I get the lockups, sometimes when changing channels too quickly and mostly when moving the mouse wheel by accient, I will get lockup issues. I will also get errors stating it can not start the graph or I will get long term lockups but it will eventually come around if I wait long enough. Once I see this, I notice I am using the CyberLink Encoder with the ATI Video card is when I have the most problems. The other PC is using the CyberLink Encoder with the NVidia video card without issues.. Works flawlessly, wife is very pleased.. (Trust me, if there was an issue, I would *HEAR* about it). UPDATE: I am seeing pausing for the client when I scan, sometimes it is 45 seconds or more.. a real pain for sure. I get 0 CPU usage and 0 network usage. Sage does not stop responding but video stops. Confirmed it is not a network issue. After scanning though many videos using F5 and F6 and getting several "pauses" that amount to 30-45 seconds each, I have decided to go back to 2.0.15 and be one of the several to report the issue. I will also test further and see if it is a server or client issue. UPDATE: I downgraded the server to 2.0.15Beta and the pausing /lockup issue on the client is gone. Seems like something was done to break the server on 2.0.16RC1. Tested the 2.0.16RC1 Server with 2.0.15Beta Client and the issue still existed as reported earlier. Tested 2.0.15Beta Server with 2.0.16RC1 Client and had no issues when skipping through the video using F5 or F6 keys. Regards, Mark Last edited by mandrews44; 04-17-2004 at 02:32 AM. |
#4
|
|||
|
|||
Hi Mark,
I wonder if we're seeing different kinds of problems. When it locks up for me, it's hard--100% CPU with no response to mouse clicks and keyboard. I too am using an ATI card. I thought maybe there was a race condition in the code, so that seeking would cause latencies over the network that would reveal the race. For example, my main computer is saving some files on my client computer. Instead of the client reading those files directly from the local disk, I'm guessing that it's going to the main computer for the file, which is reading it back over the network from the client computer. |
#5
|
||||
|
||||
What decoder are you all using? I can duplicate this on command myself with the Cyberlink decoder.
|
#6
|
|||
|
|||
I'm seeing the same behaviour as coppit. I'm using an Diamond Viper V550 (nVidia Riva TNT chipset) graphics card.
I also just had an issue where I tried to change the channel using the down button on the OSD and the application first froze, then exited. This release just doesn't seem as stable as 2.0.15..... Andy. |
#7
|
|||
|
|||
I'm using the default decoder... Anyone know how to check which one this is? (System information doesn't say...)
For what it's worth, I've seen this behavior for the last 3 or 4 versions of SageTV version 2. I haven't used 1.4. I seem to remember it being a lot worse about 3 versions ago (i.e. every seek caused it to hang). It seems better now, but still not reliable. |
#8
|
|||
|
|||
Hi Coppit,
The issue is definately on the server, not the client. One possibility of what could be happening is the server and client miss a hand shake and both are waiting for each other. 30 seconds later after timeout another handshake is sent and everything works again. I notice eventually the client will be hang with 100% CPU usage and require a forced shutdown. That could be caused by a ripple effect from buffers not being released due to things are not working as expected. (All a guess). You could be having a different issue but I am seeing the same semptoms with 2.0.16RC1. Regards, Mark |
#9
|
|||
|
|||
Okay, it's definitely a network issue. I've installed Sage RC2 and Client RC2 on the same machine, and set the server to 127.0.0.1. The client *doesn't* hang when running locally. I'm guessing some buffer or something isn't being handled right when you seek too much in the client when it's running over the network.
I'll file a bug report. (again?) |
#10
|
|||
|
|||
With client and server at .17/RC2, the client dies when I quckly change channels.
On the client I'm using PVR-350 TV-Out only, so I don't think it's a video driver problem. I've gone to .15 on the server while keeping .17 on the client and SageTV is usable again. -Matt |
#11
|
||||
|
||||
Try some different decoders too. Some handle it better. I have yet to get Elecard to bomb out. It also could have something to do with DXVA since Elecard does not support it.
|
#12
|
|||
|
|||
I was having this problem with the new 2.0.17 beta on the client, which had an ATI card. I swapped out my ATI card with a nvidia 5200 ultra, and the problems have gone away (at least for right now. I have more testing to do). I hope this helps.
-Ralnee |
#13
|
|||
|
|||
Thanks mlbdude. The intervideo decoders are the problem. I switched to Cyberlink and it worked, but put the display in a separate window. Then I disabled hardware acceleration and now I get one display with OSD and no hanging.
Maybe the FAQ or tips section of the website could have a list of known good configurations? |
#14
|
||||
|
||||
Cyberlink don't support VMR9 so your choices are Overlay (you get Overlay by selecting it or by selecting VMR9 and disabling 3D).
Try Overlay with 3D on sometime too. That could work. |
#15
|
|||
|
|||
Yeah I think my client did this as well but I was having a hard enough time just trying to get it going over wireless g, stutter, stutter, playback, stutter, playback, stutter, stutter
|
#16
|
|||
|
|||
Quote:
|
#17
|
|||
|
|||
Yes, worked fine the couple of times I tried it.
In fact, even worked fine for me when using multiple 11g clients at the same time. Jason Does 802.11g have enough bandwidth for video? [/QUOTE] |
#18
|
||||
|
||||
It should, but may not depending on the link condition, FWIW, the max recording bitrate is 12Mbps at the 5.6GB/hr setting, with 6-8Mbps being the bitrate for the 2-3GB/hr settings. Generally, don't expect more than slightly less than half the rated bandwidth on wireless (ie about 20Mbps on 11g)
|
#19
|
|||
|
|||
Quote:
Please see my post at http://forums.freytechnologies.com/f...&threadid=4893 Please do report this as a bug, I was the first to report it and until others see the issue, the issue isn't real yet. From my testing, the client will not hang when ran locally or over a wired network. The issue comes in when you introduce latency in the wireless network. (Packets take slightly longer to get over the wireless network than wired). That ever so small delay, usually less than 1ms, is what is causing my problem. What is also hendering finding the solution is there are that have similar simptons but are not the same as in this thread. Personally, I wrote a low bandwidth streaming application and tried to get it to work over a cellular Network. What sucked about that is while the packets are guarenteed delivery in the TCP/IP protocol, they are not guarenteed to be in order or have the same delay between packet sends. It is really easy to have reinterant issues and out of sequence packets. What fun that was. Regards, Mark Last edited by mandrews44; 04-25-2004 at 01:09 PM. |
#20
|
|||
|
|||
Quote:
but I could sit with the notebook in my arms in front of the router and I would get stuttering Am I really to believe this is a SageTV problem If that is the case, is there any way to make local media play on a client? I could simply manually take the files over the network myself(not stream) Should I just bug this? I know this much as soon as I go to the other side of my apartment the video I cannot even start and yet when in my living room the client will stutter yet continue to play |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
|
|