ALVR stuck at "Waiting for server to start", SteamVR says Headset not found

[LuNeder]

Description

On any version after ALVR v19.0.0-dev02+nightly.2022.09.19, including the 19.0.0 final and the 20.0.0 nightly, ALVR stays stuck on the "Waiting for server to start screen". It launches SteamVR while the Waiting screen never closes and the SteamVR window says Headset not found (and the green icons do not appear). On ALVR v19.0.0-dev02+nightly.2022.09.19 everything runs OK: Waiting for server appears, then disappears and launches SteamVR working fine.

The error is: Unable to load driver alvr_server from /home/luana/Applications/alvr_server_linux/lib64/alvr/bin/linux64/driver_alvr_server.so (libavutil.so.56: cannot open shared object file: No such file or directory). ~However, I can't seem to find info about libvutil or what package includes it, and also the previous nightly worked fine.~ (nvm, I mistyped its name when searching for it) However, it is installed.

Edit: see my next comment, it’s a dependency hell for LOTS of libraries bc ALVR expects a sightly older version of them but not all of them can be installed (and one of them could be installed but gave another error)

However, the 2022.09.19 is outdated and has the bug described on #1246 so I wanted to update.

The 19.0.0 final version has this problem, as well as the nightly immediately after 2022.09.19 (the 2022.09.22) and as well as 20.0.0 latest nightly (2022.11.12). The ALVR v19.0.0-dev02+nightly.2022.09.19 seems to be the last one to work.

General Troubleshooting

• [y ] I carefully followed the instructions in the README and successfully completed the setup wizard
• [ y] I read the ALVR Wikis here and here

Environment

Hardware

Note: for Linux, an upload to the hw-probe database is preferred: hw-probe -all -upload

Here, but it's wrong. It detected KDE, but I use XFCE (even tho KDE and gnome are instaled, I do not use them): https://linux-hardware.org/?probe=3b6d611387

Here's a Neofetch with correct info: luana@Luana-Z370XP-SLI

---

OS: openSUSE Tumbleweed x86_64 Host: Z370XP SLI Kernel: 6.0.7-1-default Packages: 6290 (rpm), 37 (flatpak), 15 (snap) Shell: zsh 5.9 Resolution: 1920x1080 DE: Xfce 4.16 WM: compiz Terminal: xfce4-terminal CPU: Intel i7-8700K (12) @ 4.700GHz GPU: NVIDIA GeForce GTX 1070 Ti Memory: 3541MiB / 32039MiB

Audio: pipewire / jack

Installation

ALVR Version: As stated, problem happens on any versions AFTER v19.0.0-dev02+nightly.2022.09.19

SteamVR Version: 1.24.6, but also happens on 1.25.1 beta

Install Type: [ ] Packaged (exe, deb, rpm, etc) [ y ] Portable (zip) [ ] Source

OS Name and Version (winver on Windows or grep PRETTY_NAME /etc/os-release on most Linux distributions): OpenSUSE Tumbleweed

[LuNeder]

I ran sudo ln -s /lib/libavutil.so.56.70 /lib/libavutil.so.56

but now the error was Unable to load driver alvr_server from /home/luana/Applications/alvr_server_linux/lib64/alvr/bin/linux64/driver_alvr_server.so (libavutil.so.56: wrong ELF class: ELFCLASS32)

So I removed the link and installed the library from a community repo, but now another one is missing (also because the installed version is more recent (7_110) than the asked one (libavfilter.so.7).

But Libavfilter7 requires libsrt1, and libsrt1_4 is the only one available (even on community repos). There are also MANY other unfulfilled dependencies on this package (and also some that conflict with the 7_110's dependencies).

So I tried symbolic linking again. This time, sudo ln -s /lib64/libavfilter.so.7.110 /lib64/libavfilter.so.7 seems to have worked.

Now, the problem is libavcodec.so.58. As expected, the installed one is more recent (58_134) and installing 58 is not possible because of a dependency hell. However, symbolic linking on this case is also not possible:

Unable to load driver alvr_server from /home/luana/Applications/alvr_server_linux/lib64/alvr/bin/linux64/driver_alvr_server.so (libavcodec.so.58: wrong ELF class: ELFCLASS32)

So appaently the dependency hell for libavcodec was smaller, so I was able to install it without its only unsatisfied dependency libaom.so.2()(64bit).

And now the problem was ANOTHER library: libswscale.so.5. As always 5_9 was already installed, but this time I was able to instal 5 alongside it with no problems (thank God!)

And now, once again, another library: libvpx.so.6 ... This one was indeed not installed, only 7 was, so I was able to install it from a community repo. HOWEVER: It errors.

Unable to load driver alvr_server from /home/luana/Applications/alvr_server_linux/lib64/alvr/bin/linux64/driver_alvr_server.so (libvpx.so.6: wrong ELF class: ELFCLASS32)

(damn, I hope my system still boots next time I reboot after this many libraries stuff)

(It did boot, but since nothing was fixed anyway I restored a snapshot so nothing gets broken)

So, basically, ALVR is expecting older versions of many libraries that are not installable. All of this while the older nightlys still work (maybe they use even older versions that are still installed?). On the first few I was able to find fixes, but not for all of them (and who knows how many more would pop up if I kept going?). Any way to fix that?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[LuNeder]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

I fucking hate this

[zmerp]

I would like to help you but i'm not very familiar with linux.

[Vixea]

Do you have the driver registered?

[LuNeder]

I would like to help you but i'm not very familiar with linux.

Being familiar with Linux wouldn’t help much. The fix would be ALVR either stop expecting specific versions of the libraries or packaging them together with ALVR if they really need those specific versions.

[Vixea]

Try with ffmpeg being statically linked now using --gpl

[LuNeder]

Try with ffmpeg being statically linked now using --gpl

Hey Thanks for reopening!

I’ll try that as soon as I get back from holidays. I’ve just realized that .appimages are thankfully now available, so I’ll try those too!

Are flatpaks or snaps planned anytime in the future? Those would probably avoid problems like this in the future, and would also come with easy updates and stuff.

[Vixea]

No, flatpaks and snaps will not be supported.

[LuNeder]

Hello! On the latest v20.0.0-dev07+nightly.2023.02.11 tar version the problem persists.

However, the Appimage version works with no problems so I'll use it instead.

Thanks for your help!!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.