Kodi Community Forum
v18 LibreELEC Testbuilds for x86_64 (Kodi 18.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: v18 LibreELEC Testbuilds for x86_64 (Kodi 18.0) (/showthread.php?tid=298462)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355

RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - dr88dr88 - 2018-09-06

(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.

RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - oneneo - 2018-09-06

(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. 


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - pletopia - 2018-09-06

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.

RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - mglae - 2018-09-06

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?

RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-09-07

New LibreELEC.tv Leia build #0906: Generic
(Supercedes previous build)

SHA256 Checksum: 73682ad571726bdfccd857c86c67aba7bbc4613e4d193d383a56a1325aeb7387 (Generic)

text:
# 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)


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-09-07

(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.

RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - DanielSB - 2018-09-07

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

RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-09-07

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!

RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - DanielSB - 2018-09-07

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!

RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-09-07

(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.

RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - pletopia - 2018-09-07

(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.

RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-09-07

New LibreELEC.tv Leia build #0907: Generic
(Supercedes previous build)

SHA256 Checksum: 5e182a72d3d6f63138cddde129974484dc58b835db0994645eaa94b3068af139 (Generic)

text:
# 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)


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - mglae - 2018-09-07

(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. 


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - Milhouse - 2018-09-08

@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:

text:


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:
text:


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>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=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:
text:


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!


RE: LibreELEC Testbuilds for x86_64 (Kodi 18.0) - phunkyfish - 2018-09-08

(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