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.
New LibreELEC.tv Krypton build #1003: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.7.6 #1 Mon Oct 3 21:04:53 BST 2016 armv6l GNU/Linux

# vcgencmd version
Sep 21 2016 13:17:10
Copyright (c) 2012 Broadcom
version 2eaf52cc53435b5ce67253af1487f9a4f9f96e2d (clean) (release)

# lsb_release
LibreELEC (Milhouse) - Version: devel-20161003210353-#1003-gd598804 [Build #1003]

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

# Kernel device tree status: Enabled

Based on tip of LibreELEC.tv master (d5988041, changelog) and tip of XBMC master (8d6e828a, changelog) with the following modifications: Build Highlights:
  1. [PVR] Fix CPVRDirectory::GetDirectory not to return false in case PVR is not yet (compeletely started).
Build Details:
  1. LibreELEC.tv:
    • projects/WeTek_Play_2: Update DVB patch - allow switching between DVB -T and DVB-T2 muxes (PR:795, 1 commit, 1 file changed)
    • moonlight-embedded: add patch to revert upstream commit (PR:787, 1 commit, 1 file changed)
    • dvblast: fix build with aml-3.14 (PR:788, 1 commit, 1 file changed)
  2. XBMC:
    • Remove home screen info mapping from remote.xml (PR:10585, 1 commit, 1 file changed)
    • Amlogic: fixes to hardware decoding blacklist (PR:10597, 2 commits, 3 files changed)
    • [PVR] Fix CPVRDirectory::GetDirectory not to return false in case PVR is not yet (compeletely started). (PR:10613, 1 commit, 1 file changed)
    • Resolution: Don't let code assumption from before 2k break behaviour (PR:10610, 1 commit, 1 file changed)
    • AESinkAUDIOTrack: Workarounds for AML chips in non AML mode (PR:10488, 5 commits, 3 files changed)
  3. inputstream.mpd:
  4. Additional commits/pull requests/changes not yet merged upstream:
    • Reverted: [pkg] 9a14177d: mediandk (reverted: breaks linux build) (inputstream.mpd)
(2016-10-03, 20:02)MikeKL Wrote: [ -> ]Is this information still useful?

Unfortunately I don't really know, as I think there is some uncertainty over the cause of the issue (maybe even issues) and certainly how to fix it. If you post on PR10544 with either crashlogs or requests for guidance on how to help (what logs or procedures might be useful etc.) then you should get a more intelligible answer! Smile
(2016-10-03, 23:37)Milhouse Wrote: [ -> ]Unfortunately I don't really know, as I think there is some uncertainty over the cause of the issue (maybe even issues) and certainly how to fix it. If you post on PR10544 with either crashlogs or requests for guidance on how to help (what logs or procedures might be useful etc.) then you should get a more intelligible answer! Smile
Thanks for update, will continue to perform nightly installs with debug check (as easy to do after your explanation thanks) and request guidance on what to check around my setup ref PR10544 and other PVR updates. (i.e. possibly #1002 PR10605)
Did anyone notice that omxplayer is far more stable than mmal for live tv usage? I'm yet to find a build that doesn't crash/lockup/reboot within 72 hours when using mmal. Switched to omxplayer a few days ago and so far so good. The only issue is much slower channel switching (when switching from one HD channel to another).
(2016-10-04, 18:08)smp1 Wrote: [ -> ]Did anyone notice that omxplayer is far more stable than mmal for live tv usage? I'm yet to find a build that doen't crash/lockup/reboot within 72 hours when using mmal. Switched to omxplayer a few days ago and so far so good. The only issue is much slower channel switching (when switching from one HD channel to another).

MMAL works fine for me. Never crashes on live tv.
(2016-10-04, 18:08)smp1 Wrote: [ -> ]Did anyone notice that omxplayer is far more stable than mmal for live tv usage? I'm yet to find a build that doen't crash/lockup/reboot within 72 hours when using mmal. Switched to omxplayer a few days ago and so far so good. The only issue is much slower channel switching (when switching from one HD channel to another).

Yes , i also need to use omx to get stable pvr
Can someone shed some light on what is causing this error? Happens on boot when the TP-Link TL-WN823N is plugged in, does not happen if it's not plugged in.

I've tried on a few recent Milhouse builds, as well as the official Krypton libreelec alphas, same issue. If I boot without it plugged in then plug it in after the fact, the raspberrypi freezes. I also have two raspberry pi's and two of the USB wifi adapters, and I've tried them both with no change.

edit - I should also note that these builds were working fine up until late last week, one unit was on the community alpha and self-updated and that error started. The other was a Milhouse build that I manually updated, is normally on ethernet but exhibits the same error when I try the USB wifi.

Image
(2016-10-03, 14:30)popcornmix Wrote: [ -> ]
(2016-10-02, 23:40)mikeb8591 Wrote: [ -> ]Provided previously : 2420580 (post)

Someone said it played fine for them, and I don't think I heard anything else about it.

Are you getting audio out-of-sync errors with this file?
I've tried various settings and can't provoke that.

Are you playing from file menu? (rather than PVR recording menu)

Can you confirm what settings you have for:

Yes, I get errors with that file, and I play from the pvr recorded video list.

omxplayer/mmal - on/on
Adjust display refresh rate to match video - off
Sync playback to display - off
PLL adjustment - Medium
Resample quality - GPU accelerated
Audio Passthrough - Enabled

Thanks!
(2016-10-04, 22:55)snapek Wrote: [ -> ]Can someone shed some light on what is causing this error? Happens on boot when the TP-Link TL-WN823N is plugged in, does not happen if it's not plugged in.

I don't know a specific reason, but could be a kernel issue.

I'd suggest going back through the builds in this thread trying different kernels, eg. #0907 (4.7.3), #0823 (4.7.2), #0725 (4.7.0), #0628 (4.6.3) until you find the first build that introduces the problem.

It may not be a kernel issue, could be a driver issue, however the RTL8192CU driver apparently used by this device hasn't been updated for over 2 years and isn't even listed on the Realtek site suggesting it's no longer supported by Realtek. There's a backport version available, which may work better - will see about switching to that in the Wednesday build.
New LibreELEC.tv Krypton build #1004: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.7.6 #1 Tue Oct 4 23:31:48 BST 2016 armv6l GNU/Linux

# vcgencmd version
Oct  4 2016 19:03:30
Copyright (c) 2012 Broadcom
version c844c61ad08f94946910d0d5e1be076df4c8c56d (clean) (release)

# lsb_release
LibreELEC (Milhouse) - Version: devel-20161004233048-#1004-g438740d [Build #1004]

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

# Kernel device tree status: Enabled

Based on tip of LibreELEC.tv master (438740d2, changelog) and tip of XBMC master (70417777, changelog) with the following modifications: Build Highlights:
  1. New firmware
Build Details:
  1. Firmware (Oct 4):
    • firmware: platform: Don't set kernel name explicitly for recovery.elf
    • firmware: resize: Add a queue of input images to avoid dropped frames with opaque input
    • firmware: resize: Set the direct_input flag when using mmal opaque mode
    • firmware: arm_loader: Restrict automatic loading to LOWMEM. See: link
    • firmware: RaspiVid: Make open_filename() unified for all outputs (video, imv, pts). See: link
  2. LibreELEC.tv:
    • linux: remove /dev/console patch from aarch64 (PR:799, 1 commit, 1 file changed)
  3. XBMC:
    • [cmake] Fix always outdated targets (PR:10614, 2 commits, 2 files changed)
    • VTB on OSX: fix flickering video caused by buffer overwrite (PR:10615, 2 commits, 8 files changed)
    • [doxygen] add support to show function with version change text (PR:10621, 1 commit, 3 files changed)
    • Create italian.xml (#10545) (dd13b734)
  4. Additional commits/pull requests/changes not yet merged upstream:
    • Added: [env] patch: libdrm: update to libdrm-2.4.71
    • Added: [env] PR:800: xf86-video-intel: enable dri3 and make it default
    • Added: [pkg] PR:10617: [eventlog] implement high resolution datetime sort method (CDateTime granularity of 1 sec is not sufficient).
    • Added: [pkg] PR:10620: [jsonrpc] CAnnouncementManager: fix invalid type "movies" for video items without video info tag
As soon as #1004 loaded I got into a continuous loop of Kodi reloading. Not a boot loop. I stayed booted. I used WinSCP to push #1003 into the Pi and sent the REBOOT command and all is well, running #1003.

Bill
(2016-10-05, 02:11)bill_orange Wrote: [ -> ]As soon as #1004 loaded I got into a continuous loop of Kodi reloading. Not a boot loop. I stayed booted. I used WinSCP to push #1003 into the Pi and sent the REBOOT command and all is well, running #1003.

Bill

Can you upload your crashlog?
I zipped up three of the logs. They don't appear identical.

https://1drv.ms/u/s!AmXKqAwyCrbxhdljQALLrH5fnIBQ-A
(2016-10-05, 00:51)Milhouse Wrote: [ -> ]It may not be a kernel issue, could be a driver issue, however the RTL8192CU driver apparently used by this device hasn't been updated for over 2 years and isn't even listed on the Realtek site suggesting it's no longer supported by Realtek. There's a backport version available, which may work better - will see about switching to that in the Wednesday build.

Tested my EDUP-1557 with same chipset. Everything works well on 1004 as usual.
Hi,

no support for USB Touch DELL ST2220 in kodi17? I have no entry in eventlist.
With Kodi 16.x it works and i have a entry in eventlist and can configure my touch to working.

Some idea?