XXHighEnd

Hi Peter,

First impressions of 2.08d:

• Gorgeous sound.
• When starting the pc I get an error: "explorer.exe – System Warning – Unknown Hard Error".
• When I start playing XXHE the Remote Desktop connection to the PC is lost. This happens in unattended mode as well as attended mode. I then have to hard-reboot my pc to get into the OS again. I also tried without stopping LAN and/or checking persist in the settings, but the connection is lost in any case.

Any ideas? As you know, I am on WS2016. Not sure whether it is related to that. I did not have this issue with 2.07 on WS2016.

Cheers, Dennis

Dennis,

With always the anticipation on a fresh OS install ...

Is this in Minimized OS as well ?
I ask, because Windows 10 has a famous kind of bug of not being able to sustain the RDC connection in Normal OS while it is fine in Minimized OS.

The Explorer error is also know, but actually from Minimzed OS and shutting down / rebooting (and an ealier W10 Build than today's).


That happening in Attended mode would be new to me (or maybe I just never tried - if only this happens in Normal OS and not in Minimized OS).

Regards,
Peter

Peter,

Actually it is the other way around: in normal OS, RD stays connected, in attended as well as unattended mode.
When I went back to minimized mode: this time it went well in Attended; but in Unattended the connection is always lost and I have to hard-reboot the pc.
Also, a few times the pc froze at "Waiting for the Group Policy Client".

The explorer error did not return; I hope it will stay away.

* postscript *
Interesting. I de-activated 'Keep LAN Services' and then, playing from a local usb stick, the RD connection stayed intact during Unattended playback with Minimized OS. Actually, that is the way I usually play (pre-converted) wav files, so I could live with that.

I think I know what is going on in there - some specific check for a combination of the OS Name (which is W10 for the desktop version and WS2016 for the server version), which check(s) must be performed for WS2016 as well. For 2.07 this would have worked out OK because there the server version was just denoted W10 ...

So let me try to find all the code checking for this ...

Peter

In Settings, Services and OSD section, there's a Stop W10 Services button. Do you have that active (red) ? If Yes, can you quickly check what happens with your RDC connection if you deactivate that ? Please apply the deactivation in Normal OS and then boot into MinOS.

If you are not there at this moment to try it, just let me know that, so I will not be waiting for your answer (and continue with something else first).

Thanks,
Peter

For this one, see below 2.08e (paste over 2.08d would be best for my own interpretation of matters).

This is only a test and the question to you whether you are still "able" to see this "waiting for" message. If not and you are persistent in being sure it has gone, there will be a next step in this one.

I also eliminated a check for 14393.xxx (14400.xxx actually) so for anyone who has a newer build than that (not you Dennis, unless very recently) a certain approach is now done for those newer builds just the same (resulting in something which was necessary from of 14388).

Peter

Peter, I am now working on it...

By the way, I never activated 'Stop W10 Services' before.

* result *

• First I applied your XXHighEnd-208e-X patch (although unrelated to the RD desktop issue I guess).
• Then rebooted into normal OS: RD connection remained OK in Attended as well a Unattended mode.
• Then activated 'Stop WS Services': RD connection remained OK in both modes.
• Then de-activated 'Stop WS Services': no problem.
• Then rebooted into Minimized OS.
• Then noticed it is impossible to get the LAN up using the 'LAN On' button; nor is it possible play with the 'Keep LAN Services' setting on. It keeps asking whether I want to wait longer, but eventually I don't.
• Playing goes well – and RD connections remains OK – with the 'Keep LAN Services' setting off, just playing from a stick.

So the behavior appears unchanged compared to yesterday's report.

Dennis

Dennis, a quick note : please do not edit posts like you did with this one, because I am waiting for your response (after your initial "working on it"), while you edited it in in the other post. I (or anyone) just won't see that (unless by accident).
:)
Peter

I suppose it is totally obvious, but I don't see what "WS" services are ?

I suppose this works differently from what you expect;

The check for the LAN goes by means of checking whether the last file played (actually the track selected in the Playlist Area) can still be found. If not, the LAN is reported not to be there ... :swoon:


Sadly this is not a build-in feature and merely a kind of bug. I mean, when you don't have the LAN you also won't have an RDC connection, right ? Well, sort of, because when you Keep the LAN "not persistent" it shuts off when playback starts but RDC activity remains.So the bug in this case comprises of shutting off the LAN (in normal OS arranged for) while using RDC overrules that partly (as it seems).
Btw, the sheer fact that you try this (for its working) could imply some kind of pilot error I don't think of.

These should be the crucial settings :
Be in Normal OS
Load a track (or more) in the Playlist Area; select it.
Stop Desktop
Stop Remaining
Stop W10 (just because I use it like that myself)
Use Remote Desktop.
Keep LAN, Not Persist (the latter means it shuts off during playback, the former means it will not be cut off right from the start (the boot).
Boot into MinOS.

No need to test or report about Attended Playback. Only Unattended.

Can you now try this :
Go back to Normal OS again.
Make OSIsW10.tst active (you will understand what I mean) because it should imply the same siuation as with 2.07, regarding this.
Same settings as above.
Go to MinOS.

Now it works ?

So the 2.08e is for testing what happens with this Group Policy Message. I hope you can let me know when you are confident it will stay away, or is still there.

Peter

oops sorry, next time I will make a new post...

sorry, typo, it should have been W10 services :-|

It does work!

Actually, OSIsW10.tst already had the tst extension, so that means it was already active?

I could not resist also trying to rename OSIsW10.tss to OSIsW10.tst (and OSIsW10.tst back to OSIsW10.tss), and that also worked fine. Or am I messing things up?

Also, the LAN On button works now. Now you explained how it works, it seems logical that it does not work with a playlist loaded from a usb stick?

Thanks, Peter!

Hi Dennis,


Haha, yes. But you had this from your previous attempt with 2.07.
Not that I can follow really what happened now and why it now works fine.


Well, it should. But only if that USB stick is still in ...  :)

OK, good. Problem solved. :scratching:
:)
Have fun now !
Peter

PS: But still waiting on that Group Policy thing, because at this moment (2.08e) something is On which can be Off.

I did not want to celebrate too soon, but indeed no more group policy thing since 2.08e.

OK Dennis, thank you.
In the end of the afternoon I plan to have a 2.08f which theoretically also won't nag about the Group Policy thing. But then in the way I like it.

Peter

Ahum - That end of the afternoon became later than planned and in the end it never happened. I will do it today now !

Peter

great Peter, at your ease! thx Dennis

Well Dennis, it now appears that I can't do much about that Group Policy matter, other than let it be as it is now. But still a small attempt :

Can you try to explain when this message "Waiting for Group Policy" appears, and also how it disappears. Maybe in other words : could it be bearable if we bring the situation back to 2.07d (I think it was).
At this moment, and without looking, I'd say that this message can there be forever, unless you start playback again. And then still it can be "bearable". And for example, if you need to click it away, then I would not like this ...

?

Peter

Peter,

If I remember well, it was an occasional blue screen which just froze when I tried to stop or restart the pc, with the 'waiting circle'.
I then had to hard-shutdown.

Do you advise to go back to 2.08d? If I do I can give you a more precise description.

Alas, I am going on holiday Saturday for 2 weeks, and it is extra busy right now, but I will try to make some time for this.

Best, Dennis

Thank you Dennis, but I think there is no need for this. The process of concern wants to start but can't. That is, I tried myself (emulated in 14393.0 Desktop version) and couldn't and then found my own documentation that I gave up on this a few years ago already. Point is : the destkop versions don't need it so once shut off in the proper way it stays away (and can only be restarted in normal OS), but apparently your WS2016 requires it and indeed can't start it herself just the same. So, dead end.
For net result it now is not shut down so nothing nags.

For more net result the server version could be somewhat less good sounding, although I never tested it (I have it but never felt tempted to install it for real and try it). And maybe to keep in mind : a Server version won't be different after all the stripping-off XXHighEnd does with the Desktop versions.

So Dennis, what you could do with some more available time, later, is compare your WS2016 with normal 14393.0.
Also to remember : your WS2016 is not of the 14393.0 "base" but is of a hihger Build number (14393.0 is the one officially supported by XXHighEnd). But don't ask me where to get the Server version with Build 14393.0.
Btw, changes will be very very small 14393.0 suddenly will be OK on this matter, as the Group Polily features will be too much in the heart of a Server (version).

So let's say it is okay as it is and that I am glad we could get it running without me having it running myself. Thanks to you of course !

Best regards,
Peter

Agreed Peter. I appreciate it that you spend time on WS2016 without running it yourself, and still made it work pretty close to 100%.
Thanks for that! Dennis