Posts by HiassofT

    BEWARE, we made an adjustment specific to Slice that was done blindly without any actual testing. So pls do a backup before, this should work but we can't test it before.

    More specifically the changes affects the built-in RTC [le92] Slice/Slice3: use upstream method to set xtal load capacitance by HiassofT · Pull Request #4015 · LibreELEC/LibreELEC.tv · GitHub

    Even if I didn't get the change right it shouldn't result in major issues but better keep an eye on the RTC and report back if something's off there (will probably only be noticable if the Slice isn't connected to a network, otherwise time is synced with NTP).

    so long,

    Hias

    Sorry, I somehow missed that you already got an Arduino Uno at home.

    In that case just give it a try, just remember that you have to set the baudrate to 115200 which will limit the number of LEDs and the update rate - about 100 LEDs at 25Hz update rate should work though (haven't tested that myself though).

    The ATmega 32u4 based Arduinos don't have that limitation, this is why I generally recommend using them (esp when buying new it doesn't make much sense to spend money on the older Arduinos, like the uno).

    Concerning the level shifter: without knowing specific details about the used level shifter it's hard to tell if it'll work or not. Most of the level shifters in the form-factor are passive ones with pull-up resistors and while they may work they are neither recommended nor guaranteed to work for this specific application (unidirectional up-shifting of >= 1MHz signals from 3.3V to 5V).

    As the issues can be very subtle and hard to track down ("mostly" or "sometimes" working etc) I generally advise against using such improper approaches.

    so long,

    Hias

    US $0.27 9% Off | IIC I2C Logic Level Converter Bi-Directional Module 5V to 3.3V For Arduino

    AliExpress - Online Shopping for Popular Electronics, Fashion, Home & Garden, Toys & Sports, Automobiles and More.

    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

    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

    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