Posts by popcornmix

Quote from CandyLuv

LibreELEC:~ # grep gpu_mem /flash/config.txt
gpu_mem=128
# SDRAM size based GPU memory split, uncomment and setup to override 'gpu_mem'
gpu_mem_256=112
gpu_mem_512=160
gpu_mem_1024=256
gpu_mem=320
LibreELEC:~ #

Display More

The gpu_mem_xxx options have precedence over gpu_mem, so your 320 setting will be ignored.
However you should get 256M on a Pi2/Pi3 (which has 1024M total) and 160M on Pi1 (with 512M total).
Are you using a Pi1, Pi2 or Pi3?

I'd suggest you comment out (insert a # at the start of line) the gpu_mem_256, gpu_mem_512 gpu_mem_1024 lines, and just insert "gpu_mem=256" at the end of the file.
You can run (after rebooting):
vcgencmd get_mem arm
vcgencmd get_mem gpu

to confirm the setting has worked.

Quote from fTdOmen

There's a lot of variation in how far you can overclock a Pi3, I've got one that can operate at 1550mhz with no problems and another that I can't get past 1330. Start with small steps

Really? I've tested many Pi3's and not found one that's reliable at 1500MHz.
I've got one that's *almost* reliable at 1450MHz, but I have backed off a little as I got very occasional crashes.

You might want to confirm with "vcgencmd measure_clock arm" as I think there may be a hard limit of 1500MHz from the arm's clock.

Quote from CandyLuv

That is strange because "gpu_mem=320" is what I have it as in my configuration file and I just checked it to confirm.
*I fail to mention that sometimes freezing occurs and movie thumpnails etc also have problems showing up.

ssh in to pi and report output of:

grep gpu_mem /flash/config.txt

07:11:37   9.585470 T:1962696704  NOTICE: ARM mem: 848MB GPU mem: 160MB MPG2:0 WVC1:0

Your gpu_mem is 160, which is less than the default of 256M (on Pi2/Pi3). Why is that?
That, coupled with using a heavy skin is probably the cause of the issues - running out of GPU mem and so unable to display textures.

Set it back to 256M. If that is not enough you may want to try 320M or more.

Quote from jogger

TV tested with TVheadend: RPi will not easily switch channels from SD to HD. Need to start a movie in between. All other directions work.

Is the SD channel MPEG-2 (without a codec licence) and the HD channel H.264?
There is a known issue with switching between hardware and software codecs without stopping. It has been fixed in Krypton:
VideoPlayerVideo: Need to clear pictures before switching decoder by popcornmix · Pull Request #9861 · xbmc/xbmc · GitHub
mmal_renderer: Use shared pointers to maintain the pool until the decoder has been destroyed by popcornmix · Pull Request #9975 · xbmc/xbmc · GitHub

I'd be interested if you have the problem in a Milhouse nightly build.

That appears when you press a number on the keyboard (it allows entering an explicit seek time).

So something is sending button presses. What do you have connected to Pi? How are you controlling it?

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.