-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems with netplay guest #3161
Comments
I managed to reproduce this, but it's not fully clear why it happens. The content is matched based on CRC (so I think a playlist won't help), and if fails with
which is puzzling, since the core is already loaded (!). The error message is from https://github.com/libretro/RetroArch/blob/01bd76405fc1441c200de54f5cfe920c6da44fcd/tasks/task_netplay_find_content.c#L145, but tracing back to see where The error shows up even with a vanilla RetroArch configuration (i.e. no RetroPie specific configs). @alessandropaggi in your test, the RetroArch host on the PC is from another RetroPie installation or is it an install downloaded from the Libretro site ? |
@cmitu The host on the laptop is running RetroArch downloaded from the Libretro site, which just works for netplay out of the box. I also set up a RetroPie running on a virtual Ubuntu machine, and it fails connecting to the RetroPie on the Pi4, since none of them can act as a guest. The RetroPie running on the virtual Ubuntu machine works as a host for RetroArch running on the laptop but cannot join as a guest, exactly like the RetroPie running on the Pi4. |
I don't know if this is related, but after loading a core on RetroArch running on the laptop if I go in the RetroArch Menu |
That's probably because there's no playlist associated - the playlist contains the core info. {
"path": "/home/pi/RetroPie/roms/pc/Quake.conf",
"label": "",
"core_path": "/home/pi/src/c1/dosbox_core_libretro.so",
"core_name": "DOSBox-core",
"crc32": "",
"db_name": ""
}, It may be that RetroArch tries to re-load the core, but since the cores are not installed where RetroArch expects them to be, it errors out. Did this process ever worked for you or is it something that's been - relatively - changed recently ? I did a test with 1.8.5 (as client, from RetroPie) and I get the same behavior. |
I think that I was able to create playlists with older RetroPie versions, but I was never able to join netplay. |
There is a workaround for this, just by adding the cores to the location where RetroArch expects them:
|
Ok, this changed something. With the symbolic link to the core in the same directory of the core infos I am able to create playlists. RetroPie is still able to serve as a host. When I try to join netplay RetroPie loads the correct core and content, but it always shows the message |
Haven't tried all the situations, but in my tests I always have the (same) content loaded when starting netplay, both on host and client. I didn't use a playlist at all. Enable verbose logging on the client and and post the debug messages from the client (not the whole log, just the portion regarding netplay initialization). |
This is the log of RetroArch running on the laptop successfully joining the RetroPie host
(I don't know if the
The same output is obtained when RetroPie tries to connect to a host in the room list
|
The failures on the PI site look like network/connection issues, not related to RetroArch. Is the host computer in the same LAN ? |
Yes, but the same happens when the laptop is connected to another network:
RetroPie as a guest
|
If I look at the log, I can see that it's the same (host) IP address used to connect for both cases:
This is not a LAN address - did you forward the netplay port ( |
Yes. |
Then it can't possibly work - at least in this test - since RetroPie client cannot connect to itself. Try using the LAN address to connect. It's a bit difficult to see in RGUI, but using the XMB or Ozone input driver I think you're able to see the IP address. |
I've set the respective LAN addresses and the result is always the same (RetroArch connects as guest, RetroPie does not). I've also tried disabling the port forwarding, and connecting the laptop to another network. The result did not change. |
I can't reproduce this case - for me the LAN connection worked - with the aforementioned workaround. |
Can you please pastebin your |
I have a stock RetroArch config - if you'd like to replicate it, just replace yours with the |
Still the same behavior. I guess I have some connection problems or router configuration to fix. |
I did some test on netplay rooms and was finally able to join as a guest. I guess I was having some lan problems. |
Glad you sorted out the network issue. |
Core info files are needed starting from 1.10+ in order to enable like save/load state, disk control (netplay ?). In addition to that, they're also needed for netplay clients (see issue RetroPie#3161).
Added 2 new parameters for the runtime-generated `retroarch.cfg`: * `libretro_log_level` will add more debug messages from the libretro core, in addition to the frontend debugging messages. Cand be useful to diagnose core issues, since `--verbose` activates just the frontend logging. * `libretro_directory` is set to the core file folder (i.e. `/opt/retropie/libretrocores/lr-<core>`). It is used by during netplay, as a client, when RetroArch attempts to re-load the core used during netplay. Basically, when connecting to a remote netplay host, RetroArch will try to locate a `core.info` file and based on it to re-load the core file. If any of them is missing, the connection fails with "Couldn't find a suitable core or content file". The netplay issue was reported and diagnosed in RetroPie#3161. Rather than symlink each installed libretro core to `$HOME/.config/retroarch/cores` (the default value for `libretro_directory`), we'll just set it at runtime with the above parameter. We still need to add the `.info` files for the installed cores, but that's a separate patch.
Added 2 new parameters for the runtime-generated `retroarch.cfg`: * `libretro_log_level` will add more debug messages from the libretro core, in addition to the frontend debugging messages. Cand be useful to diagnose core issues, since `--verbose` activates just the frontend logging. * `libretro_directory` is set to the core file folder (i.e. `/opt/retropie/libretrocores/lr-<core>`). It is used by during netplay, as a client, when RetroArch attempts to re-load the core used during netplay. Basically, when connecting to a remote netplay host, RetroArch will try to locate a `core.info` file and then try to re-load the core file. If any of them is missing, the connection fails with "Couldn't find a suitable core or content file". The netplay issue was reported and diagnosed in RetroPie#3161. Rather than symlink each installed libretro core to `$HOME/.config/retroarch/cores` (the default value for `libretro_directory`), we'll just set it at runtime with the above parameter. We still need to add the `.info` files for the installed cores, but that's a separate patch.
Added 2 new parameters for the runtime-generated `retroarch.cfg`: * `libretro_log_level` will add more debug messages from the libretro core, in addition to the frontend debugging messages. Cand be useful to diagnose core issues, since `--verbose` activates just the frontend logging. * `libretro_directory` is set to the core file folder (i.e. `/opt/retropie/libretrocores/lr-<core>`). It is used by during netplay, as a client, when RetroArch attempts to re-load the core used during netplay. Basically, when connecting to a remote netplay host, RetroArch will try to locate a `core.info` file and then try to re-load the core file. If any of them is missing, the connection fails with "Couldn't find a suitable core or content file". The netplay issue was reported and diagnosed in RetroPie#3161. Rather than symlink each installed libretro core to `$HOME/.config/retroarch/cores` (the default value for `libretro_directory`), we'll just set it at runtime with the above parameter. We still need to add the `.info` files for the installed cores, but that's a separate patch.
Core info files are needed starting from 1.10.1 in order to enable save/load state, rewind, runahead, (disk control ?). In addition to that, they're needed for netplay clients to work (see issue RetroPie#3161).
Added 2 new parameters for the runtime-generated `retroarch.cfg`: * `libretro_log_level` will add more debug messages from the libretro core, in addition to the frontend debugging messages. Cand be useful to diagnose core issues, since `--verbose` activates just the frontend logging. * `libretro_directory` is set to the core file folder (i.e. `/opt/retropie/libretrocores/lr-<core>`). It is used by during netplay, as a client, when RetroArch attempts to re-load the core used during netplay. Basically, when connecting to a remote netplay host, RetroArch will try to locate a `core.info` file and then try to re-load the core file. If any of them is missing, the connection fails with "Couldn't find a suitable core or content file". The netplay issue was reported and diagnosed in RetroPie#3161. Rather than symlink each installed libretro core to `$HOME/.config/retroarch/cores` (the default value for `libretro_directory`), we'll just set it at runtime with the above parameter. We still need to add the `.info` files for the installed cores, but that's a separate patch.
Core info files are needed starting from 1.10.1 in order to enable save/load state, rewind, runahead, (disk control ?). In addition to that, they're needed for netplay clients to work (see issue RetroPie#3161).
@alessandropaggi this has taken more than needed, but it should be solved with #3549 and #3548. But now, since RetroArch 1.10.1 will make - almost - mandatory the presence of I don't know if you can still test it (make sure to update RetroPie-Setup first and then the RetroArch package), but would be nice to have a 2nd confirmation. |
@cmitu Thanks for looking into it. |
Yes, you should remove them and also clear the |
Added 2 new parameters for the runtime-generated `retroarch.cfg`: * `libretro_log_level` will add more debug messages from the libretro core, in addition to the frontend debugging messages. Cand be useful to diagnose core issues, since `--verbose` activates just the frontend logging. * `libretro_directory` is set to the core file folder (i.e. `/opt/retropie/libretrocores/lr-<core>`). It is used by during netplay, as a client, when RetroArch attempts to re-load the core used during netplay. Basically, when connecting to a remote netplay host, RetroArch will try to locate a `core.info` file and then try to re-load the core file. If any of them is missing, the connection fails with "Couldn't find a suitable core or content file". The netplay issue was reported and diagnosed in RetroPie#3161. Rather than symlink each installed libretro core to `$HOME/.config/retroarch/cores` (the default value for `libretro_directory`), we'll just set it at runtime with the above parameter. We still need to add the `.info` files for the installed cores, but that's a separate patch.
Added 2 new parameters for the runtime-generated `retroarch.cfg`: * `libretro_log_level` will add more debug messages from the libretro core, in addition to the frontend debugging messages. Cand be useful to diagnose core issues, since `--verbose` activates just the frontend logging. * `libretro_directory` is set to the core file folder (i.e. `/opt/retropie/libretrocores/lr-<core>`). It is used by during netplay, as a client, when RetroArch attempts to re-load the core used during netplay. Basically, when connecting to a remote netplay host, RetroArch will try to locate a `core.info` file and then try to re-load the core file. If any of them is missing, the connection fails with "Couldn't find a suitable core or content file". The netplay issue was reported and diagnosed in RetroPie#3161. Rather than symlink each installed libretro core to `$HOME/.config/retroarch/cores` (the default value for `libretro_directory`), we'll just set it at runtime with the above parameter. We still need to add the `.info` files for the installed cores, but that's a separate patch.
Added 2 new parameters for the runtime-generated `retroarch.cfg`: * `libretro_log_level` will add more debug messages from the libretro core, in addition to the frontend debugging messages. Cand be useful to diagnose core issues, since `--verbose` activates just the frontend logging. * `libretro_directory` is set to the core file folder (i.e. `/opt/retropie/libretrocores/lr-<core>`). It is used by during netplay, as a client, when RetroArch attempts to re-load the core used during netplay. Basically, when connecting to a remote netplay host, RetroArch will try to locate a `core.info` file and then try to re-load the core file. If any of them is missing, the connection fails with "Couldn't find a suitable core or content file". The netplay issue was reported and diagnosed in RetroPie#3161. Rather than symlink each installed libretro core to `$HOME/.config/retroarch/cores` (the default value for `libretro_directory`), we'll just set it at runtime with the above parameter. We still need to add the `.info` files for the installed cores, but that's a separate patch.
After removing the symbolic links and the |
@alessandropaggi hm, can you also re-install EDIT: do you have a saved |
Ok, I've cleaned again the
which I commented out. Trying to join a netplay room as a guest now just crashes retroarch going back to ES with this log
This is the content of
Uncommenting the
|
Thanks for testing. I haven't encountered any crash, but I wonder if it's because of an incorrect |
Yes, that's possible. |
Fix the extra space added in the value of `libretro_directory`,caused by the `grep` pattern in 553c4fe. The extra space crashed RetroArch when trying to initiate a netplay connection (as a client), see RetroPie#3161 (comment).
Fix the extra spaces added in the value of `libretro_directory`,caused by the `grep` pattern in 553c4fe. The extra space at the beginning crashes RetroArch when trying to initiate a netplay connection (as a client), see RetroPie#3161 (comment).
Ok, after 3558 I don't get the crash anymore. |
Are the host and client running the same core and ROM ? |
Yes.
It is not set in the system's |
What game are you using for testing ? |
Super Mario World for SNES. Note that the same rom and core work without cleaning the |
I see. I've tried with Super Mario World (USA) and the netplay works - I can connect to the host without the error ( One difference may come from the |
Thanks for taking the time to dig into it.
I also use a core override, pasted here: https://pastebin.com/wZ1NF2cs |
I still can't reproduce it - either by a direct LAN connection or a Relay server. # After starting hosting, using Madrid Relay server to announce the host
[INFO] [Netplay] You have joined as player 1
[INFO] [Netplay] Queued tunnel link connection.
[INFO] [Netplay] Tunnel link connection completed.
[WARN] [Netplay] WARNING: A netplay peer is running a different version of RetroArch. If problems occur, use the same version.
[INFO] [Netplay] Connection slot 0
[INFO] [Netplay] Got connection from: "saccublenda"
[INFO] [Netplay] saccublenda has joined as player 2 (ping: 101 ms)
# Stopping host, disable relay
[INFO] [Netplay] "saccublenda" has disconnected
# ..then start host again.
[INFO] [Netplay] You have joined as player 1
[INFO] [Netplay] Netplay UPnP Port Mapping Failed
[INFO] [Discovery] Query received on LAN interface.
[WARN] [Netplay] WARNING: A netplay peer is running a different version of RetroArch. If problems occur, use the same version.
[INFO] [Netplay] Connection slot 0
[INFO] [Netplay] Got connection from: "saccublenda"
[INFO] [Netplay] saccublenda has joined as player 2 (ping: 25 ms) Client (RetroPie): # Using relay server
[INFO] [Lobby]: Testing CRC matching for: B19ED489|crc
[INFO] [Lobby]: Current content CRC: B19ED489|crc
[INFO] [Lobby]: CRC match B19ED489|crc with currently loaded content
Map_LoROMMap
Map_LoROMMap
[INFO] [Lobby]: Loading core /opt/retropie/libretrocores/lr-snes9x/snes9x_libretro.so with current content
[INFO] [Netplay]: Connecting to europe-west1.relay.retroarch.com|55435 (direct)
[WARN] [Netplay] WARNING: A netplay peer is running a different version of RetroArch. If problems occur, use the same version.
[libretro INFO] Nonexistent Port (8).
[libretro INFO] Nonexistent Port (9).
[libretro INFO] Nonexistent Port (10).
[libretro INFO] Nonexistent Port (11).
[libretro INFO] Nonexistent Port (12).
[libretro INFO] Nonexistent Port (13).
[libretro INFO] Nonexistent Port (14).
[libretro INFO] Nonexistent Port (15).
[INFO] [Netplay] Connected to: "mitu1"
[INFO] [Netplay] You have joined as player 2 (ping: 110 ms)
# Host stops netplay, client got disconnected
[INFO] [Netplay] Netplay disconnected
# connecting again via LAN discovery
[INFO] [Lobby]: Testing CRC matching for: B19ED489|crc
[INFO] [Lobby]: Current content CRC: B19ED489|crc
[INFO] [Lobby]: CRC match B19ED489|crc with currently loaded content
[INFO] [Lobby]: Loading core /opt/retropie/libretrocores/lr-snes9x/snes9x_libretro.so with current content
[INFO] [Netplay]: Connecting to 192.168.10.199|55435 (direct)
[WARN] [Netplay] WARNING: A netplay peer is running a different version of RetroArch. If problems occur, use the same version.
[libretro INFO] Nonexistent Port (8).
[libretro INFO] Nonexistent Port (9).
[libretro INFO] Nonexistent Port (10).
[libretro INFO] Nonexistent Port (11).
[libretro INFO] Nonexistent Port (12).
[libretro INFO] Nonexistent Port (13).
[libretro INFO] Nonexistent Port (14).
[libretro INFO] Nonexistent Port (15).
[INFO] [Netplay] Connected to: "mitu1"
[INFO] [Netplay] You have joined as player 2 (ping: 38 ms) I've loaded your main Not sure what to try next :/, looks like a real puzzler. |
Thanks anyway for taking the time to dig into it. |
@alessandropaggi thank you for testing. Still can't explain why it's not working. |
I'm clueless too. I may retest it on a fresh installation during the weekend. |
Ok, I've tried with a fresh install, updated everything, and IT WORKS! I guess there's something wrong with my current configuration, but I will stick with it anyway until the bullseye image comes out. So long, and thanks for all the testing. |
@alessandropaggi thanks again for testing. I'll leave this open; maybe the symlink approach is a safer solution - I'll do some more tests with my previous approach and see if we can find an all-around working solution to this issue. |
Added 2 new parameters for the runtime-generated `retroarch.cfg`: * `libretro_log_level` will add more debug messages from the libretro core, in addition to the frontend debugging messages. Cand be useful to diagnose core issues, since `--verbose` activates just the frontend logging. * `libretro_directory` is set to the core file folder (i.e. `/opt/retropie/libretrocores/lr-<core>`). It is used by during netplay, as a client, when RetroArch attempts to re-load the core used during netplay. Basically, when connecting to a remote netplay host, RetroArch will try to locate a `core.info` file and then try to re-load the core file. If any of them is missing, the connection fails with "Couldn't find a suitable core or content file". The netplay issue was reported and diagnosed in RetroPie#3161. Rather than symlink each installed libretro core to `$HOME/.config/retroarch/cores` (the default value for `libretro_directory`), we'll just set it at runtime with the above parameter. We still need to add the `.info` files for the installed cores, but that's a separate patch.
Core info files are needed starting from 1.10.1 in order to enable save/load state, rewind, runahead, (disk control ?). In addition to that, they're needed for netplay clients to work (see issue RetroPie#3161).
Fix the extra spaces added in the value of `libretro_directory`,caused by the `grep` pattern in 553c4fe. The extra space at the beginning crashes RetroArch when trying to initiate a netplay connection (as a client), see RetroPie#3161 (comment).
I've posted many times on the forum about this issue, but I've still got no answer so here I am. I can't connect to netplay rooms with Retropie despite running the same core and the same rom (same CRC) of the host. Every time I try to connect to a netplay room I get the the messages:
Compatible content found
Couldn't find a suitable core or content file, load manually
I've also ran this test: I am running Retropie on a Pi4 and Retroarch on my laptop (same Retroarch version, same core, same rom). I did not perform any rom scan on neither system (see below), I was just launching the same rom on the same emulator. On the host side I went in Retroarch menu
Netplay
->Host
->Start Netplay Host
. On the guest side I went in Retroarch menuNetplay
->Refresh Room List
and selected the host room.Retropie is able to serve as a netplay host, that is, I was able to join the Retropie netplay host room as a guest from Retroarch running on the laptop.
Retropie cannot join netplay as a guest, that is, when I try to join the host room of Retroarch running on the laptop, I get the messages shown before. This also happen on any netplay host room I see in the room list.
I also tried installing Retropie on an Ubuntu virtual machine, obtaining the same results.
I don't know if this related, but I also tried to create a playlist by scanning the rom directory, by going in Retroarch menu
Main Menu
->Load Content
->Playlist
->Scan Directory
, selecting the rom directory and then Scan This Directory. On Retroarch running on the laptop this correctly created a playlist with the roms found in the directory, while Retropie is not able to find any content.The text was updated successfully, but these errors were encountered: