The log shows that after startup the RPi is outputting audio to HDMI. But you seem to have a plugin "service.bluetooth-audio" installed which is then switching audio output to pulse. Uninstall that addon and everything should be fine again.
so long,
Hias
US $0.27 9％ Off | IIC I2C Logic Level Converter Bi-Directional Module 5V to 3.3V For Arduino
I got now this one at home. Is this one also fine?
Probably not, but you can give it a try if you already got one.
These converters are mainly useful for slower stuff (ike I2C), to get clean signals for higher speed (SPI) stuff use a 74HCTxx chip.
so long,
Hias
hagaygo thanks for reporting back!
I've had a chat with the RPi devs and the CMA issue is quite an odd thing - in theory the CMA size shouldn't matter at all, but your and our tests showed otherwise. Could be a linux kernel issue or we are missing some subtle thing.
Anyways, using cma=64M (or even cma=48M) should be safe with Kodi 18 (with Kodi 19 probably not). Even 32M could work on a HD (1920x1080) screen, though that's very marginal (checked here with a 1920x1200 screen and it was a tad too low and kodi didn't start).
Other than that: reducing gpu_mem (to 256 or 192 - though that'll probably cause issues when trying to play 4k videos) or adding a bit of swap (256MB or so) should also help on 1GB RPi4 models.
so long,
Hias
Can you try adding cma=128M to the end of /flash/cmdline.txt (with a space between "quiet" and "cma...")? You can also try with cma=64M.
This, in combination with gpu_mem=192 allowed me to view the 60Mpix file on a RPi4 with 1GB total_mem.
Software decode seems to work fine, but it needs quite a lot of memory (I saw kodi jumping up to almost 400MB resident size during image loading (but then it quickly dropped back to saner levels).
so long,
Hias
Can you please provide some sample images that fail with gpu_mem=128? My guess is they'd be larger than 15Mpix and thus require more (temporary) memory during display / thumbnail creation.
I had a quick look at the Kodi code, one difference between RPi4 and RPi0-3 is that RPi4 uses the Kodi default methods (software decode, eGL textures) whereas RPi0-3 use the firmware (OMX) functions and textures. IIRC RPi0-3 are limited to max 2048x2048 textures whereas RPi4 supports 4096x4096 - so these need more system RAM as well.
so long,
Hias
Not really sure, and I also find it a bit puzzling why kodi's picture viewer needs so much RAM. The testfiles were 15Mpix which roughly need 60MB uncompressed (when stored with 32bits per pixel).
I'd recommend setting gpu_mem to 192 or 256 for now, this should work for the majority of video files.
so long,
Hias
I could reproduce the crash with the testfiles on a RPi4 with total_mem=1024 in config.txt Problem is that kodi is running out of memory.
Keep in mind that (GPU) memory allocation on RPi4 is rather different to RPi3:
On RPi4 the gpu_mem is needed for video decoding and the memory needed by the 3D graphics chip is allocated from system memory. The latter can be quite big (check for CmaTotal and CmaFree in /proc/meminfo), with a HD monitor I see about 35MB being used, with a 4k display about 90MB.
It's planned to make memory allocation more dynamic, but that's not finished yet so for now the RPi4 needs more memory than the RPi3.
1GB RAM and 4k output on the RPi4 isn't an ideal combination - for 4k output a 2GB RPi4 is recommended.
so long,
Hias
The reason is quite simple: more often than not the actual error is way before what users think the errors is. eg. video playback may crash if some setup at the very beginning (audio devices, video driver setup etc) went wrong. If users then just post the snipped where eg video playback crashed it's completely useless as it doesn't contain the important information for developers - the context.
Don't worry too much about "private" stuff, passwords etc are usually automatically redacted in kodi logs so no one will know about them. And knowing that your NAS is at 192.168.1.123 won't give anyone access to it either.
If you are worried that your log shows "playing XXX_hardcore_porn_from_torrent_site.mkv" then, well, rename that file to something harmless before.
Anyways, if in doubt do a clean installation (which doesn't contain any possible private info), play files from local harddrives with harmless names, and don't install tons of addons. Then you have nothing to worry about and both you and devs know that it's not one of the odd addons or config settings that's causing your problems.
TL;DR Most important thing to know is that cut down or redacted logs will be simply ignored by devs - so if you want support post full logs. Cutting down or redacting logs is wasted time, no one will look at them.
so long,
Hias
/var (and thus /var/log) are already in RAM so log2ram won't provide any benefit. Also note that by default the systemd journal is only kept in RAM (without being written to /var/log/journal) unless you add "debugging" to the kernel command line - which enables permanent journal logging to /storage.
Kodi's log (/storage/.kodi/temp/kodi.log) will always be written to SD card (though that's not too many writes, unless you enable debug logging in kodi).
so long,
Hias
No, as I wrote in posts 31 and 33 you need one with the Atmega 32U4, like this one Arduino Micro
Refer to Arduino docs for pin assignment.
so long,
Hias
No, go for Atmega 32u4 only - the other ones without built-in USB will be a PITA
Just solder the connector pins to the RPi and then cable up the LED strip as usual (eg with DuPont wires).
so long,
Hias
Arduino sketch is on github ledstream.pde
Depending on which Arduino (clone) you use you may need to modify the source (see comments at the beginning) and some of the smaller/cheaper boards require you to solder in the 0.1" connectors yourself.
Just make sure you get an Arduino with Atmega 32u4 (this is the one with USB built-in, the older/other Arduinos with separate USB/serial chip won't work well as communication will be too slow).
In hypercon / hyperion.config.json set the type to "adalight" and port to "/dev/ttyACM0"
For other details about arduino stuff and the Adalight / ledstream sketch just search the net, there are tons of infos out there.
so long,
Hias
It should work fine (all WS2801 LED strips should behave identically so should work).
so long,
Hias
Can you try disabling the built-in IR receiver? Run the following command and then reboot:
echo "blacklist hid-appleir" > /storage/.config/modprobe.d/disable-appleir.conf
so long,
Hias
I've got a WS2801 strand with 50 LEDs, similar to this one 12mm Diffused Thin Digital RGB LED Pixels (Strand of 25) [WS2801] ID: 322 - $39.95 : Adafruit Industries, Unique & fun DIY electronics and kits
so long,
Hias
Sorry, don't have a picture - the board is tucked behind my wall-mounted TV.
It's just an Arduino Pro Micro clone with the Adalight Ledstream sketch, connected to RPi via USB. There should be plenty of info on the 'net.
so long,
Hias
I'm not using a level-shifter myself, I use a "Adalight" / Arduino to connect the LED strip. The Arduino outputs 5V signals so there's no problem to drive the WS2801 (which require a minimum of 4V for logic high input signals).
The 74HCT00 circuit on the hyperion wiki Supported hardware | Hyperion - Forum looks fine, if you build it yourself don't forget to connect +5V from the RPi to pin 14 and GND to pin 7 of the 74HCT00 - that small detail is missing in the schematic (buit their PCB looks OK).
so long,
Hias
Yes, this is the default behaviour in current RPi4 bootloader firmware. You can change that by editing the bootloader config settings.
On LibreELEC 9.2 Beta 2 (9.1.502) first run the following command to get the default config:
LibreELEC:~ # rpi-eeprom-config --out /tmp/config /lib/firmware/raspberrypi/bootloader/critical/pieeprom-2019-09-10.binThen edit the /tmp/config file and change POWER_OFF_ON_HALT to 1 and WAKE_ON_GPIO to 0.
eg run
LibreELEC:~ # nano /tmp/configthe config should then look like this:
BOOT_UART=0
WAKE_ON_GPIO=0
POWER_OFF_ON_HALT=1
FREEZE_VERSION=0Then create a bootloader firmware file with the changed config and install it
LibreELEC:~ # rpi-eeprom-config /lib/firmware/raspberrypi/bootloader/critical/pieeprom-2019-09-10.bin --config /tmp/config --out /tmp/pieeprom
LibreELEC:~ # rpi-eeprom-update -d -f /tmp/pieepromNow reboot to update the bootloader eeprom.
You can check if the update was successful by running vcgencmd bootloader_version (it should report Sep 10 2019) and vcgencmd bootloader_config (it should print the config from above).
Note: you only have to do this once, subsequent bootloader updates (via the LE settings addon) will keep config in the bootloader eeprom intact.
so long,
Hias