Heads Up: XCard issue and its effect on SageTV

[DFA]

HI:

I just discovered this problem and thought I would share to save others the hard road. It's probably not new news and there may be info on the XCard forum, perhaps in the AVSForum and a few other places but I have not stumbled across it.

The short story:
If XCard is installed on your HTPC and your HTPC can go into a true S3 STR (suspend to ram) sleep state (HDD's off and fans off) you'll have a problem. When coming back from the S3 suspend state, Sage will be toast. The Sage menu will take many seconds to even appear and many more seconds to even navigate, the guide will take MINUTES to appear and AV will be an erratic slide slide show if you have the patience to wait for it to show. A look at TaskManage\Processes will show the "System" service consuming right at 100% CPU. Other apps will be doggy but nothing like what happens to Sage. Even the web browser manages to get enough CPU slice to be useable. But not Sage. The problem is that the XCard driver is not verified (signed) AND, sadly, does not conform to the ACPI spec.

I recall some posts about serious menu delays. Any driver (not just XCard) that does not conform to the ACPI spec can cause the 100% CPU thing after coming back from suspend and I imagine would give the same results as does XCard for Sage.

How I came to find this out is another story and longer one. Read on for the unabridged details.


The long story:
The last few days, I have been implementing some additional automation for my HTPC. One of the things I was working on was to get the HTPC to go to an S3 suspend state. It would only go to S1 STR although capable of S3. Doing some research, I found a utility called "dumppo" (I take a dumppo every morning but in this case this is an MS SDK utility meaning DumpPowerOptions). It is capable of displaying all of the mobo's power handling capabilities (<dumppo.exe cap>) as well as showing the "S" states that the mobo supports (<dumppo.exe ac>). It can also be used to force an S3 "MaxSleep" state if the mobo supports it (<dumppo.exe ac maxsleep=S3>).

After some messing around, I got the S3 "MaxSleep" state to "stick". At first it would revert back to S1 after a reboot and require me to put it back. Putting a dumppo shortcut (<dumppo.exe ac maxsleep=S3>) in a startup folder is an option if not being able to get it to stick.

But that was not to be the end. Although S3 was enabled, the machine was not actually going to the S3 state (HDD's and fans off). A recent thread here in the AVSForum and here tipped me off to the USB issue. I implemented the registery hack and there after my HTPC would go to a true S3 suspend state (HDD's and fans off).

After achieveing a true S3 suspend mode, that was when I found Sage very messed up. My knee jerk, shoot-from-the-hip thought was that Sage could not handle an S3 suspend state. After a little checking, I found that Sage was not responsible for the "System" service consuming 100% CPU; just the victim of it.

Doing some more research, I found that problems with resuming from an S3 state are most likely caused by un-verified and un-signed drivers. I found help here . The procedure for finding the culprit is to use "sigverif.exe". Using "sigverif" and applying it to only the drivers folder, I was quickly able to ferret out the un-signed drivers. The tedious part is finding the bad one since this is a process of elimination; what it is not in order to find what it is. Fortunately, I found the errant driver relatively soon. I first sorted through the un-signed drivers to determine what their purpose was and what hardware they were associated with, if any. I then prioritized the order I guessed most likely to be the bad guy. The XCard was not far down the list.

The XCard did indeed prove to be the problem. After disabling the Xcard in "Device Manager", I can go in and out of S3 suspend without any trouble and Sage behaves w/o issue.

Now, the XCard is not exactly main stream hardware but then again it is not some GNU, freeware / shareware startup thing either. This is a company that has been around for awhile and should / must do better than this. I don't necessarily care that Sigma or anyone else does not want to go through the MS verification hassle but at the end of the day, they need to at least write drivers that conform to the ACPI spec and WDM.

Sigma has not released any driver or player updates in almost a year. I am disappointed in Sigma and more than a little pissed for the time it cost me. I would think Sigma would take a little more pride in their product and supply better support.

Here we are hammering away for XCard OSD support in Sage but have a piece of hardware that can't properly support an S3 suspend mode.

I currently have left my XCard disabled in favor of using the S3 suspend state; at least for awhile. I think I'll send a nasty-gram to Sigma about this. Any other XCard owners might be so inclined to do as well.

Whew.

Regards,
Dane

[x[corwyn]]

I don't use the suspend state. I even remove it from my laptops. I find its a buggy at best and a lot of software doesn't react too well with it. I'll pick an xCards functionality over the "suspend" ability any day of the week. I honestly don't know what the point of using that feature is if its not on batteries.

[DFA]

ACPI works quite well when drivers are written to the standard. Sage 2.1 with built in "Wake" feature has also been doing very well. Having the ability to have the machine suspend to S3 will save some $$ on electricity when not running 24 / 7 and wear and tear. My HTPC w/ 3 fast HDD's, high performance video card, all slots populated and a full compliment of peripherals and USB devices I figure is consuming 250 - 300 wattts. My machine generates a LOT of heat. The wife also likes the dead quiet. Although I have slow fans turned down as low as is reasonalbe, with no audio going, the HTPC can be slightly heard. So if it can work w/o problem which I know it can and does, why not? No downside that I can see.

Right now, S3 suspend is working perfectly with the XCard driver disabled. I have the remote and Girder setup so that when the TV is turned on, the HTPC wakes up. When the TV is turned off, the HTPC goes to S3 and will wake as needed for recordings or any other events I schedule.

As far as XCard is concerned, I am working around Sigma's short comings by putting some Girder commands in place to automatically enable and disable the XCard driver whenever the XCard is to be used w/o any intervention on my part. I am not abandoning XCard, just annoyed that I had to troubleshoot it and then work around it due to Sigma's lack of intellectual investment. ACPI has been around long enough now that all mainstream and minor players should be on board. Past difficulties (also as a laptop user I'm fully aware of them) should be becoming a thing of the past.

I felt that others who have XCard and might be trying to use S3 suspend would want to know of what trouble is awaitng them and the source of it (at least one of them anyway).

DFA

[Opus4]

Originally Posted by DFA

As far as XCard is concerned, I am working around Sigma's short comings by putting some Girder commands in place to automatically enable and disable the XCard driver whenever the XCard is to be used w/o any intervention on my part.

Since my PC is in use & is recording often enough that I don't bother with suspending it, it might be helpful for anyone interested if you could provide info on what type of commands you use to enable/disable/reset the Xcard w/o rebooting. Thanks.

- Andy

[DFA]

Sure. When I have it sorted out and working correctly. I am yet debating wether to try and use Send/postmessage commands or write directly to the registry to do it. I have been educating myself on some Girder functions I have not yet used to move ahead. I will no doubt be posting a few questions on the Girder forum before it is over.

Fortunately, I have found that the XCard driver can simply be enabled / disabled w/o any reboot or any reinits.

EDIT: The USB-UIRT is great for waking from suspend. It will accept up to 4 different remote IR commands that it will store in its memory for waking the PC. I am using the same TV Off and On IR signals to suspend and resume the HTPC, respectively. It is transparent to my family.

DFA

[Opus4]

Originally Posted by DFA

EDIT: The USB-UIRT is great for waking from suspend. It will accept up to 4 different remote IR commands that it will store in its memory for waking the PC. I am using the TV On and Off IR signals to suspend and resume the HTPC. It is transparent to my family.

I know people have asked about being able to restart the PC with their remote. Would you post instructions for doing that in a new thread? Then, I can add a link to it in one of the index threads for others' future reference.

Edit: For these instructions, see: Wake PC with remote + USB-UIRT

- Andy

[DFA]

Update:

This thread is primarily about the XCard device driver not being able to handle a cylcle through an S3 suspend state and results in a high CPU consumption for the "System" service when resuming from suspend which trips up Sage something fierce.

However, I have also found that DScaler does not respond properly after an S3 suspend state as well. It does not cause any apparent problems to the rest of the system but is non-functional itself for PDI mode.

I have found that the XCard driver can be disabled prior to an S3 suspend and re-enabled after resuming from suspend and the XCard will function normally. However, if using the XCard in a PDI configuration which requires DScaler, DScaler is non-op.

I have not yet found a way to bring DScaler back w/o a reboot. The driver involved is "DSDrv4.sys". This info is cited for DScaler 4.1.10.

Note: I have been able to automate the disabling and re-enabling of the XCard device driver with a suspend and resume in Girder by use of the MS utility "devcon.exe" which is a command line device control manager having all the necessary "switches" to carry out all the same functions that can be done in the "Device Manager" GUI.

EDIT: Some research on the DScaler suspend / resume issue indicates the problem might have more to do with the capture card driver than DScaler itself. Currently, in my system, I have no drivers installed for the capture card since DScaler does not actually require any. On the other hand, DScaler is not responsible for ACPI handling of the card. Without any drivers installed, the capture card may not come back to the original boot-state after a suspend / resume event. Consequently, capture card drivers may be the solution. But not just any drivers: they need to be ACPI compliant drivers. There are only a few bt8x8 drivers that I am aware of that are ACPI compliant and BTWinCap being one. A lot of the OEM provided capture card drivers are not ACPI compliant.

I will try installing BTWincap drivers and see what happens from there and post results.

DFA