[Bug Report] SRM Time out after 10000 milliseconds on Deck

[droople1]

Prerequisite Steps

• I have searched existing issues
• This issue is not a duplicate of an existing one
• I have checked the EmuDeck Wiki
• I have read the Troubleshooting Page on the EmuDeck Wiki

What distro are you running?

SteamOS

Which SteamOS Branch are you using?

Stable

What happened?

SRM's bug report form says that emudeck ships its own parser configurations, so I'm bringing this here, first.

I'm the second person on the emudeck Discord server to discover that a Request timed out after 10000 milliseconds. error in Steam Rom Manager can be fixed by running the 2.4.16 version of SRM.

With no connectivity issues, SRM successfully fetches all of the artwork, but when choosing Save to Steam, any new roms have 4 associated Request timed out after 10000 milliseconds. errors. I downloaded the 2.4.16 AppImage directly from SRM's github releases, and running it directly made the problem go away. Directly downloading and running version 2.4.29 made the problem come back. I assume that the AppImages are using the already present configurations in .config or something, but I don't know enough to test any further.

Relevant log output

No response

[cbartondock]

When you say that 2.4.16 fixes it, is that the last version to fix it? Does the timeout happen in 2.4.17? It would be more useful if I knew exactly which version developed the problem.

In 2.4.16 I added internal dns resolution to SRM, but it was getting SRM flagged by some antivirus software so I removed it.

[droople1]

I was able to confirm that the problem did indeed return when I tried to use 2.4.17 or 2.4.15. So I switched to 1.1.1.1 and it went through.

When I'm not using 1.1.1.1, systemd-resolved logs say Using degraded feature set UDP instead of UDP+EDN50 for DNS server 192.168.1.1. But then it says Grace period over, resuming full feature set (UDP+EDN50) for DNS server 192.168.1.1 and alternates between these two messages. That's the only weirdness I can detect so far.

When I have time to keep digging, I'll look into interactions with ipv6. A user in SteamGridDB/steam-rom-manager#583 said it was fixed by turning ipv6 off. Based on my limited knowledge, I'm assuming setting ipv4 to cloudflare overrode ipv6 resolution, somehow?

[droople1]

Okay, new data point today. Explain this one: I booted up my Steam Deck and this time it was on cloudflare dns (confirmed by systemd-resolved). I try to add a couple of roms using SRM, and I get the 10000ms error. I turn off cloudflare dns (back to default), and it fixed it.

Edit: What log do I look at, or test do I perform, or whatever do I whatever at this point?

[cbartondock]

Okay! Good to confirm that this is a DNS issue on steam deck, however I don't think should add back in internal DNS resolution to SRM because it was getting it flagged as a virus. Perhaps as a setting?

[cbartondock]

I have added a settings option in 2.5.9 to specify DNS servers and use internal DNS resolution. This should resolve this issue until the deck fixes its networking problems.