Posts by popcornmix

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.

Note:
dtparam=audio=on is not required for kodi usage. It may be needed if you run external apps (e.g. emulators) that require alsa.
audio_pwm_mode=2 is sufficient for kodi.

You can manually update the firmware (http://start.elf/fixup.dat) to get bug fixes that aren't in Jarvis release.
You can use a Milhouse nightly build which does have latest firmware.

To be sure you can add to config.txt:
hdmi_ignore_cec=1

which will mean CEC messages cannot occur. Assuming that is the problem then I can't think of anything LE is doing to cause HDMI devices to switch inputs or power on.

Is the HD channel H.264 and the SD one MPEG-2?
Do you have the MPEG-2 codec licence?

There is a bug on Jarvis where switching between software and hardware decoded codecs doesn't work.
If you get the MPEG-2 codec licence this will be avoided.

You can also switch to a Milhouse nightly build which has a fix for switching between software and hardware codecs.
LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)

Disabling CEC in system/input/peripherals/cec settings should avoid this (but will stop CEC remote control from working).
You may be able to disable some of the options there to avoid it.

I think really we want this libCEC included: use system audio mode request instead of power on to start AVR reliable by gdachs · Pull Request #208 · Pulse-Eight/libcec · GitHub

You would try a Milhouse nightly which does include that - does it work better for you?
LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)

Quote from alexkoch89

And if I convert my ISO in MKV MVC 3D Framepacking? Does it will work on LE 7 ?

Yes. Make sure you name the file suitably (e.g. with 3D.MVC. in filename).

3D ISO support is not in Jarvis build. Try a Milhouse nightly build.
LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)

It certainly can work pretty well. This early review had good success with wireless.

Speeds of about 30Mbit/s should be possible, so not quite raw BluRay rate, but most 1080p reencodes should be possible.

But, it's wifi. It depends very much on the distance to router, what's in between and what neighbours are doing.

Best option is to install iperf, and measure the speed of the wifi link.
Probably interesting to do this both when close to the router and in the normal location, so you can see what is possible with a good signal, and what is possible with the signal you actually have.

Quote from fishxz

meh, i should have read this earlier, because deinterlacing caused this problem.

Could you explain exactly what you did?
Are you saying disabling deinterlace cured the problem?
There are a number of deinterlace modes can you say which work and which don't?

Quote from mhoogenbosch

Oh and btw, the settings came from Intel VAAPI howto with Krypton v17 based on Ubuntu 16.04 server.

Why would you use settings designed for "Intel VAAPI howto with Krypton v17 based on Ubuntu 16.04 server" on a Pi?

We are in control of all the defaults and they will be set to give the best behaviour for the majority or users.
If there were a setting that was universally better, then we would change the default.

As such, don't change default settings without a good reason.

Are you using

<loglevel>1</loglevel>

by default in advancedsettings? That could cause stutters when logging is flushed to sdcard, so should only be enabled when needed.

Also these settings look like they came from another platfor and should be removed.

<gui>                                                <algorithmdirtyregions>3</algorithmdirtyregions>                                                <nofliptimeout>0</nofliptimeout>                                              </gui>                                              <video>                                                <latency>                                                  <delay>50</delay>                                                  <refresh>                                                    <min>23</min>                                                    <max>24</max>                                                    <delay>175</delay>                                                  </refresh>                                                </latency>                                              </video>

However the main issue seems to be playing a 23.97fps video in a 50Hz display mode. That will never look smooth.
Does switching to 720p60 in system/video settings help?
Have you got "adjust display refresh rate to match video" enabled?

You have turned on a debug feature "visualizedirtregions".
See: HOW-TO:Modify dirty regions - Official Kodi Wiki

As you haven't added that to you advancedsettings.xml it was probably turned with a keyboard shortcut.
Try control-shift-R to toggle it off.

Powersave *is* disabled, but in the kernel, so iw isn't aware of it.
You should the message "brcmfmac: power management disabled" in dmesg log.