Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[InflatableMouse]

My HTPC has auto login enabled with MC18 starting automatically in Theater View mode. Its running under its own unique user account.

I am running Windows 7 64-bit with the Terminal Server patch to allow multiple user sessions. I login to my HTPC from my own workstation using RDP, using my own user account. Via the Task Manager, Users Tab, I see both my own and the console session, I right click the console session and choose Connect. It asks for the password from the user account the console session is running under.

Often this works fine but sometimes, I get a black screen with white text in the middle saying "Error drawing using Direct3D (device lost)". The console session is running in 1920x1080 while the RDP session is set to 1680x1050. When I connect to the console session it obviously has Theater View open and it needs to resize the desktop. When it works correctly it quickly blinks and resizes and Theater View shows correctly. I tested it connecting on the native resolution too so it doesn't have to resize, but this makes no difference, it still gives the error sometimes.

At that point I cannot get out of it, except via the taskbar Media Center Icon, right click it and choosing Close Window. This should close Theater View and pops back to Standard View. It does this and shows standard view, but also crashes Media Center (Media Center has stopped working popup with close program button).

The same happens sometimes when I have succesfully connected via RDP and closed the Window (leave session running) and logg back in on the HTPC itself (TV will show logged in User sessions and entering the password will pull the session back to the TV screen).

I never did this with MC17 so I don't know whether that worked or not. At one point during the different MC18 betas (notably the .55 one) I felt it had improved (I actually can't remember it crashed). The first thing that happened after updating to .58 it crashed again. This is just a feeling though, could be coincidence but I wanted to mention it nonetheless. I'm not sure if I can roll back to .55, I could test that some more if that is useful.

I realize this is a very unique situation and I'm probably the only one doing this. It is however the only way to perform Media Center tasks remotely, stuff that can only be done on the server itself and not through a client, short of actually using the mouse/keyboard/TV on the HTPC directly. I have other people in this house using the TV or playing radio or Xbox, and having to interrupt that to work in front of the TV is only acceptable a few times a month; their annoyance levels visibly changes on their faces each time I do that, to the point where they will actively rebel against my interruptions .

I decided to report it because it is intermittend and sometimes actually works several times in a row, going back and forth between the TV and RDP sessions. And because it is the only way I can think of to do do remote management on MC. Last but not least, the crashes can't be good for the database and/or other files MC has open during the crash. I'm worried that eventually it will corrupt something.

If you're willing to look into this, it is reproducable (for me at least) so I can create log files.

Thanks.

[gvanbrunt]

Why not just use VNC and connect directly to the "console" session (not really console session since Vista)? I'm suggesting this, because I'm not really clear on why you are trying to use two sessions instead of one in the first place. Can you elaborate on that a bit?

[InflatableMouse]

Because:
- RDP works just so much better (It works so well I sometimes even forget I am working remotely).
- VNC is yet another process I need to run. 
- RDP allows me to login in another session that doesn't interrupt MC (with TS Patch) and do background work.

Glynor mentioned VNC had gotten much better over the years and since I am using it for connecting to OSX. I admit its not bad but it doesn't quite cut it compared to RDP, I would just get annoyed on the long run. Besides, it would just connect to the console, not allow a second user.

[gvanbrunt]

Fair enough.

But you are aware the TS patch is a hack and not a patch so it is not supported by MS and is bound to have issues. I've read a lot of messages from users with problems especially with fullscreen apps. In addition as bugs are found in the TS files and patched on server systems, this does not happen in hacked situations. So you may be running outdated TS files as well. This may not be a JRiver issue so much as it is one with Terminal Services itself. You can try and see if there are updated versions available.

The other way to do it is to create a Server 2008 R2 Virtual Machine on another computer and fully patch it. Then collect the updated files and install them on your computer.

Not much I know, but it may help.

[InflatableMouse]

I've read a lot of messages from users with problems especially with fullscreen apps.

Are these confirmed issues with the hacked TS files that did not occur on a non-patchedhacked version?

[gvanbrunt]

Have no idea. I just remember reading about issues when I considered doing this to my setup. You can also use it for home versions as they don't have TS enabled. I went with VNC instead from the reading I did.

[InflatableMouse]

Hm. I've not had problems with other full screen applications, including Vmware guests.

What gets me is that its intermittend, often it works fine and then it doesn't, for no obvious reason I can see.

[gvanbrunt]

Ya, that is weird, however I can say that in my previous setup in which I used Vista Pro and reg RDP I occasionally had issues same as you with the Direct3D error as well. So this may not even be something from the "patch" or JRiver but RDP itself.

If it is the "patch", one thing that might be an issue is dll versions getting "out of sync" with each other. As you update your computer RDP files do get updated but the "TS ones" do not. On a real server they would be updated together. So my previous suggestion of grabbing the files from a patched Virtual Machine may help.

If it does, let me know as I have been kicking around giving this a try as well for the same reasons you mentioned. I can do almost everything remotely except move files around as they then have to traverse the network which is slow. Unless you know of some remote file administration program that can move files locally.

[JustinChase]

FWIW, I used to do this also, but haven't re-setup the RDC again since wiping the HTPC.

If either of you finds a good solution, I'd also be very interested, for the same reasons (desire to do things that can only be done on the server, but without interrupting the people using the TV).

[InflatableMouse]

If it is the "patch", one thing that might be an issue is dll versions getting "out of sync" with each other. As you update your computer RDP files do get updated but the "TS ones" do not. On a real server they would be updated together. So my previous suggestion of grabbing the files from a patched Virtual Machine may help.

I don't think DLL version issues exist anymore with Vista/Win7 due to the way Microsoft has changed the way that works. This change started with Windows XP/2000 and has been improved in Vista and Windows 7 (and probably some more in Windows . This should allow different versions of the same DLL to exist side by side (hence the name, Side by Side Assembly).

Also if patching fails due to incompatible files, Windows update either overrides the file with a full version (undoing the patch) or logs a fault (which is visible by a failed installation in Windows update). I've seen neither.

I get your points and I'm not saying you're wrong, I just want to balance the view a bit if you know what I mean. I'm pretty confident this patch hack is not the issue, I suspect it has to do with the state MC is in and whether it can refresh or reinitialize the Direct3D components to redraw the screen. To confirm this, I would have to record the specific screen MC is sitting in and see if there's a link to the crash and where MC is sitting.

FWIW, I used to do this also, but haven't re-setup the RDC again since wiping the HTPC.

If either of you finds a good solution, I'd also be very interested, for the same reasons (desire to do things that can only be done on the server, but without interrupting the people using the TV).

So you were experiencing the same crashes and was it intermittend as well (ie, sometimes it did work)?

[gvanbrunt]

I'm aware of what side by side is, but that has nothing to do with what I'm talking about. "DLL Hell" is what you are speaking of and that only applies to more than one version of the exact same file - not a group of files.

There are files that are part of RDP only (the client part) and files that are part of Terminal Services (the server part). If those go "out of sync" there can be issues. When you patch RDP via Windows Update the TS files do not necessarily get updated. How else would they continue to work? So what I'm saying is you may need to update those files to get any improvements and bug fixes that MS has created.

As for not getting an error: As an Administrator that oversees patching of hundreds of computers I have seen many cases where patches were applied successfully yet files were either not updated or were reverted. We have found them after the fact. In addition you are talking about a hacked version. There are ways of interfering with an update process to prevent overwriting or to revert files after patching. In either case, I would not count things out just because you didn't get an error. One other thing I've learned as an administrator: Never say never. That has bitten me more times than I'd like to admit.

What is the version of the termsrv.dll you have in your system32 directory? Most of the hacked versions are 6.1.7100.0 which is not current.

[InflatableMouse]

What is the version of the termsrv.dll you have in your system32 directory? Most of the hacked versions are 6.1.7100.0 which is not current.

6.1.7601.17514. It's the same version as the one on my own (unhacked) version.

I don't actually replace it with a downloaded hacked version, I 'hack' my own file with a 'patcher' (which is why I called it a patch ). If the patch gets 'undone' (which hasn't happened yet), I just rerun it. The patcher just sets a couple of bits thats all.

[gvanbrunt]

That is the same version that is on one of the servers I manage so you do have the latest.

Interestingly I had MC give the Direct3D (device lost) error right from the desktop without even without using RDP. That I have never seen before.

[InflatableMouse]

Thats weird. Is it reproducable? What did you do exactly when that happened?

[gvanbrunt]

Nope. Just stopped working. I closed Theater View with Alt-F4 and reopend it. No issue after that.

[InflatableMouse]

This time I got the Direct3D error with 'Unable to get device info'. I was able to cleanly exit Theater View, so I was able to reset the log and reproduce. Log is attached.

[InflatableMouse]

I'm reevaluating the way I work and figured I'd give UltraVNC another go. I don't like MC crashing so often. I was about to dump it again when I read about the mirror driver. It disables Aero but other than that ... it works FAST and consumes a lot less CPU power than VNC without it. It is quite a bit faster and snappier than RDP too. The only thing I notice is that it sometimes leaves a mouse cursor trail in the form of display corruption and on the forums some people see VNC server crashes (I haven't seen it yet).

The big drawback is I can't connect to a new user session in the background like I could with the concurrent RDP Patch/hack, I need to figure something out for that I guess.

When connected to the HTPC when a video is playing playback continues uninterrupted and plays in the VNC window too, jerky but it plays and there are no framedrops on the TV itself. I think this is impressive.

[gvanbrunt]

Yes mirror driver makes all the difference. I forgot to mention that.

I haven't had crashes and display corruption has been very rare. I've use both an Nvidia and an ATI card with it on my HTPC. For the most part it works very well.

As for having the VNC running with video going, there is tearing on mine. Every so often I forget to disconnect it and wonder why the video isn't working right. As soon as I disconnect it, it is back to perfect.

I work on tagging etc remotely via client. With my library that is possible as I use mapped drives for file access. That way no matter if I'm on a client or the server the paths are the same.