• 1
  • 71
  • 72
  • 73(current)
  • 74
  • 75
  • 218
v17 LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)
@Milhouse
Quote:gcc: update to 5.4.0

Is this true for the PI too?
AFAIK there were Kodi related issues with gcc 5.3.x edit: on ARM.
Everything works fine?
(2016-06-26, 12:04)asavah Wrote: Is this true for the PI too?

Both Pi1/Zero and Pi2/3, yes.

(2016-06-26, 12:04)asavah Wrote: AFAIK there were Kodi related issues with gcc 5.3.x edit: on ARM.
Everything works fine?

Seems to, but this is a test build thread, so you tell me. Smile
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.
@Milhouse
If memory serves Kodi was crashing on arm when trying to access any database.
The folks on alarm (ARCH Linux ARM) forums told that it's a gcc bug, alarm used gcc 5.1.x to build kodi, while the rest of the packages were built with 5.3.x.
I've not seen any problems accessing MySQL or SQLite with #0625 built using gcc 5.4.0.

Also, you know LE has been using gcc 5.3.0 since December 2015? But then we build the whole of LE with the same gcc.
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.
(2016-06-26, 12:36)Milhouse Wrote: Also, you know LE has been using gcc 5.3.0 since December 2015? But then we build the whole of LE with the same gcc.

Thanks for the info, guess I missed the bump, I thought that OE/LE were still using 4.9.x for ARM, that's why I asked.
5.3.x (or whatever ubuntu 16.04 has now) has been flawless on x86.
I'm having problems with intermittent startup using #618 (I use lirc) on both a b+ and a zero.
On the b+ I'm mounting storage via NFS, it's local on the zero. The b+ has a wired connection, the zero uses wireless.

When the 'failure occurs, #618 manages to boot, display the animation (a 'blue' kodi animation on the b+ and a 'libreelec' animation on the zero?) then sits there with a fully black screen (i.e. before the kodi splash screen appears).

When in the 'locked' state, you can ssh into the box, but ssh locks up (even ctrl-c won't exit the session) before printing the LibreELEC banner (although "Warning: untrusted X11 forwarding setup failed: xauth key data not generated" is generated when appropriate so it seems the ssh daemon is running). It feels like sshd isn't able to sporn a shell for some reason.

Normally I run with 'Wait for network before starting kodi' turned on with a 10 second timeout (I use a shared sql database), but you can sit forever waiting for kodi to start. I've just turned it off via the GUI and the problem has re-occured so it doesn't seem to be related to this feature.

It seems that if I ssh into the box while the splashscreen animation is running (a question of timing) the box will always boot up properly. If I wait until the animation has finished playing ssh will only connect properly if the fault doesn't occur.

In locked-up cases, using the nfs mounted storage partition on the b+ I can see .kodi/temp/kodi.log but it hasn't been updated since the last run - so it doesn't look like a kodi related thing - more LibreELEC / systemd.

Any ideas what I should try next to enable some useful remotely accessible logging?

Edit: I've managed to get something useful out of a 'locked up' box by bypassing the shell (ssh root@testpi journalctl -b > journal.txt) not sure what it's telling me: http://pastebin.com/PjGqbdzJ

Edit2: On the grounds that "systemctl restart kodi" runs the splash animation and the lockup seems to occur between the animation and the 'fixed' kodi splashscreen, I've disabled the animation: (touch /storage/.config/splash.disable). No lockups yet... Will post back if it re-occurs.
#0625 and Kodi Estuary GUI Lock-up when using iplayerwww add-on

I was moving around various iplayerwww catch-up options avalable in GUI before selecting Watch Live option where Kodi appeared to lock-up however after reasoably long wait (5mins?) GUI recovered kodi Log

Don't believe issue is specifically related to latest nightly or use of iplayerwww add-on as have noticed GUI Estuary lock-up couple of times before for a few minutes (very infrequent) and didnt think to ssh and grab log file. Blush

PS I had just updated kodi to #0625 from #0624 less than 15mins before noticing this issue in case it has any releavance?
RPi4, (LibreELEC 11.0) hdmi0 -> Philips 55PUS7304 4K TV, hdmi1 -> Onkyo TX-SR608 AV Receiver
(2016-06-26, 14:15)MikeKL Wrote: #0625 and Kodi Estuary GUI Lock-up when using iplayerwww add-on

Would need a debug log. You can see a 15m gap in log, but no real clues about what was going on.
There are some errors about missing controls - are you using Estuary?

Does the stall occur repeatably? Which was the first build with the problem?
Kodi freezes if you go to the EPG Timeline, watch LiveTV fullscreen and push 'back' to exit Fullscreen to go to the epg window
(2016-06-26, 12:36)Milhouse Wrote: I've not seen any problems accessing MySQL or SQLite with #0625 built using gcc 5.4.0.

Also, you know LE has been using gcc 5.3.0 since December 2015? But then we build the whole of LE with the same gcc.

So I investigated this a little more and I share my findings to save you a possible future headache and to possibly bring this to the attention of some skilled Kodi dev who may actually fix the issue.

The crash is still present with gcc-5.4.0, you have not stumbled into it because of this https://github.com/LibreELEC/LibreELEC.t...ge.mk#L240
--disable-optimizations
If kodi is build with -O2 or higher for arm it crashes on the start.
The issue is here http://trac.kodi.tv/ticket/16609
The patch provided in the ticket https://github.com/zpon/xbmc-imx-git/blo...ults.patch effectively allows kodi to run on arm if built with --enable-optimizations.

The crash does not happen on x86_64.

I can't tell if it's gcc bug (most likely) or kodi bug.
I'll update the ticket with my findings, hope someone with good knowledge of gcc can either fix this in Kodi or file a proper bug report to gcc devs.
Thanks. If a fix is ever implemented (either Kodi or gcc) then we could consider using --enable-optimizations.
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.
(2016-06-26, 14:23)popcornmix Wrote:
(2016-06-26, 14:15)MikeKL Wrote: #0625 and Kodi Estuary GUI Lock-up when using iplayerwww add-on
Would need a debug log. You can see a 15m gap in log, but no real clues about what was going on.
There are some errors about missing controls - are you using Estuary?

Does the stall occur repeatably? Which was the first build with the problem?
Yes using Estuary, not easy to repeat stall at all, I switched on debug-log after providing previous log and tried to recreate the stall but unsuccessful.

Then left kodi running with debug on and switched-off TV, when came back after 1hr or more unable to wake up kodi with either remote or a bluetooth keyboard.
(similar to stall?)

Here is debug-log before I rebooted pi, for what its worth.

Really not sure when first noticed stall, but definitely seen it in earlier build, than latest builds.
RPi4, (LibreELEC 11.0) hdmi0 -> Philips 55PUS7304 4K TV, hdmi1 -> Onkyo TX-SR608 AV Receiver
New LibreELEC.tv Krypton build #0626: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.6.2 #1 Sun Jun 26 21:40:03 BST 2016 armv6l GNU/Linux

# vcgencmd version
Jun 20 2016 18:18:51
Copyright (c) 2012 Broadcom
version 460b39c674ef2ac89360e15331f97a2cb1388a44 (clean) (release)

# lsb_release
LibreELEC (Milhouse) - Version: devel-20160626213854-#0626-g457702a [Build #0626]

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

# Kernel device tree status: Enabled

Based on tip of LibreELEC.tv master (457702ad, changelog) and tip of XBMC master (b101751e, changelog) with the following modifications: Build Highlights:
  1. FFmpeg 3.1 with minimal Kodi commits/patches
Build Details:
  1. XBMC:
    • [upnp] CUPnP::InvokeUpdateObject: fix case when MediaServer does not support UpdateObject() action (PR:10027, 1 commit, 1 file changed)
    • configure.ac: Fix typo in help text of non-free option (PR:10034, 1 commit, 1 file changed)
  2. inputstream.mpd:
  3. newclock5:
    • New commits in this build:
    • Commits no longer in build:
      • fixup! rbp: Update to use new processInfo data cache (b0da4dff)
      • fixup! codecoverlay: Include codec name in overlay (6ed458bc)
  4. kernel 4.6.y:
    • New commits in this build:
      • mmc: Apply ERASE_BROKEN quirks correctly (85bc78c8)
    • Commits no longer in build:
      • Merge pull request #1522 from DigitalDreamtimeLtd/rpi-4.6.y (47b63bd3)
      • mm: introduce dedicated WQ_MEM_RECLAIM workqueue to do lru_add_drain_all (3f6045c1)
  5. Additional commits/pull requests/changes not yet merged upstream:
    • Added: [env] patch: ffmpeg: update to ffmpeg 3.1, minimal Kodi specific commits
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.
HI Milhouse,

I am on Raspberry Pi3 , using libreelec K17 since #618 till #626, the addon PVR Stalker Client 2.5.0 Search function not working, the search function in the PVR does not allow for writing in any string, but rather is showing me external Directories of my RPI (a directory for an ext4 partition on my SD or if i add my USB HDDs, they show up as well).

Its pretty odd and tiring, i cant search up a channel or a program, within 2500 channels i have!

When i try from MAC OS, Kodi build 17 as well, the add on is behaving well, and indeed the search function works perfectly!

I opened a thread in Stalker client middleware forum, but i was told to open in PVR support as the search function might not be an add on function, but rather a Kodi's only. and that might be true, as on MAC the builds are from Kodi, while on RPi3 its the nightly we use here (Thanks to your excellent work).

PS: search anywhere else in Kodi works fine, only within the stalker client it doesnt.
Build #0626 broke the DVD playback again. This time the navigation in DVD menus does not work on many titles I tested. The sample I posted here is a good example.
  • 1
  • 71
  • 72
  • 73(current)
  • 74
  • 75
  • 218

Logout Mark Read Team Forum Stats Members Help
LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)19