Quest 2 tracks fine, nothing being streamed. Stuck in white void.

[thatpix3l]

trafficstars

Description

On my Oculus Quest 2, ALVR connects fine, tracks fine (at least in SteamVR Home on my monitor), but the screen in the headset is stuck. No video is being streamed to it, just stuck in the white void. In the server logging, I noticed this error: error in encoder thread: Failed to find encoder libx264

General Troubleshooting

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

Environment

Quest 2 ALVR (v18.2.1, Linux portable version)

Hardware

Hardware Probe Link

CPU: Ryzen 7 4800H

GPU: GTX 1660 Ti Mobile

Audio:...Laptop Speakers?

Installation

ALVR Version: 18.2.1 (alvr_server_linux_portable)

SteamVR Version: 1.21.11

Install Type:

• [ ] Packaged (exe, deb, rpm, etc)
• [X] Portable (zip)
• [ ] Source

OS Name and Version (winver on Windows or grep PRETTY_NAME /etc/os-release on most Linux distributions): openSUSE Tumbleweed (All packages updated to latest at time of issue and posting)

[ColdIce1605]

You need to install the x264 dependency.

[Rosentti]

Install libx264. If you have nvidia control panel (Nvidia X Server Settings), go to VDPAU information and check if your gpu supports H264. Also, run steam with your dedicated gpu, as you seem to have integrated graphics. (With prime-run steam).

[thatpix3l]

Before I continue, I should have noted that I am running Steam through Flatpak. Sorry about that.

I have already installed the libx264 package, but I am guessing that Steam, running through Flatpak, is also the one spawning the ALVR server process in it's own runtime that's isloated from my system libraries. Following this logic, I copied the library file, libx264.so.161, to a directory that the flatpak has complete read access to, and created a script-shim with something like this:

#!/bin/sh

LD_LIBRARY_PATH="$HOME/lib64"
export LD_LIBRARY_PATH
/opt/alvr_server_linux_portable/bin/alvr_launcher_bin "$@"

Thinking that SteamVR will open the script itself, and then the alvr binary, but it seems to have no effect. I also tried modifying the SteamVR launch options and added LD_LIBRARY_PATH=$HOME/lib64, where $HOME/lib64 has a copy of the libx264.so.161 library, but after launching, it crashes with this error:

[thatpix3l]

I was finally able to get past the "Stream will begin soon" message by finding and placing all required libraries in my ~/lib64 directory, but now I am stuck in a green screen void. I feel so close to Linux gaming, but I need help to get past this last (I assume) obstacle.

[silveropensource]

I'm having the exact same issue, and possibly due to flatpak steam, not sure though.

[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.

[ColdIce1605]

Could you try native steam not flatpak?

[thatpix3l]

@ColdIce1605 I would really not like to, since normal Steam dumps all its contents all over my filesystem. It also helps that I can simply drag and drop my ~/.var/app/com.valvesoftware.Steam onto a new Linux installation, and have everything work as if on a previous system, which is exactly what I did after nuking my original Tumbleweed install for unrelated reasons...

Also, although not applicable to me since I run Tumbleweed, users of distros like Fedora Silverblue and openSUSE MicroOS with immutable filesystems have an even harder time setting up dependencies for this, having to reboot for each and every update.

I hope that, someday, users like mentioned above will be considered for this project.

[ColdIce1605]

One problem, ALVR cannot work with how flatpaks guarantees security.

[thatpix3l]

At least for this project, what does flatpak specifically do to "guarantee" security? If the answer is file isolation, then technically that would by a non-issue because one could instead modify the RPATH of the executable and portable libraries to point towards a folder containing all other runtime sub-dependencies just for ALVR. In fact, that is exactly what I have done to have ALVR even start inside of Steam's flatpak folder.

[ColdIce1605]

sandboxing. also why don't you just try the solution I'm giving you? Like other the the filesystem being a mess which in my opinion you got more than just steam to worry about.

[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.

[JacekJagosz]

It is still a problem for me. On Native Steam, both with native runtime off and on.

[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.

[JacekJagosz]

It is still a problem for me, unfortunately.

[Vixea]

have you tried nightly releases and not stable as on linux nighties are recommended. @JacekJagosz

[JacekJagosz]

I have been packaging it for Solus from source, because I wanted to include it in its repos too. I tried the nightly many times but stopped trying some time ago, because there hasn't been any update on this issue. Was there any commit that was supposed to fix it?

[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.