Dietpi-config on Buster // Installing rpisurv on Bullseye

Hello DietPi Community,

I’m currently using a Raspberry Pi to run rpisurv, a surveillance software (GitHub - SvenVD/rpisurv: Raspberry Pi surveillance). However, I’ve encountered an issue with VLC when using Raspberry Pi OS 11 “Bullseye” that prevents me from using the Bullseye version of DietPi with rpisurv (VLC issue on raspbian bullseye · Issue #141 · SvenVD/rpisurv · GitHub). After trying various solutions without success, I’ve resolved to stick with Raspberry Pi OS Legacy (Buster).

I would prefer to use DietPi Buster, but I cannot find the image. My favorite feature of DietPi is the dietpi-config script. I was wondering if someone could provide a link to the Buster version of dietpi-config so that I may integrate it into my Raspberry Pi OS Legacy (Buster) installation? I tried using the DietPi script that turns Raspberry Pi OS Buster into DietPi, but during the process, it insisted that I upgrade to Bullseye.

If anyone can help me with this issue or provide guidance on how to obtain the Buster version of dietpi-config, I’d greatly appreciate it.

Thank you in advance!

  • Craig J.

basically, there is no difference for our script. They are the very same on Buster, Bullseye and Bookworm. We just maintain a single version.

That’s great! Thank you for such a prompt reply.

So, if I understand correctly, I can use the latest master version of the dietpi-config script from DietPi/dietpi-config at 195d9b66da39080764cdb05d94cff8ec2d660bf4 · MichaIng/DietPi · GitHub with my Raspberry Pi OS Legacy (Buster) installation without any issues?

It’s intended to be used a standard shell script, right? That’s to say, I don’t need to do anything special with permissions?

well, it is not intended as stand along script. The script load other script like /boot/dietpi/func/dietpi-globals

Understood! dietpi-globals seems to be the only script it imports, so am I right in understanding that so long as I run dietpi-globals prior to dietpi-config, I’d be effectively able to run dietpi-config on Raspberry Pi OS Legacy (Buster)? I see the section for dietpi-services (line 45), but as far as I can tell it isn’t actually referring to any specific unit files.

Thank you for your patience, Joulinar!

I gues @MichaIng could explain in detail what are the challenges of using individual DietPi scripts on plain PRI OS

1 Like

Did you try the rpisurv installer master branch instead of 3.0.0 release? There were some commits regarding VLC which makes it installing VLC from the APT repository now. And the RPi repo provides VLC packages for Buster as well as Bullseye which should work fine.

I’ll give v3.0.0-beta7 a go! I did try v3 beta (beta 6, I think it was) at the time when I last looked into this; I believe it was an issue with the installation script not seeing VLC as the correct version, although when I probed deeper into it the author of rpisurv explained it was something to do with a bug in the newer versions of VLC that was stopping it from rendering the rpisurv streams correctly. I did ask if it was something they’d be willing to look into further and his logic seemed to be focused more on ‘well it works fine with Raspberry Pi OS Buster’!

It still has the same issue with Bullseye, unfortunately.

Relevant portion of the rpisurv install.sh:

Setting up vlc (3.0.18-0+rpt3+deb11u1) …
Processing triggers for udev (247.3-7+deb11u1) …
Processing triggers for libc-bin (2.31-13+rpt2+rpi1+deb11u5) …
Processing triggers for libvlc-bin:arm64 (3.0.18-0+rpt3+deb11u1) …
Your version of vlc does not have the needed mmal options. Rpisurv needs those
Minimum tested vlc version for Rpisurv is (VLC media player 3.0.11 Vetinari (revision 3.0.11-0-gdc0c5ced72)
Aborting installation, upgrade to latest vlc player with mmal support

Once configured, this raspberry pi can be used on a closed network with no internet access, so security isn’t much of a concern to me. Is it possible to get a copy of the DietPi (RPi-ARMv8) Buster image? Or would it insist on updating to Bullseye as part of its various first run update scripts? I ran DietPi Buster previously for this, and it worked flawlessly.

Only after updating to Bullseye did I have issues; rpisurv would immediately go to a black screen when launched, so I tried a reinstall (and in my ignorance, didn’t think to retain my DietPi Buster image) and it all went downhill from there.

Officially we don’t have Buster images anymore. However I have a private copy of that image. And no, we don’t do Destro upgrades as part of first run. System will stay on Buster.

That’s very encouraging to hear! Would I be able to have a copy of that Buster image? I’m happy to keep it to myself, if distribution of the image is a concern.

Well, we don’t like to offer Buster images officially as this is oldstable Debian version and will become oldoldstable this summer. From our point of view, we like to keep our users on an up-to-date software version. Mainly due to security :slight_smile:

I understand, I figured that would be the case, especially if they are using their Raspberry Pi in a situation that would expose them to the internet at large! Thank you both so much for your time.

I see that you used the ARMv8/64-bit image, which is known to not support MMAL at all. Try the ARMv7/32-bit image.

Also, I really meant the “master” branch with latest commit from 2022-07-25, not any v3 beta (which are even older than the v3.0.0 release). So just clone the repo as is (no specific tag/release/branch) and start the installer right away.

Thank you for looking into this! :slight_smile:

I can’t seem to find a download for ARMv7, although I do now have access to the ARMv6 image of Buster; are you referring to a 32bit variant of Bullseye? Or suggesting I use the 32bit variant of Buster?

Edit: Oh, you literally did mean ARMv7! I wasn’t even aware there was such a thing; for some reason I thought it was ARMv6 for 32bit and ARMv8 for 64bit! I’ve been doing some further research into this and think I might even be able to get this work on Bookworm. I’m experimenting as we speak!

Edit 2: Alas, it seems the oldest version of VLC I can get for Bookworm (Or Bullseye) is 3.0.18, and the most recent version that rpisurv will allow me to use is 3.0.17.4, which I can’t seem to get for anything newer than Buster. Currently trying to build my own version using VideoLAN / VLC · GitLab - I’m not hopeful, but it’s worth a shot!

Edit 3: No joy! Running Master on ARMv6 Buster and it’s happy enough. Since the Raspberry Pi is only ever going to be used for this purpose, I don’t mind the security risks of using outdated hardware. I’m satisfied I’ve done as much as I can within my realm of expertise, however, although I do wish I could do more to help solve the issue.

Thank you for clarifying the master branch, for some reason I had it in my head that the beta releases were newer!

Ah right, we renamed them, it’s the Raspberry Pi 2 PCB v1.1 image. In the subtitle you see “ARMv7” indicating the userland/OS architecture. Compared to the ARMv6 (Raspberry Pi 1/Zero) image it does not use the Raspbian repository but regular Debian armhf, which has quite a lot of benefits.

Here is the relevant part of the script: rpisurv/install.sh at d2e1e54133f86d4c26a8bb049ae17def9deaf7db · SvenVD/rpisurv · GitHub
As you can see it does not check the version in particular but whether vlc -H (the CLI help output) shows a --mmal-layer option, indicating MMAL support. If this is not true, it prints the error about max version being 3.0.17.4. And VLC 3.0.18 from the RPi repo does support it, so it should work:

root@DietPi:~# sudo -u dietpi vlc -H | grep mmal
VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
Warning: using insecure memory!
 mmal_vout (mmal_vout)
      --mmal-layer <integer>     VideoCore layer where the video is displayed.
      --mmal-adjust-refreshrate, --no-mmal-adjust-refreshrate
      --mmal-native-interlaced, --no-mmal-native-interlaced
      --mmal-display <string>    Output device for Rpi fullscreen.
      --mmal-vout-transform <string>
      --mmal-vout-window <string>
      --mmal-vout-transparent, --no-mmal-vout-transparent
 MMAL-based decoder plugin for Raspberry Pi (mmal_codec)
      --mmal-opaque, --no-mmal-opaque
      --mmal-decode-enable, --no-mmal-decode-enable
                                 Enable mmal decode even if normally disabled
          Enable mmal decode even if normally disabled. MMAL decode is normally
      --mmal-resize, --no-mmal-resize
                                 Use mmal resizer rather than hvs.
          Use mmal resizer rather than isp. This uses less gpu memory than the
      --mmal-isp, --no-mmal-isp  Use mmal isp rather than hvs.
          Use mmal isp rather than hvs. This may be faster but has no blend.
 MMAL-based deinterlace filter plugin (mmal_deinterlace)
      --mmal-deinterlace-no-qpu, --no-mmal-deinterlace-no-qpu
      --mmal-deinterlace-adv, --no-mmal-deinterlace-adv
      --mmal-deinterlace-fast, --no-mmal-deinterlace-fast
      --mmal-deinterlace-none, --no-mmal-deinterlace-none
      --mmal-deinterlace-half-rate, --no-mmal-deinterlace-half-rate
      --mmal-deinterlace-full-rate, --no-mmal-deinterlace-full-rate
      --glconv {any,drm_gl_conv,mmal_converter,none}
      --glconv {any,drm_gl_conv,mmal_converter,none}
  -V, --vout {any,mmal_xsplitter,gles2,gl,xcb_xv,wl_shm,xcb_x11,fb,drm_vout,mmal_vout,caca,flaschen,yuv,vmem,aa,vdummy,vdummy,omxil_vout,none}

The installation went well here:

root@DietPi:~# curl -LO https://github.com/SvenVD/rpisurv/archive/refs/heads/master.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 10.5M    0 10.5M    0     0  4208k      0 --:--:--  0:00:02 --:--:-- 7049k
root@DietPi:~# tar xf master.tar.gz
root@DietPi:~# cd rpisurv-master/
root@DietPi:~/rpisurv-master# ./install.sh
Use this installer on your own risk. Make sure this host does not contain important data and is replacable
This installer will disable graphical login on your pi, please revert with the raspi-config command if needed.

The following version will be installed: "3.0.0"

Do you want to continue press <Enter>, <Ctrl-C> to cancel

Hit:1 http://raspbian.raspberrypi.org/raspbian bullseye InRelease
Hit:2 https://archive.raspberrypi.org/debian bullseye InRelease
Reading package lists... Done
...

Do you want me to (re-)start rpisurv after install?
Type yes/no
yes
sending incremental file list
./
__init__.py
...

sent 11,397,428 bytes  received 565 bytes  4,559,197.20 bytes/sec
total size is 11,392,808  speedup is 1.00
sed: can't read /etc/rc.local: No such file or directory
'rpisurv' -> '/usr/bin/rpisurv'
'rpisurv.service' -> '/etc/systemd/system/rpisurv.service'
Created symlink /etc/systemd/system/multi-user.target.wants/rpisurv.service → /etc/systemd/system/rpisurv.service.
root@DietPi:~/rpisurv-master#

This was on Bullseye. On Bookworm, Debian provides a newer VLC 3.0.18-2, but only the (older) 3.0.18-0 one from the RPi repo supports MMAL. So APT pinning would be needed to assure that all VLC packages are only installed from archive.raspberrypi.org.

1 Like

What a wonderful reply! Thank you so much for taking the time to look further into this; I’m still fairly new to Linux, so your post prompted a morning of searching terms to better understand it!

I now have a better understanding of userland, APT pinning (I had come across this before, but didn’t understand the reasoning for it), and the existence - and purpose - of ABIs; in particular, I’m very interested in seeing if armhf makes a notable difference in performance when switching rpisurv streams, which is already notably better on DietPi than it is on the equivalent Raspberry Pi OS release.

I’m eager to try this method as soon as I get an opportunity, and although it seems obvious enough that this is going to work, I’d still likely do a follow-up to confirm such! Thanks again! :blush:

Your method worked to install rpisurv, although it doesn’t seem to work, unfortunately. Running the script per the instructions on rpisurv’s readme.md doesn’t, and I’m unsure why.

rpisurv appears to run correctly at first, and then falls over when trying to actually connect to the video streams:

root@EOD-Office:~/rpisurv/rpisurv-master# systemctl status rpisurv
● rpisurv.service - Rpisurv Raspberry Pi Surveillance
     Loaded: loaded (/etc/systemd/system/rpisurv.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2023-04-18 22:06:11 BST; 35s ago
   Main PID: 21764 (rpisurv)
      Tasks: 37 (limit: 1069)
        CPU: 1min 5.978s
     CGroup: /system.slice/rpisurv.service
             ├─21764 /bin/bash /usr/bin/rpisurv
             ├─21765 python3 surveillance.py
             ├─21776 python3 surveillance.py
             ├─21777 /usr/bin/vlc -I dummy --aspect-ratio=1920:1080 --vout mmal_vout --network-caching 500 --no-video-title-show --mmal-display=hdmi-1 --input-timeshift-granularity=0 --repeat --mmal-vout-transparent --mmal-vout-window 1920x1080+0+0 --mmal-layer 1999999997 --rtsp-tcp --no-audio rtsp://10.0.0.4:7447/PAzOtxNWP3ozsCQd
             ├─21788 python3 surveillance.py
             ├─21795 /usr/bin/vlc -I dummy --aspect-ratio=1920:1080 --vout mmal_vout --network-caching 500 --no-video-title-show --mmal-display=hdmi-1 --input-timeshift-granularity=0 --repeat --mmal-vout-transparent --mmal-vout-window 1920x1080+0+0 --mmal-layer 2000000000 --rtsp-tcp --no-audio rtsp://10.0.0.4:7447/VzzRQdm8f3WchoQV
             ├─21816 python3 surveillance.py
             └─21819 /usr/bin/vlc -I dummy --aspect-ratio=620:340 --vout mmal_vout --network-caching 500 --no-video-title-show --mmal-display=hdmi-1 --input-timeshift-granularity=0 --repeat --mmal-vout-transparent --mmal-vout-window 620x340+1280+720 --mmal-layer 2000000001 --rtsp-tcp --no-audio rtsp://10.0.0.4:7447/eJFYKCFo9b89kGad

Apr 18 22:06:46 EOD-Office rpisurv[21777]: [h264 @ 0xf5b5b3e0] no frame!
Apr 18 22:06:46 EOD-Office rpisurv[21795]: error: XDG_RUNTIME_DIR not set in the environment.
Apr 18 22:06:46 EOD-Office rpisurv[21795]: error: XDG_RUNTIME_DIR not set in the environment.
Apr 18 22:06:46 EOD-Office rpisurv[21795]: [f5f00d98] mmal_vout vout display error: VCSM init fail
Apr 18 22:06:46 EOD-Office rpisurv[21795]: [f6847430] main video output error: video output creation failed
Apr 18 22:06:46 EOD-Office rpisurv[21795]: [f611b928] main decoder error: failed to create video output
Apr 18 22:06:46 EOD-Office rpisurv[21795]: [h264 @ 0xf6030be0] get_buffer() failed
Apr 18 22:06:46 EOD-Office rpisurv[21795]: [h264 @ 0xf6030be0] thread_get_buffer() failed
Apr 18 22:06:46 EOD-Office rpisurv[21795]: [h264 @ 0xf6030be0] decode_slice_header error
Apr 18 22:06:46 EOD-Office rpisurv[21795]: [h264 @ 0xf6030be0] no frame!

As I understand it, this is an error related to VLC and the VCSM library, so I confirmed the version of VLC to be 3.0.18. It shouldn’t be running out of memory; I set gpu_mem to 512, as recommended by the author of rpisurv when running multiple streams. I also explicitly set the environment in the rpisurv unit file.

[Unit]
Description=Rpisurv Raspberry Pi Surveillance
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/rpisurv
KillMode=control-group
Restart=on-failure
RestartSec=20
Environment="XDG_RUNTIME_DIR=/run/user/0"

[Install]
WantedBy=multi-user.target

It did not work, and I am now out of ideas! :slight_smile:

root@EOD-Office:~/rpisurv/rpisurv-master# systemctl daemon-reload && systemctl restart rpisurv
root@EOD-Office:~/rpisurv/rpisurv-master# systemctl status rpisurv
● rpisurv.service - Rpisurv Raspberry Pi Surveillance
     Loaded: loaded (/etc/systemd/system/rpisurv.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2023-04-18 22:16:48 BST; 4s ago
   Main PID: 3349 (rpisurv)
      Tasks: 37 (limit: 1069)
        CPU: 7.424s
     CGroup: /system.slice/rpisurv.service
             ├─3349 /bin/bash /usr/bin/rpisurv
             ├─3351 python3 surveillance.py
             ├─3362 python3 surveillance.py
             ├─3363 /usr/bin/vlc -I dummy --aspect-ratio=1920:1080 --vout mmal_vout --network-caching 500 --no-video-title-show --mmal-display=hdmi-1 --input-timeshift-granularity=0 --repeat --mmal-vout-transparent --mmal-vout-window 1920x1080+0+0 --mmal-layer 1999999997 --rtsp-tcp --no-audio rtsp://10.0.0.4:7447/PAzOtxNWP3ozsCQd
             ├─3380 python3 surveillance.py
             ├─3381 /usr/bin/vlc -I dummy --aspect-ratio=1920:1080 --vout mmal_vout --network-caching 500 --no-video-title-show --mmal-display=hdmi-1 --input-timeshift-granularity=0 --repeat --mmal-vout-transparent --mmal-vout-window 1920x1080+0+0 --mmal-layer 2000000000 --rtsp-tcp --no-audio rtsp://10.0.0.4:7447/VzzRQdm8f3WchoQV
             ├─3405 python3 surveillance.py
             └─3408 /usr/bin/vlc -I dummy --aspect-ratio=620:340 --vout mmal_vout --network-caching 500 --no-video-title-show --mmal-display=hdmi-1 --input-timeshift-granularity=0 --repeat --mmal-vout-transparent --mmal-vout-window 620x340+1280+720 --mmal-layer 2000000001 --rtsp-tcp --no-audio rtsp://10.0.0.4:7447/eJFYKCFo9b89kGad

Apr 18 22:16:52 EOD-Office rpisurv[3381]: no frame!
Apr 18 22:16:52 EOD-Office rpisurv[3363]: decode_slice_header error
Apr 18 22:16:52 EOD-Office rpisurv[3363]: [h264 @ 0xf3348520] no frame!
Apr 18 22:16:52 EOD-Office rpisurv[3363]: [f3500da8] mmal_vout vout display error: VCSM init fail
Apr 18 22:16:52 EOD-Office rpisurv[3363]: [ec21b318] main video output error: video output creation failed
Apr 18 22:16:52 EOD-Office rpisurv[3363]: [f43154a8] main decoder error: failed to create video output
Apr 18 22:16:52 EOD-Office rpisurv[3363]: [h264 @ 0xf3347760] get_buffer() failed
Apr 18 22:16:52 EOD-Office rpisurv[3363]: [h264 @ 0xf3347760] thread_get_buffer() failed
Apr 18 22:16:52 EOD-Office rpisurv[3363]: [h264 @ 0xf3347760] decode_slice_header error
Apr 18 22:16:52 EOD-Office rpisurv[3363]: [h264 @ 0xf3347760] no frame!
root@EOD-Office:~/rpisurv/rpisurv-master# 

Did you enable camera support in dietpi-config? Also please verify that you have fake KMS enabled and sufficient GPU memory (96 MiB at least):

grep -E 'dtoverlay=vc4-fkms-v3d|gpu_mem_1024' /boot/config.txt

And a reboot is needed for this to take effect.

Good morning, and thank you for your suggestions!

So rpisurv connects to network streams (rtsp streams, in my case), so camera support isn’t needed in this case. I did actually forget to select vc4-fkms-v3d, however, so have got that set (I did so via dietpi-config and then double checked it had been updated in config.txt). I’ve explicitly set the GPU memory to 512MB, rather than using a split, here’s the parts of my config.txt that I’ve changed manually (plus the fkms element added in by dietpi-config):

# Uncomment to force a console size. By default it will be display's size minus overscan.
framebuffer_width=1920
framebuffer_height=1080

...

#-------GPU memory splits-------
gpu_mem=512

...

dtoverlay=vc4-fkms-v3d

After rebooting, the service status is the same:

root@EOD-Office:~# systemctl status rpisurv
● rpisurv.service - Rpisurv Raspberry Pi Surveillance
     Loaded: loaded (/etc/systemd/system/rpisurv.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2023-04-21 06:27:47 BST; 14s ago
   Main PID: 517 (rpisurv)
      Tasks: 41 (limit: 565)
        CPU: 15.833s
     CGroup: /system.slice/rpisurv.service
             ├─517 /bin/bash /usr/bin/rpisurv
             ├─519 python3 surveillance.py
             ├─534 bin/pngview -b 0 -l 1999999999 -d 2 -x 0 -y 0 images/blackbackground_3840_2160.png
             ├─535 python3 surveillance.py
             ├─536 /usr/bin/vlc -I dummy --aspect-ratio=1920:1080 --vout mmal_vout --network-caching 500 --no-video-title-show --mmal-display=hdmi-1 --input-timeshift-granularity=0 --repeat --mmal-vout-transparent --mmal-vout-window 1920x1080+0+0 --mmal-layer 1999999997 --rtsp-tcp --no-audio rtsp://10.0.0.4:7447/PAzOtxNWP3ozsCQd
             ├─541 python3 surveillance.py
             ├─544 /usr/bin/vlc -I dummy --aspect-ratio=1920:1080 --vout mmal_vout --network-caching 500 --no-video-title-show --mmal-display=hdmi-1 --input-timeshift-granularity=0 --repeat --mmal-vout-transparent --mmal-vout-window 1920x1080+0+0 --mmal-layer 2000000000 --rtsp-tcp --no-audio rtsp://10.0.0.4:7447/VzzRQdm8f3WchoQV
             ├─555 python3 surveillance.py
             └─556 /usr/bin/vlc -I dummy --aspect-ratio=620:340 --vout mmal_vout --network-caching 500 --no-video-title-show --mmal-display=hdmi-1 --input-timeshift-granularity=0 --repeat --mmal-vout-transparent --mmal-vout-window 620x340+1280+720 --mmal-layer 2000000001 --rtsp-tcp --no-audio rtsp://10.0.0.4:7447/eJFYKCFo9b89kGad

Apr 21 06:28:02 EOD-Office rpisurv[544]: thread_get_buffer() failed
Apr 21 06:28:02 EOD-Office rpisurv[536]: thread_get_buffer() failed
Apr 21 06:28:02 EOD-Office rpisurv[536]: [h264 @ 0xf364aef0]
Apr 21 06:28:02 EOD-Office rpisurv[544]: [h264 @ 0xf3745550]
Apr 21 06:28:02 EOD-Office rpisurv[536]: decode_slice_header error
Apr 21 06:28:02 EOD-Office rpisurv[544]: decode_slice_header error
Apr 21 06:28:02 EOD-Office rpisurv[544]: [h264 @ 0xf3745550]
Apr 21 06:28:02 EOD-Office rpisurv[536]: [h264 @ 0xf364aef0]
Apr 21 06:28:02 EOD-Office rpisurv[544]: no frame!
Apr 21 06:28:02 EOD-Office rpisurv[536]: no frame!

My system log is currently the same VCSM init fail error, repeated:

Apr 21 06:28:34 EOD-Office rpisurv[536]: [016072c8] mmal_vout vout display error: VCSM init fail
Apr 21 06:28:34 EOD-Office rpisurv[536]: [ec539800] main video output error: video output creation failed
Apr 21 06:28:34 EOD-Office rpisurv[536]: [f46154a0] main decoder error: failed to create video output
Apr 21 06:28:34 EOD-Office rpisurv[536]: [h264 @ 0xf365d8c0] get_buffer() failed
Apr 21 06:28:34 EOD-Office rpisurv[536]: [h264 @ 0xf365d8c0] thread_get_buffer() failed
Apr 21 06:28:34 EOD-Office rpisurv[536]: [h264 @ 0xf365d8c0] decode_slice_header error
Apr 21 06:28:34 EOD-Office rpisurv[536]: [h264 @ 0xf365d8c0] no frame!

rpisurv is described as ‘self healing’ by the author, in the sense that it will continue to try and restart itself indefinitely if there are any issues with the streams, so it does make sense that the error is being repeated.

The H.264 video codec seems to be having trouble allocating a buffer to store the video frames, although I’m unsure what to do about this, as I do not have a solid understanding of how to diagnose an issue with a decoder library.