Posts by FeFiFoFum

LibreELEC (official): 9.2.0 (RPi2.arm)

LibreElecPi:~ # uname -r

4.19.83

LibreElecPi:~ # ^C

LibreElecPi:~ # cat /etc/os-release

NAME="LibreELEC"

VERSION="9.2.0"

ID="libreelec"

VERSION_ID="9.2"

PRETTY_NAME="LibreELEC (official): 9.2.0"

HOME_URL="https://libreelec.tv"

BUG_REPORT_URL="https://github.com/LibreELEC/LibreELEC.tv"

BUILD_ID="5d0330e6ad834a1cc1debbc6b58b3464d027acb4"

OPENELEC_ARCH="RPi2.arm"

LIBREELEC_ARCH="RPi2.arm"

LIBREELEC_BUILD="official"

LIBREELEC_PROJECT="RPi"

LIBREELEC_DEVICE="RPi2"

LibreElecPi:~ #

Can I just literally pull the SDCard, put it in the 4 and it'll work?

I know at one point in time, a RPi 2 to 3 SD Swap was a NO NO, until a certain patch - and Ithink similar for Pi 3 to 4, but whatabout now? 6 months on with 9.2.0 - will it just boot ok?

What's the value of it? Literally playback of 2 different things to different displays around the house? (Pi 4 might be able to do that at 1080p?)

I think maybe more likely a clone display might be useful?

Quote from chewitt

LE master branch is already on 5.3 and will bump to 5.4 soon .. but not for RPi4 which needs to remain on 4.19 until more V4L2 plumbing has been completed. Kodi is slowly inching towards HDR support. It's already possible to hack something up that works for some SoCs (not RPi4 yet) but we'd rather do it properly at a more measured pace. I'm not expecting to see "proper" HDR support for some time yet.

Appreciate the reply. Do you think 6 / 12 months or even longer?

Sorry, just to clarify, when Linux 5.2 is the base for Libreelec, that's likely when the os will fully support 4k and HDR with the Pi4?

I'm curious so that I know for future reference. (I may consider a Pi4 then)

I'm getting this error despite setting "wait for network" and setting over 90 seconds delay.

I'm not sure why - it otherwise seems fine, but it's strange - anything else it could be ?

Thanks for the reply to this, I think I ended up switching to that beta edition on the front page and it's been behaving.

Quote from @fterlife

I noticed you already pulled in kernel 5.3 in the development, also for the Pi boards, and that you are now even working on kernel 5.4 integration. That's really impressive and quite bleeding edge I might say. Can you shed a light on current performance just so we can get a hint of the future? Thanks a lot for all your hard work.

Also curious about this. Please let us know.

What is the difficult part of managing the other 2 Pi?

I once had a similar situation and I used Kodis MySQL database mode, so I was working within a single database.

You could just have a primary pi, back up to an IMG file and re-burn the other 2, to SDCard once a month.

I don't have a use for this, but assuming you got it working, in a state where it doesn't interfere with LibreElec, this is amazing - well done.

Is there any way to lock max frame rate of the user interface?

I have a Raspberry Pi 3B+ and while it is pretty good, it often seems to be quite fast in the UI, then slow at other times.

Locking it to say a solid 20fps period, may result in the feel being more consistent.

Can this be done?

Quote from milhouse

What is this 100MB of data you are referring to - is it the squashfs image? This is already compressed so using zram to compress it again in RAM would not result in any significant benefit, and would in fact use more CPU to perform multiple rounds of uncompress/compress.

LibreELEC is designed to perform well within the memory constraints of the target device, eg. 1GB RAM on RPi3, which (on everything other than RPi0/RPi1) still leaves sufficient spare RAM to run a few background applications/services, so zram/zswap should not be necessary.

However if users choose to load the system to the point where all the available RAM is in use then that's not really a problem I think is worth solving with zram/zswap - the better solution is to partition your services on to dedicated/appropriate hardware so that LibreELEC as an HTPC client is running optimally (not having RAM/CPU intended for Kodi stolen by other background tasks) or continue using a single device but one with more physical RAM and/or faster CPU (4GB RPi4?)

Adding zram may mean more RAM appears to be available to applications, but it will also consume more CPU so what you gain on the one hand you lose on the other - you may have plenty of RAM available with zram but you may then experience stuttering during video playback as you are now CPU bound.

Planning on using any form of swap is a bad idea, particularly if your swap file is stored on SD card - it will be very slow, with or without zswap. Swap should only be used as a last resort.

There are several zram/zswap posts on the Raspberry Pi forum - this is probably one worth taking note of:

swap in Raspbian: More trouble than it is worth? - Raspberry Pi Forums

zram/zswap is a pretty niche requirement and not likely one that 99.99% of users will need. If you (or anyone else) wanted to test zram/zswap then the best option would be to enable the kernel configuration options and build your own custom/community LibreELEC: Compile [LibreELEC.wiki]

Display More

I am very inexperienced, I thought perhaps it may be useful to 'buy the developers' a few extra MB (50,100, 200?) to work with for room to move. Obviously you guys know your stuff very well. Wasn't sure if you had all heard of the technology at all.

Regardless I have faith, LibreElec has been wonderful on my R.Pi3, it was only a suggestion, thank you all for the hard work.

I would (assume) only un-needed system files / drivers / modules which aren't frequently accessed would dropped into it.

It's worked really well on my little Armbian PC. - none the less you guys know way more than I do!

I would also like to know the answer to this question from the developers?

Does LibreElec make use of this? I just discovered this technology today and I imagine there's at least 100MB (?) of data in memory which could just be compressed and left there?

Any value in it?

Quote from MikeKL

Don't worry you can use .tar or .img.gz to manual update device from existing installed running build to latest beta as mentioned in Update Libreelec section of wiki. Just ensure you have correct .tar or .img.gz file for your specific device, transfer downloaded file into update folder of device (using your chosen method to transfer file to device) then reboot.

So an .img.gz will NOT scrub the entire disk, just over -write necessary system files?

EDIT: removed, figured out how to find the .TAR file from within the GUI. (Scared to use .IMG.GZ, might over-write the whole disk, isn't it?)

Does anyone know if Linux 5.1 will have more overhead on the Pi 1,2,3 and may reduce performance? What about 5.2 which is coming soon right?

I can 100% confim this bug to be consistent across at least 3 nightly builds.

I have also updated to the build from Sept 05

libreelec-rpi2.arm-9.80-nightly-20190905-45fa149.tar

This has still not fixed the issue.

What do I need to do, in order to fix this?

What do I need to provide, in order to correctly log the job?

Ok in the interest of being a bit more thorough with my testing.

I have installed LibreElec OVA virtual machine, totally diff computer (x86)

Date and time IS correct.

Brand new install!

Import of Once Upon Hollywood, this time? 19/July/2019?

So I'm confused, shouldn't the "date added" be the date added to my LIBRARY?

EDIT:

Ok it appears the 'date added' library flag is based on the date the file was actually written to disk (total madness, but so be it)

I 'faked' a new movie that's never been in my library before, for testing (Once Upon a Time in Hollywood) by renaming another file.

The movie imported in, today, 04/Sept/2019.

The "Date added" on my database, is apparently "20/July/2019"

Is this a bug in LibreElec? In Kodi? In the OS underneath?

Can someone please try and re-create this with a test Pi?