Internal go-vod doesn't start up, but runs fine externally

[Gnarflord]

Describe the bug This is all running natively on Arch Linux according to the Arch Wiki

If I set the application to use the internal go-vod transcoder I get a warning message: If I try to play any media the log just says "Error, memories, Transcode failed: Transcoder returned 408". I can see the running process:

❯ ps aux | grep go-vod
nextclo+ 4071999  0.0  0.0 714528  5504 ?        Sl   11:12   0:00 /tmp/go-vod-oc7qwkgz9ac3-0.2.4-227538c9 /tmp/go-vod/oc7qwkgz9ac3.json

But no go-vod related folders are created in /tmp! I double-checked if the php directive open-basedir limits the folder access of nextcloud but it looks fine:

open_basedir=/var/lib/nextcloud/data:/var/lib/nextcloud/apps:/tmp:/usr/share/webapps/nextcloud:/etc/webapps/nextcloud:\/dev/urandom:/usr/lib/php-legacy/modules:/var/log/nextcloud:/proc/meminfo:/run/redis:/mnt/datengrab/data/nextcloud

The command to test the render pipeline also works correctly:

❯ sudo -u nextcloud \
        ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi \
        -i 'sample.mp4' -vcodec h264_vaapi \
        output-www-data.mp4
ffmpeg version n6.1.1 Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 13.2.1 (GCC) 20230801
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-frei0r --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libharfbuzz --enable-libiec61883 --enable-libjack --enable-libjxl --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librsvg --enable-librubberband --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpl --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable-shared --enable-vapoursynth --enable-version3 --enable-vulkan
  libavutil      58. 29.100 / 58. 29.100
  libavcodec     60. 31.102 / 60. 31.102
  libavformat    60. 16.100 / 60. 16.100
[...]

The permissions for the render card are set correctly, I've added the user nextcloud to both video and render:

❯ /usr/bin/ls -la /dev/dri
total 0
drwxr-xr-x  3 root root        100 Feb  3 09:53 .
drwxr-xr-x 21 root root       4240 Feb  3 09:53 ..
drwxr-xr-x  2 root root         80 Feb  3 09:53 by-path
crw-rw----  1 root video  226,   1 Feb 15 08:58 card1
crw-rw-rw-  1 root render 226, 128 Feb 15 08:58 renderD128

Now interestingly when I startup go-vod manually as the nextcloud user and setup memories to use an external encoder everything works perfectly:

❯ sudo -u nextcloud /var/lib/nextcloud/apps/memories/bin-ext/go-vod-amd64
2024/02/15 11:11:49 &{Version:0.2.4 Configured:false VersionMonitor:false Bind::47788 FFmpeg:/usr/bin/ffmpeg FFprobe:/usr/bin/ffprobe TempDir:/tmp/go-vod ChunkSize:3 LookBehind:3 GoalBufferMin:1 GoalBufferMax:4 StreamIdleTime:60 ManagerIdleTime:60 QF:0 VAAPI:false VAAPILowPower:false NVENC:false NVENCTemporalAQ:false NVENCScale: UseTranspose:false UseGopSize:false}
2024/02/15 11:11:49 Starting go-vod 0.2.4 on :47788
2024/02/15 11:11:53 &{Version:0.2.4 Configured:true VersionMonitor:false Bind::47788 FFmpeg:/usr/bin/ffmpeg FFprobe:/usr/bin/ffprobe TempDir:/tmp/go-vod ChunkSize:3 LookBehind:3 GoalBufferMin:1 GoalBufferMax:4 StreamIdleTime:60 ManagerIdleTime:60 QF:24 VAAPI:true VAAPILowPower:true NVENC:false NVENCTemporalAQ:false NVENCScale:cuda UseTranspose:false UseGopSize:false}
[...]

I can stream videos without any issues and the appropriate directories are created within /tmp. Why does it matter whether nextcloud or I call the executable?

To Reproduce Install nextcloud according to the arch wiki, setup VAAPI and add the memories app.

Platform:

• OS: Arch Linux 6.6.15-1-lts
• Browser: Firefox
• Memories Version: 6.2.2
• Nextcloud Version: 28.0.2
• PHP Version: 8.1.27-2

[pulsejet]

Why does it matter whether nextcloud or I call the executable?

It shouldn't. If the temp directly doesn't exist though, it is likely a permissions issue somewhere.

I also suggest debugging with HW acceleration disabled

[joshtrichards]

open_basedir=/var/lib/nextcloud/data:/var/lib/nextcloud/apps:/tmp:/usr/share/webapps/nextcloud:/etc/webapps/nextcloud:\/dev/urandom:/usr/lib/php-legacy/modules:/var/log/nextcloud:/proc/meminfo:/run/redis:/mnt/datengrab/data/nextcloud

The "not found" for /dev/dri/renderD128 looks like it's because of your open_basedir settings. The file_exists() check fails in PHP since it's not permitted by your configuration.

https://github.com/pulsejet/memories/blob/1918535783947b1114b7b5d165eceebb0a4b0267/lib/Controller/AdminController.php#L166-L170