• 1
  • 76
  • 77
  • 78(current)
  • 79
  • 80
  • 218
v17 LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)
(2016-07-02, 15:29)popcornmix Wrote: @Milhouse is it possible to include https://github.com/notspiff/inputstream.rtmp ?
As I understand it kodi now only supports very basic rtmp through ffmpeg and you need inputstream.rtmp for fuller rtmp support.

This is already included since #0612, and should be enabled by default.
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.
New LibreELEC.tv Krypton build #0702: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.6.3 #1 Sun Jul 3 10:02:40 BST 2016 armv6l GNU/Linux

# vcgencmd version
Jun 27 2016 17:27:06
Copyright (c) 2012 Broadcom
version 1e7b8e2c9a7319f7b22869f1334c66e2cfc99f4a (clean) (release)

# lsb_release
LibreELEC (Milhouse) - Version: devel-20160703100028-#0702-gf7cc132 [Build #0702]

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

# Kernel device tree status: Enabled

Based on tip of LibreELEC.tv master (f7cc132e, changelog) and tip of XBMC master (a64c0f94, changelog) with the following modifications: Build Highlights:
  1. New firmware - use versioned libELG and libGLESv2
  2. Updated inputstream.mpd
  3. mmal updates
Build Details:
  1. Firmware (Jun 27):
    • firmware: cmake: mark GLESv2 as so version 2 for consistency with mesa lib See: link
  2. LibreELEC.tv:
    • Odroid c2 updates (PR:498, 5 commits, 9 files changed)
  3. XBMC:
    • [depends] libomxil-bellagio is not used (PR:10055, 1 commit, 31 files changed)
    • Fix screensaver issue with JSON and pictures (PR:9749, 1 commit, 1 file changed)
    • rbp: Update transposed video scaling to match other platforms (PR:10050, 1 commit, 2 files changed)
    • mmalcodec: Add another buffer when deinterlacing (PR:10052, 1 commit, 1 file changed)
    • [settings] Adjustments to the location of settings and defaults (PR:10011, 2 commits, 2 files changed)
    • [addons] fix default sort order in recently updated (PR:10062, 1 commit, 2 files changed)
    • [PVR] Observers/Observables: Fix pvr windows <-> pvr components lifecycle problem. (PR:10061, 1 commit, 10 files changed)
  4. inputstream.mpd:
  5. newclock5:
    • Commits no longer in build:
      • rbp: Update transposed video scaling to match other platforms (c3d89555)
      • mmalcodec: Add another buffer when deinterlacing (26a4c6d9)
      • mmalcodec: Remove deinterlace support (cfaaa84e)
  6. kernel 4.6.y:
    • New commits in this build:
      • dts: Add overlay for NXP SC16IS752 Dual UART with SPI Interface (c6bdedbb)
      • spi-bcm2835: Disable forced software CS (7864c93a)
      • BCM270X_DT: Overlay to re-enable HW CS on SPI0 (c99c4d20)
  7. Additional commits/pull requests/changes not yet merged upstream:
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-07-03, 03:18)loggio Wrote: Any particular reason deinterlace support had been removed?

That was accidental - it should be back in latest build.
I'm working on a new scheme where deinterlace is being removed from decoder and added to renderer, and that commit was unintentionally included.
Have been stalking this thread for a while, wanted to finally say thanks for all the fine work folks - loving following the progress. I'm not much of a developer so can't contribute, though.

I wanted to ask if kodi addons are in the scope of this testbuild, or if they're mostly expected to not work until they're individually upgraded by their developers to support Krypton?
I'm having trouble getting EarthCam to work, for example, for which I have an error log - are these the kind of things sought for testing purposes? Or does it come down to having the expertise to know whether the error would be down to the working Krypton build, as opposed to the Libreelec build?
(2016-07-03, 12:32)Pinchanzee Wrote: I wanted to ask if kodi addons are in the scope of this testbuild, or if they're mostly expected to not work until they're individually upgraded by their developers to support Krypton?
I'm having trouble getting EarthCam to work, for example, for which I have an error log - are these the kind of things sought for testing purposes? Or does it come down to having the expertise to know whether the error would be down to the working Krypton build, as opposed to the Libreelec build?

It is up to add-on authors to update their add-ons to latest version of Kodi.
Check the add-on support thread to see if they claim Krypton compatibility (many do, many don't).
If they don't claim compatibility and the add-on doesn't work with these builds then you can request support on the add-on thread.

If they claim support for Krypton, or if if an add-on was working one day and fails the next, then you can mention it here, but it may well be that an API
has changed and they need to update again (although it could also be an accidental regression - we'll try to work that out).

We're still in the alpha stage of Krypton development, so breaking API changes are allowed. As Krypton moves to beta and RC stages, breakages become less likely.
(2016-07-03, 12:39)popcornmix Wrote:
(2016-07-03, 12:32)Pinchanzee Wrote: I wanted to ask if kodi addons are in the scope of this testbuild, or if they're mostly expected to not work until they're individually upgraded by their developers to support Krypton?
I'm having trouble getting EarthCam to work, for example, for which I have an error log - are these the kind of things sought for testing purposes? Or does it come down to having the expertise to know whether the error would be down to the working Krypton build, as opposed to the Libreelec build?

It is up to add-on authors to update their add-ons to latest version of Kodi.
Check the add-on support thread to see if they claim Krypton compatibility (many do, many don't).
If they don't claim compatibility and the add-on doesn't work with these builds then you can request support on the add-on thread.

If they claim support for Krypton, or if if an add-on was working one day and fails the next, then you can mention it here, but it may well be that an API
has changed and they need to update again (although it could also be an accidental regression - we'll try to work that out).

We're still in the alpha stage of Krypton development, so breaking API changes are allowed. As Krypton moves to beta and RC stages, breakages become less likely.

for regular addon there are zero changes that would break it. like the addon simply doesn't work even in v16
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Ok thanks for explaining, I'll bear that in mind before reporting issues Smile
(2016-07-02, 14:00)popcornmix Wrote:
(2016-07-01, 20:30)MikeKL Wrote: ----Edit----- Just watched full match, Wales 3:1 Belgium, what a great game of football and not a single drop/pause in 3.1Mpbs Limelight stream for whole match -----
It is possible the BBC have upgraded their servers and can handle more bandwidth now.
(2016-07-02, 19:10)popcornmix Wrote:
(2016-07-02, 17:45)MikeKL Wrote: I am also noticing that some skipping of frames is occurring with catch-up streams, which seems to me to be more noticeable and annoying in #0701.

"skip" steadily increasing in value, which is not occurring with live playback. (3.1 & 5.5Mbps Limelight)
If you think this is a regression, then identifying the first build with the problem would be very useful.
In summary, don't believe this is a regression Blush

Stepped back to #0629 and skipping appears to be occurring with catch-up in way its not not occurring with Live streams (Streaming at similar/same times in day) but skips are not often and therefore not too annoying
(Live & Catch-up streams continue to play reliably at any time of day, which overall "if permanent improvement" is really great news as this has not been case for me in past at higher BBC stream bit-rates)

Stepped forward and through each build and actually skipping with catch-up is no better or worse in any of #0629 to #0702 releases.
(Streaming same catch-up program this morning for,10 mins approx in each of the builds)

What I have noticed (user observation) recently when using latest milhouse builds and iplayer www add-on is :-
  • BBC Live streams are playing much much better now (as you indicated may be due to perhaps BBC server upgrades)
  • BBC Catch-up streams do appear to skip more frames than live streams for similar playback time periods.
  • Start either BBC stream type and at start skip = 6; after 10 minutes of streaming, Catch-up skip = 30 to 40 approx, Live Skip = 6)
Catch-up skipping occurs "whilst just watching program" i.e. I am not moving around in Kodi GUI, and the skipping occurs regardless of debug log switched on/off before streaming.
(Note: Never switched on debug option this morning during tests)
RPi4, (LibreELEC 11.0) hdmi0 -> Philips 55PUS7304 4K TV, hdmi1 -> Onkyo TX-SR608 AV Receiver
(2016-07-03, 13:33)MikeKL Wrote: Stepped back to #0629 and skipping appears to be occurring with catch-up in way its not not occurring with Live streams (Streaming at similar/same times in day) but skips are not often and therefore not too annoying

Does enabling "sync playback to display" help the catch-up case? (I think it effectively gets enabled with live streams).
(2016-07-03, 13:36)popcornmix Wrote:
(2016-07-03, 13:33)MikeKL Wrote: Stepped back to #0629 and skipping appears to be occurring with catch-up in way its not not occurring with Live streams (Streaming at similar/same times in day) but skips are not often and therefore not too annoying

Does enabling "sync playback to display" help the catch-up case? (I think it effectively gets enabled with live streams).
Enabled "sync playback to display" via GUI Player Settings -> Videos Then ran 10 minute soak test with same BBC Catch-up item at same stream level of 3.1Mbps and lo and behold
  • start skip = 6, after 10 mins skip = 6 CoolCoolCool
Thanks popcornmix for being so patient Blush
RPi4, (LibreELEC 11.0) hdmi0 -> Philips 55PUS7304 4K TV, hdmi1 -> Onkyo TX-SR608 AV Receiver
(2016-07-03, 13:36)popcornmix Wrote: Does enabling "sync playback to display" help the catch-up case? (I think it effectively gets enabled with live streams).

That explains what I am experiencing...
Watching live TV, every now and then when I hear music eg: The Simpsons intro , the pitch of the audio shifts and makes music sound off/out of tune. This happens when I enable sync to display, but I've had it disabled and it's still doing it.
Why is "sync playback to display" enabled by default on live streams?
It's not going to stay that way is it?
(2016-07-03, 14:05)loggio Wrote: Watching live TV, every now and then when I hear music eg: The Simpsons intro , the pitch of the audio shifts and makes music sound off/out of tune. Why is "sync playback to display" enabled by default on live streams?
It's not going to stay that way is it?

Yes. The clock of the server may differ from the clock of the client (typically clock accuracy is 100ppm or 0.01%).
This needs to be compensated for, and that is done through resampling the audio to keep the two ends in sync (which is what sync playback to display).

On the Pi, you can enable "PLL adjustment" in system/audio settings which avoids resampling, and so avoids the pitch warbles.
It can't handle large differences in clocks (e.g. when trying to play 24fps video on a 25Hz display), but should be fine for typical client/server clock adjustment.
Ahh... Well there you go. So should I set PLL High? Or lower?
something still breaks the stalker client in #702, same error.
but then again I do not see the commit popcornmix suggested or anything else that might have fixed it.
I do suffer from old man's css (can't see s**) though.

i'll just keep a lookout. Smile

thanks again.
(2016-07-03, 14:15)loggio Wrote: Ahh... Well there you go. So should I set PLL to 8 or lower?

8? I think the options are Off/Low/Medium/High/Max.
You should set it to the highest value that your TV/receiver is happy with. Too high and you may get audio/video dropouts. If you do lower it a notch and try again.
  • 1
  • 76
  • 77
  • 78(current)
  • 79
  • 80
  • 218

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