Posts by HiassofT

You'll have to create a button mapping for the video playlist window (should be "VideoPlayList") as well and eg map "blue" to "ContextMenu".

Otherwise the default (global) mapping is used, which is usually the PVR functions for color buttons.

If in doubt enable debug logging in kodi and check kodi log for "Window Init" messages - this will tell you which window is currently being used. The https://kodi.wiki/view/window_ids wiki page lists the window names (which you have to use in keymap xml files) and window xml files - eg if you see "MyPlaylist.xml" in kodi.log you'll have to use "videoplaylist" in keymap.

The kodi log will also show you the button press and the performed action.

so long,

Hias

yes

Ah, just noticed you wrote in your first post that you want the functionality of the "c" key. The default keyboard keymap shows that "c" is mapped to "Playlist" in FullscreenVideo - so use that.

eg

<keymap>
  <FullscreenVideo>
    <remote>
      <blue>Playlist</blue>
    </remote>
  </FullscreenVideo>
</keymap>

so long,

Hias

Instead of global use FullscreenVideo (or FullscreenLiveTV etc) - see the list of window names here Keymap - Official Kodi Wiki

Mappings in "global" are the global defaults and window specific mappings can override the global ones.

eg in kodi defaults both the menu and title button are mapped to ContextMenu, but in FullscreenVideo menu is mapped to OSD and title to PlayerProcessInfo - see hee xbmc/remote.xml at master · xbmc/xbmc · GitHub

so long,

Hias

Forgot to add: if you don't want to wait you can also do a manual update (see samba/cli sections here Update LibreELEC [LibreELEC.wiki]) using the 9.2 Beta 2 image libreelec-rpi4.arm-9.1.502.img.gz

so long,

Hias

Quote from fatshotty

thanks for the explanation.
I wonder: in kodi log file I saw "9.1.901" , so I think it is newer than 9.1.502, isn't it?
moreover, No update found so far and yes, "wait for network" is active

9.1.901 is an internal version number for addons only, which doesn't always strictly correlate to the LibreELEC version number you see eg in system info or on the boot splash screen. In LE 9.2 alpha/beta (9.1.xx versions) we had to set the point version to a very high number to avoid a clash with previously relased addons for master.

Can you check the LE version number in system info? I'd guess it shows 9.1.501 there. Still puzzling why you got that instead of 9.1.502 and why you don't see any updates....

BTW: final 9.2.0 version should be released very soon (unless last-minute issues show up) which should resolve the version issues, too.

so long,

Hias

Hmm, looks like you got some older LE version via noobs install - not quite sure why that happened.

In LE settings you should see there's an update to 9.1.502 available (if not, set automatic updates to "manual", select "LibreELEC-9.2" in the update channel and then go to available versions - there 9.1.502 should show up).

BTW: automatic LE updates and addon update/installation can fail if the network connection takes too long to come up - it's best to enable "Wait for network before starting Kodi" (in LE Settings->Network), this avoids running into these issues.

so long,

Hias

yes - with the exception of the Arduino Uno, which will be slower due to the limited baudrate.

so long,

Hias

If RPi4 plus level shifter works fine then go for it - both Arduino and GPIO connection plus level shifter should work pretty much the same.

The main reason I'm using an Arduino here is because I have an audio card plugged in which needs SPI - so I can't use the GPIO connection method.

so long,

Hias

Quote from CvH

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

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

Quote from harun-cuk17

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

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