First connection errors #123
Comments
|
It's more likely caused by your host's configuration. Could you please share your PC configuration? |
|
What details of PC configuration do you need exactly? Host Client |
|
Oh you're using the desktop client. It's weirdly slow when initiating a stream and this message might actually be caused by the client itself. Can you confirm the same message still pops up with Android client or iOS client? |
|
Same errors occur using your Artemis moonlight fork for Android, however it loads the screen after the AV1 warning, no black screen. HEVC fallback. Each time opening on Artemis says no AV1 decoder found. Not just first time. It never uses AV1 despite having it selected in Artemis settings. Phone |
|
Yeah so it's the client's issue. I haven't got time to look into the desktop client yet so unfortunately I can't be sure what's happening. What's the error on Artemis then? |
|
Actually from Google maybe the Qualcomm Snapdragon 8+ Gen 1 doesn't have AV1 decode. Getting conflicting answers online. Thanks for your help in any case, I guess we can leave it there. |
|
The status overlay will show what decoder is actually used. IIRC 8G1 doesn't have AV1, it starts supporting AV1 from 8G2. |
|
I get a similar problem using Apollo, whether using Artemis or a standard Moonlight client. On my first attempt to connect, I'll get a momentary error on the overlay telling me the server device GPU doesn't support HDR. Colors will be noticeably distorted. Then I'll disconnect and reconnect, and HDR will work fine. This is with Apollo running on an up-to-date Windows 11 install, with a 5900x and a 4080 Super with up-to-date drivers. The client devices have been Artemis on a Galaxy S24+ (Snapdragon 8 Gen 3) and Moonlight on my M2 Max Macbook Pro Pro. This is whether I try to force AV1, HEVC or have it set to auto in the codec setting in the client. |
|
It's a Windows issue. Probably that's why Parsec still doesn't make HDR on their virtual display available. |
|
Is it particular to newer builds of Windows? I didn't run into this issue when using the mainline Sunshine, but having it mirror my real physical primary display (instead of a virtual device driver), which was HDR-capable and had it enabled in Windows. But that was also now a couple of months ago, and I don't know if anything's changed since then. Or is it something about the way Windows with the virtual driver specifically -- perhaps when the virtual driver is set to configure its capabilities on-demand based on the client settings? If so, would there be any way to work around this by having a setting in the server config to force HDR on? It works fine on a second connection -- could the server be "primed" to mimic whatever's happening between the first and second connection? If not with Apollo itself, with something Artemis does? For a while, I was briefly trying Sunshine AIO, but I gave up on it when some of the scripts were failing on my machine after an update, and this project seemed (and has been!) much more seamless overall to use. I don't think I ran into this issue there though, either. (Forgive the rambling speculation -- I have only a minor insight into how any of this might work) |
It's this problem, and it exists through Win11 23H2 and 24H2. MTT's VDD doesn't expose this problem since the virtual display it creates presists, and the problem only happens when a new display is just added. I have already workaround the color issue by toggling HDR on and off on the newly attached virtual display automatically but don't know why it can't detect HDR capability on your system on the first connection. Windows is still very janky about HDR so... that's why there's the message about HDR in the README. |
|
Unfortunately, I'm still getting the error that the server doesn't support HDR rendering on a first connection. As with before, if I disconnect and reconnect, HDR is working properly on the virtual display. This is with Artemis on Android but I've seen it with Moonlight on other OSes as well. |
|
You need to set encoder support to always advertise. Then it'll work. |
|
Sorry, where do I set that? Under "advanced," I have Apollo will advertise support for HVEC based on encoder capabilities" (and the same for AV1.) Under the codec settings in Artemis, it looks like I had it as "prefer HEVC" (though I'd thought I had it on automatic). This is on Win 11, latest NVidia drivers, Apollo v0.2.7. The client is the latest version of Artemis on a Samsung S24+. |
|
Set them both to always advertise. You don't change your GPU very often right 😂 When using headless mode, the initial probing for encoder support is skipped, so it can only read from user configs. Previous versions didn't do that, encoder capabilities were left blank at startup, probing was delayed to the first connection, that's why it only had that message on the first connection. |
|
Running master and setting both settings to always advertise, I have still the same error and behaviour. |
|
|
|
Same. I had both set as in the screenshot, and still got the same message and behavior. |
Yep, like that and still have the errors |
|
Weird, have you pulled the latest master? Or can you try my build? |
|
This was on .2.7. Do you mean a build newer than that, and if so where do I get it? I'd be glad to test again,but can't until later tonight. |
I actually didn't notice you had pushed additional commits since yesterday, sorry. |
On the first connection to the Host, pop-up warnings flash up that both the host and client can't encode/decode AV1 or do HDR.
A black screen then appears on connection.
Once you quit the first connection and reconnect a second time everything works as normal, with AV1 and HDR.
Is there any way to fix this?
The text was updated successfully, but these errors were encountered: