Kodi Community Forum
v17 LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Printable Version

Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Linux (https://forum.kodi.tv/forumdisplay.php?fid=52)
---- Thread: v17 LibreELEC Testbuilds for x86_64 (Kodi 17.0) (/showthread.php?tid=269815)



RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Milhouse - 2016-07-31

(2016-07-31, 06:20)sciascia88 Wrote: Alright, when I get more time to test different builds I'll send the logs. The VPN manager does go through the motions and says it is connected to NY, but that IP is my actual IP, not the one it should show from NY. The OpenVPN log says "ERROR: Linux route add command failed: external program exited with error status: 2" four times before completing the sequence, but I have no idea what that even really means and the developer seemed to not have much insight either.

"route add" is a Busybox command. The Busybox package is bumped in build #0721. Start testing builds #0720 and #0721, as it's possible the updated Busybox package has introduced a change of "route add" behaviour. However if both of these builds are working OK then you'll need to work through the more recent builds until you identify the first non-working build. Obviously if both builds are not working, you need to work back through the older builds until you find the first working build.


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - piotrasd - 2016-07-31

(2016-07-31, 00:15)Milhouse Wrote:
(2016-07-30, 23:34)piotrasd Wrote:
(2016-07-30, 20:49)Milhouse Wrote: I'm not aware of any specific problems with keyboards. Keyboards weren't broken by the merge in #0729 (though they did receive some new longpress mappings which haven't been reverted) and a USB keyboard connected to a NUC is working fine with a test build from earlier today.

this same problem with PS3 remote connected over BT.
and i checked IRW and eventinput and system showing presed key OK or ENTER but notthing happen in kodi

And yes keyboard working fine !

Apologies if you've told me this already, but when did the PS3 BT remote last work properly (ie. which build)?
Ok im myself revert changes with long pressed buttons and everything back to normal .. .


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Milhouse - 2016-07-31

(2016-07-31, 05:18)madhits Wrote: Milhouse Would it be possible to add support for Silicone image 680 PATA IDE controller to LibreElec? See here: http://lxr.free-electrons.com/source/drivers/ata/pata_sil680.c#L421

I have been trying to figure it out myself and I am completly unable to compile the kernal to add the support. I am just to damn new to linux to figure out the errors I keep getting.

I hope you can help me, your pretty much my only hope now..

I've pushed PR:583. Unless there are any objections adding support for this controller (it's pretty ancient) then it should merge in a few days. I'll include it in future builds, unless the PR is closed without being merged.


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - tinzarian - 2016-07-31

(2016-07-31, 00:09)Milhouse Wrote: You said your restart problem started with #0420, and provided this crashlog:

(2016-05-10, 22:59)tinzarian Wrote: Edit: Build #0420 is the last one that worked, it's still broken in #0509

There's nothing obvious in build #0420 that would appear to be responsible for changing the restart behaviour (no new kernel, no new drivers etc.). The crash in your crashlog appears to be related to libnfs, but libnfs didn't change in #0420 so I'm not sure why it would start to become an issue (there is a change in #0420 that cleans up some file handling code but it looks fairly benign).

Are you sure this restart problem began with #0420, and that it wasn't just a random/unrelated crash that made you think it starts with #0420, when in fact it's a later build that has the real problem?

No, #420 was the last one that worked right, it started with #423 with the 4.6 kernels.

The nfs-crash was unrelated and not an issue.


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Hitcher - 2016-07-31

This is the only way I can still use my Fire TV remote and long press -

(2016-07-26, 00:31)porkchop999 Wrote: I copied the file /usr/lib/udev/rules.d/98-eventlircd.rules to /storage/.config/udev.rules.d/98-eventlircd.rules and edited it removing the new code

http://pastebin.com/KAVyX7Tr

This allows me to use my custom keyboard.xml with the aftv remote



RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - madhits - 2016-07-31

(2016-07-31, 06:46)Milhouse Wrote:
(2016-07-31, 05:18)madhits Wrote: Milhouse Would it be possible to add support for Silicone image 680 PATA IDE controller to LibreElec? See here: http://lxr.free-electrons.com/source/drivers/ata/pata_sil680.c#L421

I have been trying to figure it out myself and I am completly unable to compile the kernal to add the support. I am just to damn new to linux to figure out the errors I keep getting.

I hope you can help me, your pretty much my only hope now..

I've pushed PR:583. Unless there are any objections adding support for this controller (it's pretty ancient) then it should merge in a few days. I'll include it in future builds, unless the PR is closed without being merged.

Milhouse... Yeah I know its ancient. I am just trying to make use of it (story of stuff), I have a dual boot, or I will have a dual boot system with Libreelec & xpenology now that I have support for this controller. You are AWESOME!


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - deepeye - 2016-07-31

Refere to thread: https://forum.libreelec.tv/thread-991.html
Testbuild: #0730, 30-Jul-2016
kodi.log: http://sprunge.us/OIPj

* Videoplayer issue on playback VC-1 Videocodec with AMD Mobility Radeon HD 5430
* all Matroska-Videos with VC-1 as Videocodec has fragments/shutter on playback, same Video on RPI- and RPI2-Hardware works
* System: Arctic MC001
** https://www.arctic.ac/eu_en/mc001.html
** CPU: Intel® Atom™ CPU D525 @ 1.80GHz
** GPU: AMD Mobility Radeon HD 5430
* File Infos: Matroska File with VC-1 Video-Codec
** Codec-ID: V_MS/VFW/FOURCC
** private Codec-Data, length 74 (FourCC: WVC1, 0x31435657)
* guisettings.xml
<videoplayer>
<adjustrefreshrate default="true">0</adjustrefreshrate>
<autoplaynextitem default="true">false</autoplaynextitem>
<errorinaspect default="true">0</errorinaspect>
<hqscalers default="true">0</hqscalers>
<pauseafterrefreshchange default="true">0</pauseafterrefreshchange>
<preferdefaultflag default="true">true</preferdefaultflag>
<prefervaapirender default="true">true</prefervaapirender>
<quitstereomodeonstop default="true">true</quitstereomodeonstop>
<rendermethod default="true">0</rendermethod>
<stereoscopicplaybackmode default="true">0</stereoscopicplaybackmode>
<stretch43 default="true">0</stretch43>
<useamcodec default="true">true</useamcodec>
<usedisplayasclock default="true">false</usedisplayasclock>
<usedxva2 default="true">true</usedxva2>
<useomx default="true">true</useomx>
<useomxplayer default="true">true</useomxplayer>
<usevaapi default="true">true</usevaapi>
<usevaapimpeg2 default="true">true</usevaapimpeg2>
<usevaapimpeg4 default="true">true</usevaapimpeg4>
<usevaapivc1 default="true">true</usevaapivc1>
<usevda default="true">true</usevda>
<usevdpau default="true">true</usevdpau>
<usevdpaumixer default="true">true</usevdpaumixer>
<usevdpaumpeg2 default="true">true</usevdpaumpeg2>
<usevdpaumpeg4>true</usevdpaumpeg4>
<usevdpauvc1 default="true">true</usevdpauvc1>
<usevideotoolbox default="true">true</usevideotoolbox>
</videoplayer>

Hope, somebody could help. Thx


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - fritsch - 2016-07-31

Quote: Videoplayer issue on playback VC-1 Videocodec with AMD Mobility Radeon HD 5430

Sorry - upstream is not developing (vdpau / acceleration) code for that ancient chip anymore. Just disable VDPAU-VC1 in the settings and hope the CPU can decode it. Alternatively you can go to bugs.freedesktop.org and provide all the logs they would like to have. Therefore it is best to test with a "normal" distribution like Ubuntu 16.04 and also additional player like mpv (using vdpau support) to see if it is a generic issue. VC1 on this chip generation never worked correctly and fluently. I don't think that will ever change.


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Milhouse - 2016-07-31

(2016-07-31, 11:23)tinzarian Wrote: No, #420 was the last one that worked right, it started with #423 with the 4.6 kernels.

The nfs-crash was unrelated and not an issue.

Arghh... I blame it on the late hour. Smile

OK in build #0423 there's a mesa bump and a major kerenl bump, so it looks like a bug in either of those (most likely the kernel). It's hard to say what is causing the problem without clearer logs.

If it's a problem that occurs at shutdown then you could add "debugging" to /flash/EFI/BOOT/syslinux.cfg (UEFI) or /flash/extlinux.conf (legacy BIOS) and that should preserve your system log across reboots. Then trigger the problem, restart the system and upload your journal with "journalctl -a | pastebinit" - it may include a clue as to what is happening (no promises on a fix though).

Edit: Also, just to be clear on the actual problem - you said:
Quote:I have a Zotac Zbox CI520, which was running the #0419 build. After I installed the #0503 something is f'ed up with the power and or IR-settings. After a shutdown it won't power up with the remote, I have to do it manually.
With #0419 were you powering off the box, or putting it into standby? From the #0510 log you sent me, it looks like you're shutting down Kodi (which crashed due to nfs which you say isn't an issue) and thus powering off the box. Whenever I power off my boxes, they don't come back on with a remote control - never have, never will... they only wake from standby.

If you intended to put your box into standby on shutdown, check you still have the "Suspend" option selected as the "Shutdown function" in Kodi Settings > System > Power Saving.


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Milhouse - 2016-07-31

(2016-07-31, 06:20)sciascia88 Wrote: The OpenVPN log says "ERROR: Linux route add command failed: external program exited with error status: 2" four times before completing the sequence, but I have no idea what that even really means and the developer seemed to not have much insight either.

This might be worth checking: http://serverfault.com/questions/757751/vpn-error-linux-route-add-command-failed

So also double check your configs.


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - john.cord - 2016-07-31

How to bring up the CodecInfo Screen after latest Build? Maybe related to change from CodecInfo to PlayerProcessInfoHuh


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - FernetMenta - 2016-07-31

(2016-07-31, 20:49)john.cord Wrote: How to bring up the CodecInfo Screen after latest Build? Maybe related to change from CodecInfo to PlayerProcessInfoHuh

There is no CodecInfo anymore. PlyerProcessInfo is opened with "o" key.

Edit: there is an action to show some player debug info but this action has no default mapping to any key


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - john.cord - 2016-07-31

Ok, thanks. I mapped the "Guide" Button on my Harmony to bring up CodeCinfo and after Update the Button does nothing. Shouldnt it bring Up PlayerProcessInfo? Is there some remapping needed? THe "o" Key on my Keyboard does nothing too. Maybe related to Aeon Nox 5? I updatet the Skin to latest Git.


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - nalor - 2016-07-31

(2016-07-31, 21:44)john.cord Wrote: Ok, thanks. I mapped the "Guide" Button on my Harmony to bring up CodeCinfo and after Update the Button does nothing. Shouldnt it bring Up PlayerProcessInfo? Is there some remapping needed? THe "o" Key on my Keyboard does nothing too. Maybe related to Aeon Nox 5? I updatet the Skin to latest Git.
Check this post: 2384804 (post)

The keyword for the CodecInfo had been renamed to 'PlayerDebug'


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Hitcher - 2016-07-31

It's actually 'PlayerProcessInfo' and I'm guessing Aeon Nox 5 hasn't been updated to reflect the changes yet. If you're using nightlies that involve changes to the skinning engine you should stick to using Estuary.