•   
  • 1
  • 285
  • 286
  • 287(current)
  • 288
  • 289
  • 355
  •   
  Thread Closed
v18 LibreELEC Testbuilds for x86_64 (Kodi 18.0)
(2018-09-05, 10:27)HiassofT Wrote:
(2018-09-05, 03:51)InNursery Wrote:
(2018-09-04, 11:42)dr88dr88 Wrote:  The problem is that Kodi see it now as an active mouse all the time even if the mouse is deactivated on the remote.  As soon as I try to move the remote the mouse pointer is activated in the middle of the screen without any movement of the mouse pointer.  
 I have the same problem the remote mouse is unusable.  
 @Milhouse could you create a build with this kernel patch https://patchwork.kernel.org/patch/10587369/ added? It's a likely candidate for fixing the mouse issues reported by @dr88dr88 and @InNursery 

so long,

Hias 
I tried the new build with the kernel patch but it did not solve the problem.
(2018-09-06, 00:38)Milhouse Wrote:
(2018-09-06, 00:28)piotrasd Wrote: from couple of version is problem with GUI - some element stay in backgroud example after switch channels, or download subtitles in movies.
or toggle screen betwean main menu and full screen

Could you mention what version you are currently using, and the first version with this issue?
I too have the same problem..from build #0814.
Till then was just fine. 
Hi Milhouse,

I came across your builds when I was checking out the Libreelec forum. I think it was mentioned that potentially your builds might do 10bit HDR. Is this accurate? I was hoping to get a Gemini Lake NUC or an 8th gen i3 but am holding off any purchasing anything until there is more clarity as to Kodi, Linux and proper 4k. (I know everyone talks about nVidia and windows working but I don't want Winblows and prefer to not have a dedicated gfx card.)

Thx for any info.
Shutting down the system or stopping kodi usually ends in a memory management error and creates a crash dump.

The error is not visible in default configuration because systemd kills the process before crash dump generation has finished. I have increased the stop timeout by creating

/storage/.config/system.d/kodi.service.d/timeout.conf:
Code:
[Service]
TimeoutStopSec=30

Bisecting the builds results in #0210 (yes, Feb 10) being the first one having the error.

Can someone else confirm the issue?
New LibreELEC.tv Leia build #0906: Generic
(Supercedes previous build)

SHA256 Checksum: 73682ad571726bdfccd857c86c67aba7bbc4613e4d193d383a56a1325aeb7387 (Generic)

# uname -a
Linux NUC 4.18.6 #1 SMP Thu Sep 6 21:52:36 BST 2018 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20180906215101-#0906-ga3c73c3 [Build #0906]

# Kodi version
(18.0-BETA2 Git:59cae3b). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (a3c73c3, changelog) and tip of XBMC master (59cae3b, changelog) with the following modifications: Build Highlights:
  1. [PVR] trac#18022: Add support for ACTION_SHOW_INFO to CGUIDialogPVRChannelGuide
  2. pvr.dvbviewer and pvr.mediaportal.tvserver fixes
Build Details:
  1. XBMC:
    • [PVR] trac#18022: Add support for ACTION_SHOW_INFO to CGUIDialogPVRChannelGuide (PR:14391, 1 commit, 1 file changed)
  2. pvr.dvbviewer:
  3. pvr.mediaportal.tvserver:
    • Fix Timeshifting for v18 (PR:93, 2 commits, 5 files changed)
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2018-09-06, 22:24)pletopia Wrote: Hi Milhouse,

I came across your builds when I was checking out the Libreelec forum. I think it was mentioned that potentially your builds might do 10bit HDR. Is this accurate? I was hoping to get a Gemini Lake NUC or an 8th gen i3 but am holding off any purchasing anything until there is more clarity as to Kodi, Linux and proper 4k. (I know everyone talks about nVidia and windows working but I don't want Winblows and prefer to not have a dedicated gfx card.)

Thx for any info.

Yes, potentially, at some point in the future when then entire stack supports HDR, but not at this time. Also see this reply.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Another HDR question, though I've actually read about a hundred pages back, so hopefully I'm not just repeating someone else's question Big Grin

I'm holding off on purchasing a 4k HDR capable graphics card until its HDR support is confirmed with the Linux kernel and Kodi. I'm guessing it'll be a GT 1030 or an RX 550, though I read somewhere that GeForce cards actually only output 8-bit even if they decode 10- and 12-bit HDR (though I'm hesitant to believe this; it just doesn't sound right).

Anyway, since there seems to be some support for 10 bpp output just without the "HDR" monicker, I'm wondering if one couldn't "just" get the same result by not sending HDR per se, but instead switching to 30-bit RGB? This would also allow for image slideshows to display in a wide colour palette when available. Or maybe that question just reveals how little I understand how hardware-assisted video decoding actually works? Or maybe HDR10 is more than just 10 bpp Smile

I have an LG OLED which does HDR, and it works great with DLNA using its native player, and HDR looks amazing. It just doesn't support, e.g. TrueHD audio or FLAC in MKVs, and besides I really really love Kodi and its plugins and library and picture support as well Smile
Nvidia GPU support is not confirmed for Kodi 19, so if you want to get more than a year or two out of your next GPU purchase you should avoid Nvidia entirely. The reasons why are covered elsewhere, but in a nutshell the current proprietary Nvidia API (VDPAU) is no longer developed by Nvidia and a technological deadend, and Nvidia have replaced VDPAU with yet another proprietary API (CUDA) that Kodi will not - at this time - be supporting.

Intel, AMD (and others on ARM) are using VAAPI which is more or less an open standard that Kodi 19+ will be supporting.

About your HDR questions - sorry no idea!
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Thank you, Milhouse Smile 

That's a really good reason to avoid Nvidia. Funny, back when before I switched to Mac for my non-server needs, I had a Radeon HD-something card, and had so much trouble getting it to work properly on Linux. I so regretted not having bought an Nvidia card because their Linux support was way better back then. And now everything is upside-down Big Grin Dodged a bullet yesterday cancelling my GT 1030 order before it was shipped, because I realised there was currently no HDR support.

Guess it'll be an AMD card whenever HDR is properly supported — till then I'll just stick with an old card and DLNA Smile

Thanks again!
(2018-09-06, 23:59)mglae Wrote: Shutting down the system or stopping kodi usually ends in a memory management error and creates a crash dump.

The error is not visible in default configuration because systemd kills the process before crash dump generation has finished. I have increased the stop timeout by creating

/storage/.config/system.d/kodi.service.d/timeout.conf:
Code:
[Service]
TimeoutStopSec=30

Bisecting the builds results in #0210 (yes, Feb 10) being the first one having the error.

Can someone else confirm the issue?

Funnily enough I'd been looking at this same crash-on-exit last Sunday.

I started with an RPi2 build which is crashing conistently in CProgramThumbLoader (http://ix.io/1ma9), while Generic is crashing in either GUIFontManager (http://ix.io/1ma5) or CNfsConnection (http://ix.io/1ma6).

Using a recent Generic build, ie. #0906, with the debug overlay enabled I'm able to reproduce the GUIFontManager crash on exit. However with the debug overlay disabled, the crash now occurs in CNfsConnection (http://ix.io/1ma6) as I have nfs:// sources.

Without debug logging enabled and without nfs:// sources, there are no crashes on exit with a Generic build.

I've tested hundreds of Generic builds and I've found that the CNfsConnection crashes were common until #0612, when the crashing stopped, only to start again with #0826, which is also when the GUIFontManager crash started to occur (if the debug overlay is enabled):

#0201: CNfsConnection crash
#0210: CNfsConnection crash
#0301: CNfsConnection crash
#0401: CNfsConnection crash
#0501: CNfsConnection crash
#0601: CNfsConnection crash
#0611: CNfsConnection crash
#0612 - #0825: No crash
#0826 - #0906: GUIFontManager/CNfsConnection crash

#0612 saw the introduction of "Reusepython" (PR13814), while #0826 introduced "PythonInvoker: fix thread termination check" (PR14356).

If I revert PR14356 from #0906 then the crashing - both GUIFontManager and CNfsConnection - no longer occurs.

I suppose it might be possible for the GUIFontManager crash to occur in the #0210 build but I didn't see this myself - it might depend on other factors such as installed addons, considering it is potentially a Python-related issue.

So it looks like the Python language interpreter is responsible in some way for the current crashes on exit - at least on Generic anyway, as the RPi2 crashes continue even after reverting PR14356 so they're due to something else, maybe a use-after-free/race condition.

I did try creating a Generic debug-enabled build to obtain a more detailed crash log, but building with debug changes the behaviour of kodi.bin so that it now crashes in a different place (http://ix.io/1m9Q) regardless of debug overlay status. I am also yet to reproduce any crash with Ubuntu but this may be because of the debug-build nature of the Ubuntu build, and/or combination of add-ons affecting the way in which the Python language interpreter and Kodi is shutting down.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2018-09-07, 07:46)Milhouse Wrote:
(2018-09-06, 22:24)pletopia Wrote: Hi Milhouse,

I came across your builds when I was checking out the Libreelec forum. I think it was mentioned that potentially your builds might do 10bit HDR. Is this accurate? I was hoping to get a Gemini Lake NUC or an 8th gen i3 but am holding off any purchasing anything until there is more clarity as to Kodi, Linux and proper 4k. (I know everyone talks about nVidia and windows working but I don't want Winblows and prefer to not have a dedicated gfx card.)

Thx for any info.

Yes, potentially, at some point in the future when then entire stack supports HDR, but not at this time. Also see this reply
 Thx for the clarification. So basically it seems my only current option is a Vero 4k like a buddy has which is about as powerful as my nearly 10 year old Atom/ION Zotac. Usable but definitely laggy when browsing my extensive library. Doubt any of the other Android choices would be significantly better.
New LibreELEC.tv Leia build #0907: Generic
(Supercedes previous build)

SHA256 Checksum: 5e182a72d3d6f63138cddde129974484dc58b835db0994645eaa94b3068af139 (Generic)

# uname -a
Linux NUC 4.18.6 #1 SMP Fri Sep 7 21:06:42 BST 2018 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse): devel-20180907210336-#0907-g10e5dba [Build #0907]

# Kodi version
(18.0-BETA2 Git:ef47f46). Platform: Linux x86 64-bit

Based on tip of LibreELEC.tv master (10e5dba, changelog) and tip of XBMC master (ef47f46, changelog) with the following modifications: Build Highlights:
  1. inputstream.adaptive with Widevine api 10 implemented
  2. [videoplayer] [bluray] Fix playback of disc with truehd tracks in menu mode.
  3. drm/i915: Increase LSPCON timeout (@YinYang - see if this helps your LSPCON problem)
Build Details:
  1. LibreELEC.tv:
    • Cleanup OOTB IR remote support and make it configurable (PR:2956, 5 commits, 5 files changed)
  2. XBMC:
    • [XBMCHelper] - fixed up/down buttons on macOS 10.13.6 (PR:14383, 3 commits, 4 files changed)
    • [videoplayer] [bluray] Fix playback of disc with truehd tracks in menu mode. (PR:14382, 2 commits, 1 file changed)
  3. inputstream.adaptive:
  4. Additional commits/pull requests/changes not yet merged upstream:
    • Added: [pkg] patch: drm/i915: Increase LSPCON timeout (linux)
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2018-09-07, 13:08)Milhouse Wrote: Funnily enough I'd been looking at this same crash-on-exit last Sunday.
Excellent.
 
Quote:Without debug logging enabled and without nfs:// sources, there are no crashes on exit with a Generic build.
I am testing with network disabled to keep the system environment as simple as possible. There are no additional plugins installed or enabled.

And always had debug logging enabled. After a few tests I can confirm there are no crashes without debug logging.

The GUIFontManager crash is not the only one I see, sometimes there are "corrupted double linked list" errors somewhere else (but unfortunately I did not save any logs). Furthermore In very rare cases kodi exits without crash.
 
Quote:#0201: CNfsConnection crash
#0210: CNfsConnection crash
#0301: CNfsConnection crash
#0401: CNfsConnection crash
#0501: CNfsConnection crash
#0601: CNfsConnection crash
#0611: CNfsConnection crash
#0612 - #0825: No crash
#0826 - #0906: GUIFontManager/CNfsConnection crash
I am getting different results. Just tested #0612, #0810 and #0825, all three do crash.
 
Quote:#0612 saw the introduction of "Reusepython" (PR13814), while #0826 introduced "PythonInvoker: fix thread termination check" (PR14356).

If I revert PR14356 from #0906 then the crashing - both GUIFontManager and CNfsConnection - no longer occurs.
Is the version available for download?
 
Quote:I suppose it might be possible for the GUIFontManager crash to occur in the #0210 build but I didn't see this myself - it might depend on other factors such as installed addons, considering it is potentially a Python-related issue.

So it looks like the Python language interpreter is responsible in some way for the current crashes on exit - at least on Generic anyway, as the RPi2 crashes continue even after reverting PR14356 so they're due to something else, maybe a use-after-free/race condition.
According to my tests I'm afraid reverting PR14356 does not solve the problem on Generic. I agree with you it is likely a memory corruption after use-after-free.
 
Quote:I did try creating a Generic debug-enabled build to obtain a more detailed crash log, but building with debug changes the behaviour of kodi.bin so that it now crashes in a different place (http://ix.io/1m9Q) regardless of debug overlay status. I am also yet to reproduce any crash with Ubuntu but this may be because of the debug-build nature of the Ubuntu build, and/or combination of add-ons affecting the way in which the Python language interpreter and Kodi is shutting down. 
@mglae Yes I have seen other crashes, not very often, but GUIFontManager and CNfsConnection crashes are by far the most common (for me, at least).

I'm testing with these scripts which you can install in the LibreELEC client:


wget -q http://ix.io/1mcF -O /storage/segfault
wget -q http://ix.io/1mcE -O /storage/debug.sh
chmod +x /storage/segfault /storage/debug.sh

Then run "/storage/segfault #" to test (where # is the number of restarts to be tested). If Kodi crashes it should display the relevant backtrace. With a regular build of Kodi I can usually trigger a crash within 3 restarts, quite often at the first attempt. With a build that has PR14356 reverted I can restart 30 times without a crash.

You can try #0907b which has PR14356 reverted: Generic

#0907:

NUC:~ # /storage/segfault 30
LibreELEC (Milhouse): devel-20180907210336-#0907-g10e5dba [Build #0907]
2018-09-07 23:19:54: 001 Stopping... stopped.
Found new crash log after Kodi shutdown!
********
[New LWP 1114]
[New LWP 1111]
[New LWP 1133]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/lib/kodi/kodi.bin --standalone -fs'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fc6b84b6b99 in ?? ()
[Current thread is 1 (Thread 0x7fc706597880 (LWP 1108))]

Thread 4 (Thread 0x7fc6ce7fc700 (LWP 1133)):
********
THREAD #1:
Thread 1 (Thread 0x7fc706597880 (LWP 1108)):
#0 0x00007fc6b84b6b99 in ?? ()
#1 0x00000000007e64b0 in CNfsConnection::destroyOpenContexts() ()
#2 0x00000000007e6536 in CNfsConnection:Big Grineinit() ()
#3 0x00000000007e6703 in CNfsConnection::~CNfsConnection() ()
#4 0x00007fc70791f3ec in __run_exit_handlers (status=65, listp=0x7fc707a95718 <__exit_funcs>, [email protected]=true, [email protected]=true) at exit.c:108
#5 0x00007fc70791f51a in __GI_exit (status=<optimized out>) at exit.c:139
#6 0x00007fc70790a092 in __libc_start_main (main=0x797102 <main>, argc=3, argv=0x7ffc7c5ae968, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc7c5ae958) at ../csu/libc-start.c:342
#7 0x000000000079820a in _start ()

#0907b:

NUC:~ # /storage/segfault 30
LibreELEC (Milhouse): devel-20180907230715-#0907b-g9f04b0e [Build #0907b]
2018-09-07 23:22:19: 001 Stopping... stopped. Starting... started.
2018-09-07 23:22:33: 002 Stopping... stopped. Starting... started.
2018-09-07 23:22:49: 003 Stopping... stopped. Starting... started.
2018-09-07 23:23:04: 004 Stopping... stopped. Starting... started.
2018-09-07 23:23:18: 005 Stopping... stopped. Starting... started.
2018-09-07 23:23:32: 006 Stopping... stopped. Starting... started.
2018-09-07 23:23:46: 007 Stopping... stopped. Starting... started.
2018-09-07 23:24:01: 008 Stopping... stopped. Starting... started.
2018-09-07 23:24:15: 009 Stopping... stopped. Starting... started.
2018-09-07 23:24:29: 010 Stopping... stopped. Starting... started.
2018-09-07 23:24:43: 011 Stopping... stopped. Starting... started.
2018-09-07 23:24:58: 012 Stopping... stopped. Starting... started.
2018-09-07 23:25:12: 013 Stopping... stopped. Starting... started.
2018-09-07 23:25:26: 014 Stopping... stopped. Starting... started.
2018-09-07 23:25:40: 015 Stopping... stopped. Starting... started.
2018-09-07 23:25:55: 016 Stopping... stopped. Starting... started.
2018-09-07 23:26:09: 017 Stopping... stopped. Starting... started.
2018-09-07 23:26:24: 018 Stopping... stopped. Starting... started.
2018-09-07 23:26:38: 019 Stopping... stopped. Starting... started.
2018-09-07 23:26:53: 020 Stopping... stopped. Starting... started.
2018-09-07 23:27:07: 021 Stopping... stopped. Starting... started.
2018-09-07 23:27:21: 022 Stopping... stopped. Starting... started.
2018-09-07 23:27:35: 023 Stopping... stopped. Starting... started.
2018-09-07 23:27:50: 024 Stopping... stopped. Starting... started.
2018-09-07 23:28:05: 025 Stopping... stopped. Starting... started.
2018-09-07 23:28:19: 026 Stopping... stopped. Starting... started.
2018-09-07 23:28:33: 027 Stopping... stopped. Starting... started.
2018-09-07 23:28:50: 028 Stopping... stopped. Starting... started.
2018-09-07 23:29:04: 029 Stopping... stopped. Starting... started.
2018-09-07 23:29:18: 030 Stopping... stopped. Starting... started.
All 30 passes successful!
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2018-09-03, 15:40)phunkyfish Wrote: Hey @fritsch

No, it's not wireless, wired ethernet.

So I disabled the VU+ addon and then tested with both the libreelec Alpha and the latest 902 build. I used a show from Amazon as the test case, same episode each time. I ran it for two minutes both times and then brought up the OSD after two mins which resolved the video stuttering.

LibreElec Alpha: http://ix.io/1lVs

Milhouse Build 902: http://ix.io/1lVx 

Home this helps shed some light on the issue.

Any further ideas @fritsch
Maintainer of Enigma2 PVR addon: repo, docschangelog
How to create a full debug: here
  •   
  • 1
  • 285
  • 286
  • 287(current)
  • 288
  • 289
  • 355
  •   
  Thread Closed
 
Thread Rating:
  • 24 Vote(s) - 4.5 Average



Logout Mark Read Team Forum Stats Members Help
LibreELEC Testbuilds for x86_64 (Kodi 18.0)4.524