server sleep mode with Windows clients

[null_pointer_us]

SageTV 7.0.20 (RC4) Media Center and Clients

When the server sleeps, clients go into GCoL (Grey Circle of Limbo) and become unresponsive for a long time; they do not wake the server.

I forgot about one client and then found it still in GCoL several hours after the server had awakened and sleep was disabled.

In GCoL mode, the back, exit, and stop commands do nothing.

ALT+F4 kills the processes (after a while), but this is hardly a seamless solution.

In the network adapter's settings, Wake On LAN is checked along with magic packets and pattern matching.

I kinda expected this to work by v7. Do I have a configuration problem? Is it a quirk of this beta build?

The fact that the clients can go GCoL and require a task kill is extremely disappointing. Otherwise the new UI is really slick. It looks better, shows more useful information, and also performs sooooo much better.

[Narflex]

We haven't heard of this specific problem before. Can you please submit a bug report on it so we can get more details? It may be configuration related...but whatever it is, we'll figure it out. http://sagetv.com/bugs.html

[null_pointer_us]

I'm thinking the broken WoL may be W7/network-driver related, e.g. faulty driver turns port off during suspend.

I can't work on this right now due to it being the family video server and having scheduled recordings.


The GCoL problems look very much like bad UI programming.

1. Making the whole UI block on network timeouts is a design error. It's fine (and necessary) to make parts of the UI block on long timeouts, e.g. logically the client *can't* display the recording list if it has lost its connection to the server. Blocking the whole UI though is bad design.

2. Not providing a (working) way to cancel the network operation compounds the problem. Have you ever used a network app with a cancel button only to find out that the cancel button doesn't actually work? It happens when the thread that's supposed to process events for the cancel button is the one that's blocked on the network operation (which is, say, 30 seconds into its 60 second timeout). The correct way is to spawn a worker thread (for network operations) so that the UI thread can still respond to UI events that should kill the worker thread (and its connections) if needed.

3. Insufficient feedback increases user frustration. Whether due to a misbehaving recording device, missing network share, failing router, faulty CPU-hogging process, etc. SageTV has the same response. Most of the UI freezes, slows down, or just stops working while the GCoL runs and runs and runs and runs. But often there's no feedback on what's going wrong or whether the user should expect it to recover. I really like the recordings warning/error icons and viewer that were added in v6; when I had problems, it was nice to get some feedback instead of just wondering why something didn't record or the last five minutes are missing. Network-related stuff has no real feedback and no way to cancel: it's either stuck in GCoL or it's not; it either picks up on its own or you have to hit close/ALT+F4 (or use task manager).

For example, Windows Explorer's built-in graphical FTP client was horrendously bad. IIRC, if you made it do a long file transfer much of Windows would become unresponsive for the duration of the transfer; you couldn't cancel it -- Windows was just "stuck." I think the FTP client would even stop parts of Explorer windows from redrawing themselves, too. Dunno if they ever fixed it.

Best way to test SageTV's UI responsiveness/recovery under bad network conditions is to have one person use the client (mostly in the menus) and have someone pull the network cable out of the port at random times. How does the client app react? Is it responsive? Does it give some feedback as to why it's failing? Does it provide an easy way to cancel/close/restart the app or the operation? How quickly will it recover? If you plug in the cable, does it quickly start working again? Does it *ever* start working again?

I've used SageTV since v4 and it's common to find some SageTV clients still hung at "trying to reestablish the connection" hours after changing the network configuration. Maybe some of this is due to bad wireless drivers or a bad router, but network apps are supposed to be more fault tolerant. While it would be unreasonable to expect significant changes under the hood at RC4, maybe you could keep it in mind for 7.1/7.2 timeframe.

[gplasky]

All you need to do is use the "Back" button or command and Sage quits trying to connect and goes to the Main screen.

Gerry

[null_pointer_us]

That doesn't work for me. I'll quote myself:

In GCoL mode, the back, exit, and stop commands do nothing.

ALT+F4 kills the processes (after a while), but this is hardly a seamless solution.

Anyway, despite BIOS/driver updates and BIOS/Windows settings adjustments, the board (Biostar IP31-A7) still kills the power LED on the RTL8111C port during S3. There's no board jumper for WoL. I have exhausted all power-related settings that I can think of.

According to the BIOS, the board does support wakeup by PCI card and I have one slot free, so maybe I'll pick up a PCI ethernet card and try again.