Kodi Community Forum

Full Version: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
(2016-05-07, 03:07)bill_orange Wrote: [ -> ]Regarding the "Randomized Slideshow" picture failure with large collections of mixed format pictures, I tracked down the change where the problem started. That was fun.

Build #710-2015 is good, no problem. Build #711-2015 is bad. Kodi crashes on slideshow. One of #711 changes is "add support for specifying the image scaling algorithm" Maybe that's it.

Thanks for searching. I think PR7472 is also a possibility for increased memory usage.
Does disbling "Pictures -> Show EXIF picture information" in settings help?
(2016-05-07, 13:51)popcornmix Wrote: [ -> ]Thanks for searching. I think PR7472 is also a possibility for increased memory usage.
Does disbling "Pictures -> Show EXIF picture information" in settings help?

Yes. It increases the maximum comment length from 2K to 64K. There are 4 comments per exif data.
This means each photo requires 256K just for comments.
So, if you have 5000 jpegs in a directory, then more than 1 Gig of memory is needed just for storing exif comments...

Let me set that back to 2K for tonight's build.
(2016-05-07, 13:51)popcornmix Wrote: [ -> ]
(2016-05-07, 03:07)bill_orange Wrote: [ -> ]Regarding the "Randomized Slideshow" picture failure with large collections of mixed format pictures, I tracked down the change where the problem started. That was fun.

Build #710-2015 is good, no problem. Build #711-2015 is bad. Kodi crashes on slideshow. One of #711 changes is "add support for specifying the image scaling algorithm" Maybe that's it.

Thanks for searching. I think PR7472 is also a possibility for increased memory usage.
Does disbling "Pictures -> Show EXIF picture information" in settings help?

Turning EXIF off helps a little on the #711 build. With EXIF on Kodi crashs and restarts. With it off it hangs.
(2016-05-07, 16:05)bill_orange Wrote: [ -> ]Turning EXIF off helps a little on the #711 build. With EXIF on Kodi crashs and restarts. With it off it hangs.

How many photos?
(2016-05-07, 07:36)david1976aus Wrote: [ -> ]Any suggestions?

Don't cut debug logs, post the whole file... you've omitted useful information. And besides, that wasn't even a debug log (wiki) - make sure you enable debug logging.
(2016-05-07, 18:28)popcornmix Wrote: [ -> ]
(2016-05-07, 16:05)bill_orange Wrote: [ -> ]Turning EXIF off helps a little on the #711 build. With EXIF on Kodi crashs and restarts. With it off it hangs.

How many photos?

77g worth. probably about 10,000+ photos. Maybe the thing to do is to add a size check to the slideshow function. If the collection is larger than some arbitrary safe number, display "size to large" and return from the function.

P.S. On builds prior to #0507 is noticed that the LibreElec start-up movie was truncated by maybe 1/5 of a second. That is no longer the case with #507, The movie runs to completion.
New LibreELEC.tv Krypton build #0507: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.6.0-rc6 #1 Sat May 7 21:05:53 BST 2016 armv6l GNU/Linux

# vcgencmd version
May  6 2016 13:57:24
Copyright (c) 2012 Broadcom
version 0cc642d53eab041e67c8c373d989fef5847448f8 (clean) (release)

# lsb_release
LibreELEC (Milhouse) - Version: devel-20160507210445-#0507-g617cd64 [Build #0507]

# vcdbg log msg 2>&1 | grep DTOK
002486.047: Kernel trailer DTOK property says yes

# Kernel device tree status: Enabled

Based on tip of LibreELEC.tv master (617cd64a, changelog) and tip of XBMC master (3d570c50, changelog) with the following modifications: Build Highlights:
  1. NOTE: DVD playback remains temporarily disabled
  2. Possible fix for slideshow related crashes
Build Details:
  1. LibreELEC.tv:
    • kodi-binary-addons: update to latest versions (PR:316, 1 commit, 20 files changed)
    • libmad: fix 'unary operator expected' error (PR:317, 1 commit, 1 file changed)
    • fix chromium for 8.0 repo (PR:318, 2 commits, 3 files changed)
  2. XBMC:
    • [Coverity] Misc. Coverity issues (PR:9757, 13 commits, 13 files changed)
    • [win32][depends] Updated taglib to v1.11 (PR:9762, 1 commit, 1 file changed)
    • [depends] Updated taglib to v1.11 (PR:9764, 1 commit, 1 file changed)
    • [Input/EventServer] - pass amount to the action (fixes volumeup/down actions from eventclients) (PR:9768, 1 commit, 1 file changed)
    • addon fix status handler (PR:9766, 3 commits, 4 files changed)
    • [addons] sync with repo (02ccf6b5)
  3. pvr.dvblink:
    • pvr.dvblink (krypton), version 3.2.1 (PR:48, 1 commit, 5 files changed)
  4. newclock5:
    • New commits in this build:
      • Revert "[libexif] Increase the possible length of a comment according to the specification." (d13d071a)
    • Commits no longer in build:
      • fixup! [rbp] Default to double buffered (c671c291)
  5. Additional commits/pull requests/changes not yet merged upstream:
    • Added: [env] PR:321: RTL8812AU: Fix AP timeout and disable power saving
(2016-05-07, 20:16)bill_orange Wrote: [ -> ]
(2016-05-07, 18:28)popcornmix Wrote: [ -> ]
(2016-05-07, 16:05)bill_orange Wrote: [ -> ]Turning EXIF off helps a little on the #711 build. With EXIF on Kodi crashs and restarts. With it off it hangs.

How many photos?

77g worth. probably about 10,000+ photos. Maybe the thing to do is to add a size check to the slideshow function. If the collection is larger than some arbitrary safe number, display "size to large" and return from the function.

Yes! build #507 fixes the slideshow issue. The only remaining issue I have is the TuneIn Radio lockup about which I posted a week or so ago. That may be one for the TunIn author to fix anyway.
(2016-05-08, 00:02)bill_orange Wrote: [ -> ]Yes! build #507 fixes the slideshow issue.

Great, and thanks for identifying the build - it's tedious but it does pay off in most cases. Smile

(2016-05-08, 00:02)bill_orange Wrote: [ -> ]The only remaining issue I have is the TuneIn Radio lockup about which I posted a week or so ago. That may be one for the TunIn author to fix anyway.

Try build #0430 and #0501. If TuneIn hangs with build #0501 but not #0430, then it's most likely the same problem affecting YouTube (and probably Quasar), ie. PR9664.
(2016-05-08, 00:32)Milhouse Wrote: [ -> ]
(2016-05-08, 00:02)bill_orange Wrote: [ -> ]Yes! build #507 fixes the slideshow issue.

Great, and thanks for identifying the build - it's tedious but it does pay off in most cases. Smile

(2016-05-08, 00:02)bill_orange Wrote: [ -> ]The only remaining issue I have is the TuneIn Radio lockup about which I posted a week or so ago. That may be one for the TunIn author to fix anyway.

Try build #0430 and #0501. If TuneIn hangs with build #0501 but not #0430, then it's most likely the same problem affecting YouTube (and probably Quasar), ie. PR9664.

Yup. You nailed it. TuneInRadio runs fine on build #430 and hangs on #501.
(2016-04-23, 15:46)Milhouse Wrote: [ -> ]
(2016-04-23, 15:26)steve1977 Wrote: [ -> ]Any idea what I can do to further trouble-shoot?

The server is a beefy Unraid server (see my siganture for detais).

I'd suggest running a network bandwidth test using iperf, which you might still be able to install from the OpenELEC Unofficial repository (if you still have that repo installed).

Hopefully the LE 8 repository will be populated soon.

Thanks Milhouse. Please let me know the syntax to run iperf. Also, I have opened a separate thread as the issue is not related specifically to the the nightlies, but happens even with Jarvis. Thanks for your help!

272972 (thread)
(2016-05-06, 08:56)Sinisan Wrote: [ -> ]Hello all !

...no, this message is not to ask again about DVD playing... I wait. (perhaps could I help, but I don't really know how.. Strange : when you open the DVD iso, and read the .m2ts files, it's ok...).

This message is to ask you how Kodi recognize the movie 3D format. I'm not talking about the filename, but when it detects a 3D movie, you can choose SBS, TAB and "as the movie". My question is : how does it know the movie format ?

In reality, I have some little problems with makemkv : it's ok, the MVC format is ok, but when I play with Kodi, the player detects it's a 3D movie and ask myself what I want, and when I choose "as the movie" (that's what I'm usually doing), it's not in 3D. I have to choose SBS or TAB (it doesn't change : strange isn't it ?) to switch to good 3d movie.

This problem is not with all MVC MKV, of course. So it's probably a flag or something makemkv forgot to put in the file, but I would appreciate to know what Wink

Thank you for your help.

Hello,

Anybody could tell me what's the 3D "signature" ?

Thank you,
(2016-05-07, 02:53)Milhouse Wrote: [ -> ]
(2016-05-01, 15:22)Milhouse Wrote: [ -> ]
(2016-05-01, 14:28)nexusle Wrote: [ -> ]I think my Pi boots too fast?

Kodi is supposed to wait until the video player process disappears from the process list. The video player should always start before Kodi, and the video player should disappear once the video has played out in full. If you are not seeing the whole video, then this suggests the video player process terminated (disappeared) before the end of the video. About the only other possibility, and I don't know why or how this could happen, is that Kodi is starting before the video player so that when Kodi queries if the video player is still running it sees nothing running and continues without any delay - the video player may then eventually start, and you see only the first half of the video (or something). This would actually suggest your system is booting really slowly, or in some weird order.

I'll add "ulimit -c unlimited" to kodi-splash.sh in the next build, if the video player is crashing then we should get a core dump.

@nexusle: Is your splash video still not playing out completely? Do you have a hello_video.bin core dump file in /storage/.cache/cores? If so, can you run the following command (copy & paste it as a single line):
Code:
gdb /usr/bin/hello_video.bin --core="$(ls -1r /storage/.cache/cores/*hello_video.bin* | head -1)" --batch -ex "thread apply all bt" 2>/dev/null | paste
and paste the link.

If the video isn't playing out completely, but you don't have a core dump, then hello_video.bin probably isn't crashing - knowing this would also be useful information.

@Milhouse: I also have the issue that the splash video ends prematurely and have done some testing.

1. The hello_video.bin doesn't crash.
2. Normal reboot, the video ends as the white square starts to come out of the box.
3. Kodi debug reboot, the video plays to the end.
4. Running systemctl reboot kodi, the video plays to the end.

I wrote a script using autostart.sh to monitor the hello_video.bin process and noticed that the system time changes when it ends prematurely.

5. Normal reboot with the ethernet unplugged, the video plays to the end.
6. Normal reboot with connman/settings TimeUpdates=manual, the video plays to the end.

So it seems that hello_video.bin doesn't like the system time changing mid video and as it is a timing issue, it explains why it doesn't affect everybody the same.

Hope this helps.
Thanks @amediauser, that sounds like a very useful observation.
(2016-05-08, 18:33)amediauser Wrote: [ -> ]Hope this helps.

Yes, that's interesting. I suspect one of the timeouts in the splash player gets falsely triggered when the clock jumps.
Let me have a closer look.