Closed MichaIng closed 4 years ago
first test update on my RPi3B+ is working fine.
Ah btw, to test the new simple zram-swap implementation, as it is not yet visible in any of our menus:
/boot/dietpi/func/dietpi-set_swapfile 1 zram
This will create a zram drive with a size of 50% physical RAM size and use it as swap drive/partition ("1
" = auto size).
/boot/dietpi/func/dietpi-set_swapfile 1024 zram
This will create a zram drive with 1024 MiB size as swap partition. ("2
" and above = size in MiB)
Compression method is lzo by default, compression ratio probably 1.5 - 2 but depends highly on usage. Your statistics are welcome!
The size is the uncompressed zram partition, so 1024 MiB will probably lead to ~600 MiB RAM usage or less. The max memory usage can be controlled as well. For details check the related Linux documentation: https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html
How does it behave if a regular swap file is present? Will test it on my RPi3B+ later the evening. Just need to find the cool stress
command to load the memory π
Edit
ok found it. This will utilise 4 processes, using 30% of phys mem each. Means its's going to force swapping.
stress --vm-bytes $(awk '/MemAvailable/{printf "%d\n", $2 * 0.3;}' < /proc/meminfo)k --vm-keep -m 4 --timeout 60
SWAP
ZRAM
I did not do real performance testing but system response feels way better using ZRAM. At least htop
was not hanging compare to the use of normal swap file. There my RPi3B+ stuck for longer period before refreshing htop
again.
@MichaIng
not sure if this is intended but if I'm on ZRAM and going to call dietpi-set_swapfile
without parameter, it's going to fail.
root@DietPi3:/boot/dietpi/func# ./dietpi-set_swapfile
DietPi-Set_swapfile
βββββββββββββββββββββββββββββββββββββββββββββββββββββ
Mode: Applying /var/swap
[ INFO ] DietPi-Set_swapfile | Disabling and deleting all existing swap files
[ OK ] DietPi-Set_swapfile | swapoff -a
removed '/etc/modules-load.d/dietpi-zram-swap.conf'
removed '/etc/udev/rules.d/98-dietpi-zram-swap.rules'
./dietpi-set_swapfile: line 162: ((: == 1 : syntax error: operand expected (error token is "== 1 ")
./dietpi-set_swapfile: line 179: ((: < 1 : syntax error: operand expected (error token is "< 1 ")
13404
[ OK ] DietPi-Set_swapfile | Generating new swap space
[ INFO ] DietPi-Set_swapfile | Size = MiB
[ INFO ] DietPi-Set_swapfile | Path = /var/swap
[FAILED] DietPi-Set_swapfile | fallocate -l M /var/swap
How does it behave if a regular swap file is present?
It will replace any present swap file. For now only a single swap file/zram is supported.
A combination of in-RAM compressed + additional file based swap is btw served by another different implementation, called zswap
: https://www.kernel.org/doc/html/latest/vm/zswap.html
It by design requires a disk swap space and, based on usage, moves parts of the in-RAM swap to disk and back dynamically. That should always win against any zram + disk swap implementation where any priorities to use one over the other at best can be done by assigning custom fixed priorities. So adding zswap
support would be another nice feature, but first we should add regular swap partition support π.
if I'm on ZRAM and going to call dietpi-set_swapfile without parameter, it's going to fail.
I don't know what I did there, this should fix the issue: https://github.com/MichaIng/DietPi/commit/af83e9d7637a5c76132ba4b2ecc7bd0c73f11723
well done. I switched to dev
branch and it's working now
root@DietPi3:/boot/dietpi/func# ./dietpi-set_swapfile
DietPi-Set_swapfile
βββββββββββββββββββββββββββββββββββββββββββββββββββββ
Mode: Applying 487 /var/swap
[ INFO ] DietPi-Set_swapfile | Disabling and deleting all existing swap files
[ OK ] DietPi-Set_swapfile | swapoff -a
removed '/etc/modules-load.d/dietpi-zram-swap.conf'
removed '/etc/udev/rules.d/98-dietpi-zram-swap.rules'
[ OK ] DietPi-Set_swapfile | Free space check: path=/var/ | available=13404 MiB | required=487 MiB
[ OK ] DietPi-Set_swapfile | Generating new swap space
[ INFO ] DietPi-Set_swapfile | Size = 487 MiB
[ INFO ] DietPi-Set_swapfile | Path = /var/swap
[ OK ] DietPi-Set_swapfile | fallocate -l 487M /var/swap
[ OK ] DietPi-Set_swapfile | mkswap /var/swap
[ OK ] DietPi-Set_swapfile | chmod 600 /var/swap
[ OK ] DietPi-Set_swapfile | swapon /var/swap
[ OK ] DietPi-Set_swapfile | eval echo '/var/swap none swap sw' >> /etc/fstab
[ OK ] DietPi-Set_swapfile | Desired setting in /boot/dietpi.txt was already set: AUTO_SETUP_SWAPFILE_SIZE=487
[ OK ] DietPi-Set_swapfile | Setting in /boot/dietpi.txt adjusted: AUTO_SETUP_SWAPFILE_LOCATION=/var/swap
[ INFO ] DietPi-Set_swapfile | Setting /tmp tmpfs size: 731 MiB
[ OK ] DietPi-Set_swapfile | mount -o remount /tmp
root@DietPi3:/boot/dietpi/func#
Edit: ok the swap file will be created with same size like zram before. Should it be set back to 50% phys mem?
hw accelleration in jellyfin. i cant enable it.
all dev are missing on dietpi, how can i enable it for to work with jellyfin? i got this error when try to transcode with hw enabled Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> h264 (h264_omx)) Stream #0:1 -> #0:1 (dts (dca) -> mp3 (libmp3lame)) Press [q] to stop, [?] for help [h264_omx @ 0x55aa8e8fe0] /opt/vc/lib/libbcm_host.so not found
for reference this is link to jellyfin page about hw acceleration https://jellyfin.org/docs/general/administration/hardware-acceleration.html?q=hw%20acceleration
It looks like your on RPi, right? You followed the respective paragraph? https://jellyfin.org/docs/general/administration/hardware-acceleration.html#raspberry-pi-3-and-4
[h264_omx @ 0x55aa8e8fe0] /opt/vc/lib/libbcm_host.so not found
Does this file exist?
ls -l /opt/vc/lib/libbcm_host.so
yes im on rpi4 64bit, /opt/vc is missing all vc dir is missing dont know if this can help, but when i use raspian-lite and jellyfin docker i have to use this for hw in docker volumes:
in dietpi on rpi, opt/vc is missing and that 2 dev too
Ayayay good find. I read something about the plan to move /opt/vc into the regular /usr/lib /usr/bin etc location and indeed the new RPi 64-bit image already did this.
Here is the package file list:
/usr/lib/aarch64-linux-gnu/libbcm_host.so.0
/usr/lib/aarch64-linux-gnu/libdebug_sym.so.0
/usr/lib/aarch64-linux-gnu/libdtovl.so.0
/usr/lib/aarch64-linux-gnu/libvchiq_arm.so.0
/usr/lib/aarch64-linux-gnu/libvcos.so.0
And for the binaries:
/usr/bin/dtmerge
/usr/bin/dtoverlay
/usr/bin/dtoverlay-post
/usr/bin/dtoverlay-pre
/usr/bin/tvservice
/usr/bin/vcgencmd
/usr/bin/vchiq_test
/usr/bin/vcmailbox
/usr/bin/dtparam
You could reinstall the package from the repo which should restore the old location but going backwards is probably not the best idea and instead we should report this new location to Jellyfin devs and you can symlink the library for now:
mkdir -p /opt/vc/lib/
ln -s /usr/lib/aarch64-linux-gnu/libbcm_host.so.0 /opt/vc/lib/libbcm_host.so
If further libraries or binaries are expected at the old location, link them as well.
Note that this comes from the RPi foundation 64-bit beta image, so it represents the plan their aiming in near future: https://downloads.raspberrypi.org/raspios_arm64/images/ https://downloads.raspberrypi.org/raspios_lite_arm64/images/
Lets move with this topic over to the RPi 64-bit thread, since this is not really a DietPi beta topic: https://github.com/MichaIng/DietPi/issues/3570#issuecomment-682204377
Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> h264 (h264_omx)) Stream #0:1 -> #0:1 (dts (dca) -> mp3 (libmp3lame)) Press [q] to stop, [?] for help [h264_omx @ 0x5585377fe0] /opt/vc/lib/libopenmaxil.so not found
its a problem if i symlink all /usr/lib/aarch64-linux-gnu/ dir?
its a problem if i symlink all /usr/lib/aarch64-linux-gnu/ dir? how can i do it?
Actually you could do that. But now I see that libopenmaxil.so
is missing completely. Either they simply did not add all features yet or restructured the firmware completely. Looks like you need to revert to the repo package:
rm -R /opt/vc
apt update
apt install --reinstall libraspberrypi0 libraspberrypi-bin
Lets see if that works all fine with the installed kernel.
/opt/vc continue to be missing with that reinstall libopenmaxil.so too
What the hack. So first of all, armhf
packages can be installed, right?
dpkg --print-foreign-architectures
And which package version is about to be pulled?
apt policy libraspberrypi0
root@DietPi:~# dpkg --print-foreign-architectures
armhf
root@DietPi:~# apt policy libraspberrypi0
libraspberrypi0:
Installed: 2+git20200813~095940+f73fca0-1
Candidate: 2+git20200813~095940+f73fca0-1
Version table:
*** 2+git20200813~095940+f73fca0-1 500
500 https://archive.raspberrypi.org/debian buster/main arm64 Packages
100 /var/lib/dpkg/status
Hmm the reinstall seems to be skipped automatically then in favour of the more recent installed version. Lets do it manually:
cd /tmp
wget http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/libraspberrypi0_1.20200819-1_armhf.deb
wget http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/libraspberrypi-bin_1.20200819-1_armhf.deb
dpkg -i ./libraspberrypi0_1.20200819-1_armhf.deb ./libraspberrypi-bin_1.20200819-1_armhf.deb
rm ./libraspberrypi0_1.20200819-1_armhf.deb ./libraspberrypi-bin_1.20200819-1_armhf.deb
root@DietPi:/tmp# dpkg -i ./libraspberrypi0_1.20200819-1_armhf.deb ./libraspberrypi-bin_1.20200819-1_armhf.deb
(Reading database ... 34035 files and directories currently installed.)
Preparing to unpack .../libraspberrypi0_1.20200819-1_armhf.deb ...
Unpacking libraspberrypi0:armhf (1.20200819-1) over (1.20200819-1) ...
Preparing to unpack .../libraspberrypi-bin_1.20200819-1_armhf.deb ...
Unpacking libraspberrypi-bin:armhf (1.20200819-1) over (1.20200819-1) ...
dpkg: dependency problems prevent configuration of libraspberrypi0:armhf:
libraspberrypi0:armhf depends on raspberrypi-bootloader (= 1.20200819-1).
dpkg: error processing package libraspberrypi0:armhf (--install):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of libraspberrypi-bin:armhf:
libraspberrypi-bin:armhf depends on libraspberrypi0 (= 1.20200819-1); however:
Package libraspberrypi0:armhf is not configured yet.
dpkg: error processing package libraspberrypi-bin:armhf (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
libraspberrypi0:armhf
libraspberrypi-bin:armhf
Okay dpkg is not able to see that both packages are about the be installed together π, then:
apt install ./libraspberrypi0_1.20200819-1_armhf.deb ./libraspberrypi-bin_1.20200819-1_armhf.deb
I hope like that it's not again ignored because of the newer installed version. Else you need to remove them first, what I actually wanted to avoid:
apt remove libraspberrypi-bin libraspberrypi0
Ah not the only issue, also the bootloader needs to be downgraded then. Hmm, apt should do that automatically, but I'm not sure how well downgrades work with the bootloader. I hope its okay if you need to reflash the image, in case anything fails, then at best the stable 32-bit image with proper firmware packages installed?
ok, with last 2 commands, i have /opt/vc/lib with files.. now ill test if all is working
root@DietPi:/tmp# apt install ./libraspberrypi0_1.20200819-1_armhf.deb ./libraspberrypi-bin_1.20200819-1_armhf.deb
Stream mapping:
Stream #0:0 -> #0:0 (h264 (native) -> h264 (h264_omx))
Stream #0:1 -> #0:1 (dts (dca) -> mp3 (libmp3lame))
Press [q] to stop, [?] for help
[h264_omx @ 0x55c687cfe0] /opt/vc/lib/libbcm_host.so not found
root@DietPi:~# ls -l /opt/vc/lib/libbcm_host.so
-rw-r--r-- 1 root root 110992 Jul 20 07:51 /opt/vc/lib/libbcm_host.so
i think its better to install dietpi 32bit stable :)
i think its better to install dietpi 32bit stable :)
Well, DietPi is not the problem. It's the Raspberry OS 64bit BETA. Seems it's still missing some features. That's why it is a BETA π
sorry, im here again. installed a fresh 32bit 6.32 beta dietpi on rpi4, install jellyfin, enabled all hw options in jellyfin and... dont work. this time log dont say more. no errors ,nothing. a simple error from jellyfin: media is not supported. from this guide: https://www.reddit.com/r/jellyfin/comments/ei6ew6/rpi4_hardware_acceleration_guide/ i exec this:
root@DietPi:~# sudo usermod -aG video jellyfin
root@DietPi:~# sudo systemctl restart jellyfin
root@DietPi:~# ls -l /dev/dri
ls: cannot access '/dev/dri': No such file or directory
root@DietPi:~# for codec in H264 MPG2 WVC1 MPG4 MJPG WMV9 HEVC ; do echo -e "$codec:\t$(vcgencmd codec_enabled $codec)" ; done
H264: H264=disabled
MPG2: MPG2=disabled
WVC1: WVC1=disabled
MPG4: MPG4=disabled
MJPG: MJPG=disabled
WMV9: WMV9=disabled
HEVC: HEVC=disabled
ok found it, need to change in config.txt:
#-------GPU memory splits-------
#gpu_mem_256=16
#gpu_mem_512=16
#gpu_mem_1024=16
gpu_mem=320
root@DietPi:~# for codec in H264 MPG2 WVC1 MPG4 MJPG WMV9 HEVC ; do echo -e "$codec:\t$(vcgencmd codec_enabled $codec)" ; done
H264: H264=enabled
MPG2: MPG2=disabled
WVC1: WVC1=disabled
MPG4: MPG4=disabled
MJPG: MJPG=enabled
WMV9: WMV9=disabled
HEVC: HEVC=disabled
Yes, you can do this in dietpi-config
> Performance Options (or was is Display Options?) as well. At least 32 MiB are required to enable basic GPU features, 64 MiB is RPi default, more required based on what you're doing with it.
EDIT: I'll add increasing the memory split to the Jellyfin install code. @frezeen did you find some resource that 320 MiB is recommended? 32 MiB should enable the GPU features already but not sure if/how much transcoding/decoding benefits from additional GPU memory.
Strange that on the 64-bit image you still got /opt/vc/lib/libbcm_host.so not found
even that it was there π€. Probably also the new kernel does not support the old libraries anymore, just the "not found" looks wrong.
Btw, as I didn't test Jellyfin on RPi, does it has something like a hardware acceleration preset for RPi that automatically looks for /opt/vc/lib/libbcm_host.so
or are there any custom switches/options as well? If this path is really hardcoded in Jellyfin, we should report this quickly to them so they can enable support for the 64-bit RPi firmware.
source about mem setting jellyfin official doc: https://jellyfin.org/docs/general/administration/hardware-acceleration.html#raspberry-pi-3-and-4 section 3:
Change the amount of memory allocated to the GPU. The GPU can't handle accelerated decoding and encoding simultaneously.
sudo nano /boot/config.txt
For RPi4, add the line gpu_mem=320 See more Here
For RPi3, add the line gpu_mem=256
You can set any value, but 320 is recommended amount for 4K HEVC.
Verify the split between CPU and GPU memory:
vcgencmd get_mem arm && vcgencmd get_mem gpu
about "link" question: i think its hardcoded, the custom setting only is for ffmpeg bin path
Strange that they recommend more GPU memory on RPi4, since actually RPi4 needs less GPU memory, since more features use the normal system memory, compared to previous RPi models... Ah, probably because they think about going to 4k there.
Okay let me implement that.
EDIT: https://github.com/MichaIng/DietPi/commit/6a5ef9fd5e246509accc9384e8957bd110dbba6a
Access to /dev/dri
should require the user being member of the "render" group.
I opened an issue on Jellyfin repo, more for informational reasons: https://github.com/jellyfin/jellyfin/issues/4023
After update to this beta I got following error on my RPI3 (previously kodi was set to start on boot)
/boot/dietpi/misc/start_kodi: line 36: syntax error near unexpected token `&&'
/boot/dietpi/misc/start_kodi: line 36: ` (( $G_HW_MODEL == 12)) && command -v xcompmgr > /dev/null && killall -w xcompmgr -a & && sleep 2'
Commenting this out, makes that kodi starts properly.
Ah indeed, there is a syntax error. Can you please try to simply remove the line, it should not be required anymore:
sed -i '/xcompmgr/d' /boot/dietpi/misc/start_kodi
/boot/dietpi/misc/start_kodi
I think the aim was to assure limited window composition (desktop element shadow, transparency and such) via -a
option to enhance Kodi performance. However we start this composition manager with the limiting -a
option by default now on all desktops (but Xfce, because it has its own conflicting builtin composition manager). And since on LXDE there is no composition enabled by default, even better should be to simply disable/remove xcompmgr
:
rm /etc/xdg/autostart/xcompmgr.desktop
apt purge xcompmgr
Can you please try if that has any negative impact on Kodi performance?
Ah, this workaround is for Odroid C2 only, which is already a bid strange since either it affects all systems or none π.
Okay I simplified and optimised the script even more, could you please try this:
curl -s https://raw.githubusercontent.com/MichaIng/DietPi/dev/dietpi/misc/start_kodi > /boot/dietpi/misc/start_kodi
/boot/dietpi/misc/start_kodi
Release has been done. Many thanks to all testers!! I mark this as closed.
Related/solved issues: https://github.com/MichaIng/DietPi/issues?q=is%3Aissue+milestone%3Av6.32