Posts by popcornmix

Remove this from advancedsettings.xml:

<gui>
<algorithmdirtyregions>1</algorithmdirtyregions>
<nofliptimeout>0</nofliptimeout>
</gui>

That's not supported on any GL ES platforms.

Quote from JimmySmith

I have a few years back Rpi1, and as far as I remember, I think that it was capable to play 720p x264 content from USB disc quite without problem - after buying VC-1 license.

Just to clarify no licence is required for playing H.264 (the codec used by the x264 encoder).
You may need the VC-1 licence for playing VC-1 files (not widely used, but most commonly found on some BluRay disks).

Pi 1 will be fine for 720p H.264. You shouldn't have a problem with 1080p files either (as long as network is good).
Obviously a Pi 2 or Pi 3 will give a more resposive experience as the processors are significantly faster.

You don't have debug enabled in your log.

17:19:40  32.954910 T:1962405888  NOTICE: ActiveAE DSP - starting

Looks like you have enabled ADSP - that is known not to work on ARM platforms, so make sure it's disabled.

Quote from nickrob84

Is there a standard safe oveclock for an RPI3 running LE for general use? Or is it even worth it in the first place? Sorry for hijacking your thead.

No. It's an overclock. If you want safety then leave it as stock.

On Pi3 (or even Pi2) an overclock is hardly essential. A Pi1 has a lot more reason for overclocking.
Some users like to get get every last drop of performance out, but that requires some experimentation.

debug log?

Quote from nickrob84

How flexible are the RP's in terms of overclocking. Obvoiusly in the PC world their are components that are literally made to be clocked but is there any evidence to suiggest that overclocking (sensibly) will damage a Pi?

Overclocking has been widely used since the first Pi four years ago. We've seen no evidence of a Pi ever being damaged.

Sure, too high an overclock may well crash the Pi, and if that crash occurs at an unlucky time, like writing to the sdcard you could get corruption.
But nothing that wouldn't be fixed by reflashing the sdcard.

Ideally back up the sdcard first (e.g. with win32diskimager), or do the tests on a new install that you don't mind reflashing, just in case.
[hr]

Quote from ontap

thanks for that reply ,so when doing this should i leave "force_turbo=0 or changge it to "1" ?

Up to you. force_turbo=1 may make the install marginally faster, but the Pi will run hotter when idle,
and it may set the warranty bit (e.g. if used in conjunction with over_voltage).

Quote from ontap

i have been using a pi3 with openelec previously and have overclocked it as follows.
arm_freq 1000
core_freq 500
adram_freq 500
over_voltage 2
can i coninue to do this with libreelec ?

Display More

Yes, but arm_freq=1000 is an underclock. The default for pi3 is 1200. Perhaps try 1300 if you want to overclock the arm.

Quote from Dalton63841

To fix it, you can ssh in, delete all the *.REC files, and get the overlays folder from the tar update download to scp into the /flash directory. I don't use the touchscreen, but that's how I fixed my botched img install.

Yes, that is correct solution. See LibreELEC for more info.

This should now be fixed with latest 7.0.1. It was actually an issue with how the image was created.
See: mtools: Fix creation of dot directories (. and ..) by MilhouseVH · Pull Request #435 · LibreELEC/LibreELEC.tv · GitHub for the details.

A re-install is the obvious fix, but it should work if you delete the FSCK*.REC files and the overlays file (if it exists) and then do a manual update from the 7.0.1 tar file.

Looks like there is an issue with the current img files on the download page (the tar files are okay) which is causing this.
I'll post when fixed builds are ready.

Can you report output of:

ls /flash
ls /flash/overlays

Try with a Milhouse nightly build:
LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) (pi)
LibreELEC Testbuilds for x86_64 (Kodi 17.0) (x86)

I believe Jarvis doesn't suppot fast channel switching with IPTV, but Krypton does.

Could you confirm if this is still an issue with a Milhouse nightly build?
LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)

The enable option for live tv has gone in Krypton.
If you install and enable a PVR add-on it will be enabled.
If no PVR add-ons are enabled it is disabled.

I imagine this happens with all platforms and all kodi distributions. Perhaps you can test with kodi on another platform?

If it is then it's best reported a feature request on kodi forums.

Make sure you disable "rewind" support - that slows down emulators a lot.

Can you provide a sample file I could have a look at?

Those compile flags are still for a 32-bit target.
Milhouse made a complete LE (may have been OE back then) build with "-mcpu=cortex-a53 -mfpu=neon-fp-armv8"
but was unable to measure any performance improvements.

64-bit kernels do exist for Pi3, but so far have no GPU support (e.g. no hardware video decode) so are not useful for Kodi.
We are waiting for evidence of performance benefits of switching to 64-bit, but so far it's unclear.
Some benchmarks improve, some worsen with 64-bit.