Linux Pop-Os error: C2-12828-1

[Unbornsz]

Please provide the following info.

AMD Mesa version: 23.3.3 - kisak-mesa
Vita Moonlight version: 0.93
Vita Moonlight running on: _PSVita 1000

Output of Vita Moonlight: Enable debug log in settings, then copy ux0:data/moonlight/moonlight.log
moonlight.log

What is the expected result? To be able to stream normally

What happens instead of that? Ok so what happens is the following, i can stream normally on windows 11 using sunshine with my amd card (6700xt) but when i try it on linux pop os, if i start streaming and i'm with the browser on it, it works, but if i minimize, press super (windows button), or try to launch any game (with the exception so far from Dolphin emulator) it gives me the following error: C2-12828-1 Saved Core File Succeeded. ux0:data/ps2pcore-1705821186-0x0000482573-eboot.bin.ps2pdmp

It only happens on linux, windows is working perfect. I thought it was a driver issue, so i reverted back to original pop os supported driver but the error keeps happening. On Android is working with no problems at all, so i believe this problem is only on vita

In the meantime i managed to find a workaround to access my files from linux on windows, just installed a ext file manager, hope this will be fixed in the future

[MetalfaceScout]

I can't say if I'm having the same problem, there's not enough detail but I've done quite a bit of investigation and stuff.
I've parsed my coredump to try and figure out what's going on, whenever it crashes it's either the AudioRecv thread or the ControlRecv thread.

I'm on Vita Moonlight 0.9.3 and PSVita 1000, running Sunshine on Linux with an AMD card.

coredump.txt
moonlight.log

I am simply not able to figure out what's going on here.

[Unbornsz]

Yes is very strange. Just for additional context, tried garuda and nobara, both give me this error. I switched full time for linux and deleted the partition of windows, if someone is like me, the solution so far is to install a windows VM if you don't want to dual boot anymore.
(And yes it works, just tested myself)

[MetalfaceScout]

I noticed issues with any verison of Sunshine after 0.19. Some kind of change there is causing problems that this app isn't able to handle. I wish I had a gdb stub or a devkit.

[angelthorns]

It's an issue with the VA-API encoder, if you change to software encoding in the sunshine settings it should work, but obviously that isn't ideal

[MetalfaceScout]

So any AMD or Intel GPU on linux will use VA-API, causing this problem, Other moonlight apps are able to handle whatever issue the encoder is having. That's at least a place to look for me.

[angelthorns]

va-api is just an abstraction api for hw video encoding, it could be that in the intel gpu drivers it works as it's (maybe) implemented correctly but i dont know if anyone has tested this on intel so.
my guess is that since this moonlight client uses the vita's own h264 decoder that has a 'bug' in it that makes it unable to play the slightly incorrect output from amd va-api that modern devices dont have a problem with

[MetalfaceScout]

I think I got it fixed, try this.

[allan-kg]

I think I got it fixed, try this.

It worked for me.

I was having the same exact issue. I just tried it today, so I don't know about older versions.

System : linux, debian based
GPU driver : amdgpu
PSVita : PCH1010

v0.9.3 : C2-12828-1 after less than 10 seconds streaming.
v0.10.0 : works as expected, tested on BigPicture, Castlevania Lords of Shadow (menu) and GTA IV (20mins gameplay).

I noticed some delay. After checking, the delay was :

1. On PSVita rendering (perceptible to be like 300ms or something).

• On the computer(host), the input was as if I was playing with a plugged controller to the PC, no perceptible delay.
• Both client and host in the same network.

2. On rear pad, the delay was twice or thrice the rendering delay (sometimes it felt like a full second).

• It may be due to the expected input delay by the hardware interpreting the commands.

In both cases, I'm not sure if it was expected to be like this or if it is something to be optimized.

I was living in another planet and just tested moonlight since yesterday, when a friend of mine invited me to play some coop games from his PC. I'm saying that to argue that the delay may not be caused by my modem/router, since it is expected to handle 802.11ac and the gameplay from his PC(host) was just like if it was from mine (same city) - except for the video compaction, as expected.

[Unbornsz]

I think I got it fixed, try this.

Just tested it and now it's able to automatic detect my connection, but when i try to pair it says error: MITM attack detected (Edit 2: nvm, just remembered this issue was on windows)

Gonna try later opening the ports of my modem and see if it works

Edit: Openned the ports but issue still persisted, current workaround for me was to install default vita moonlight and pair with it, then uninstalled and installed your version, it's working. Later i'll try testing with a few games
Current distro: Nobara (fedora based)

[allan-kg]

Edit: Openned the ports but issue still persisted, current workaround for me was to install default vita moonlight and pair with it, then uninstalled and installed your version...

Just adding here that I've installed the release version before trying the pre-release one as well. So it is probably something that would happen to me to.

[allan-kg]

Well, just some updates after some testing:

1 - performance and delay - solved

I noticed some delay. After checking, the delay was

It happened due to the high resolution of my monitor. Lowering the resolution to both vita native and 720p solved this issue.

2 - not possible to pair a new host - confirmed

Edit: Openned the ports but issue still persisted, current workaround for me was to install default vita moonlight and pair with it, then uninstalled and installed your version...

Just adding here that I've installed the release version before trying the pre-release one as well. So it is probably something that would happen to me to.

Well, I tried my friend's PC (Sunshine + Windows), and with v0.10.0 it hung and did not show any code when it was supposed to. My friend confirmed that he did not receive a request.

I reinstalled v0.9.3, then paired, then reinstalled v0.10.0, then it worked like a charm.

3 - disconnecting while the game stills running

Well, I'm still checking why:

• I could play with my friend for some time without any problem (Sunshine + Windows).
• Yesterday I could connect to my host (Sunshine + Linux) and got 20 minutes of input-delayed gameplay, without any disconnection like this.
• Today I tried 2 favorable resolutions (vita native and 720p), and every 5 mins or less it auto disconnected.
  • Sunshine + Linux
  • The chances of disconnecting increased with higher quality CBR/QP.
  • Resetting to default still led to the disconnection.

By now I suspect that it occurs due to the constant high bitrate (stable 60fps). I'll try setting lower frame rates and resetting Sunshine later.

[MetalfaceScout]

This is helpful, thank you, I'll continue working on it.

[allan-kg]

The disconnection was related to a script of mine.

So, it seems to be just the pairing with v0.10.0.

Do you want me to create an issue for this?

[MetalfaceScout]

No, that's alright. I've got a new release up. I did a bunch of testing on this one in a local connection environment and it was doing well. Let me know if there's any more issues, preferably here. I appreciate your detail in testing.

[allan-kg]

It worked. I could only test the pairing to Linux to this moment.

• I did it by deleting data/moonlight/<hostname.d> and searching again for the device.
  • I believe that it was enough to reset the host information, as it informed a PIN.

I'll try to pair to Windows when possible.

By now, I couldn't find any other detail besides that v0.10.0 triggers the same message as the other versions in Sunshine's log : Warning: SSL Verification error :: self signed certificate, which means that a connection was indeed being established a short before the "Can't add device list" message appears. But then you fixed in v0.10.1, so I believe that this information would just be useful if you wanted to revert something else to focus only on this detail in ui_connect.c.