• 1
  • 277
  • 278
  • 279(current)
  • 280
  • 281
  • 495
v18 LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)
Netflix/Amazon/inputstream.adaptive/widevine/helper/resolution issues would be better handled in dedicated support threads, probably in Add-on support > Video Addons (there's already one there for the Amazon issue).

Please start dedicated threads per issue, otherwise we'll need to start moderating these test build threads and moving (or garbage binning) the OT Netflix/Amazon/inputstream/widevine/helper/resolution posts.

Edit: I've just posted the same message in the Generic test build thread.
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 Leia build #0118: RPi / RPi2
(Supercedes previous build)

SHA256 Checksum: 5bf60482c3534661fda7f55352956198f40842cc50a579baf3af4257990d342c (RPi)
SHA256 Checksum: f7c6d6a5824cf82cd09dec8a5b1cbee60f0ea311d6fcb8d6ad0acc2a260aba49 (RPi2)

text:
# uname -a
Linux rpi512 4.14.14 #1 Thu Jan 18 21:46:32 GMT 2018 armv6l GNU/Linux

# vcgencmd version
Jan 17 2018 17:19:55
Copyright © 2012 Broadcom
version 334597236bcc2498b0a044e21aa2f5b255bf3d22 (clean) (release)

# lsb_release
LibreELEC (Milhouse): devel-20180118214519-#0118-g07482bc [Build #0118]

# Kodi version
(18.0-ALPHA1 Git:69a6725). Platform: Linux ARM 32-bit

Based on tip of LibreELEC.tv master (07482bc, changelog) and tip of XBMC master (5d10ea5, changelog) with the following modifications: Build Highlights:
  1. [video] Fix CGUIWindowVideoBase::GetResumeItemOffset after #13288
Build Details:
  1. LibreELEC.tv:
    • qca9377-firmware-aml: change firmware version to 1.0.0-3 (PR:2420, 1 commit, 1 file changed)
  2. XBMC:
    • [PVR] Guide window: put channel group selector implementation into own class (PR:13384, 1 commit, 2 files changed)
    • [Windows] fix adapters enumeration for multiple GPU (PR:13386, 1 commit, 1 file changed)
    • [Filesystem] Add EfectiveUrl translation in addon interface (PR:13387, 1 commit, 1 file changed)
    • [xbmc] Link against curl instead of using dlopen. (PR:13360, 4 commits, 8 files changed)
    • [video] Fix CGUIWindowVideoBase::GetResumeItemOffset after #13288 (on (PR:13389, 1 commit, 1 file changed)
    • [win10] make the uwp app working in background and handles media butt (PR:13388, 1 commit, 3 files changed)
  3. pvr.mediaportal.tvserver:
    • [fix] allow building with glibc 2.26 or newer (PR:81, 1 commit, 2 files changed)
  4. kernel 4.14.y:
    • New commits in this build:
      • ASoC: bcm2835: fix hw_params error when device is in prepared state (#2345) (063440ee)
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.
Dear Team,

3D MVC support does not work any longer (tried with OMXPlayer activated and deactivated) - problem started after #0112. 3D MVC blurays play simpply as 2D since then. Is this bug already known or should I track it down more today evening?

...and thanks for the great work!
Some feedback regarding the SMB fix (with seems to help a lot with the known bad SMB performance) in #0115:

- since you changed the checksize I'm able to play blurays with high bitrate without stuttering via a direct 100 mbit connection (HPProliant Gen10 server running libreelec 8.2.2 as smb server -> switch -> raspberryPi2 with increased read buffer settings in advancedsettings.xml). Great! Before that, there was constant stuttering every 20-30 seconds (esp. 3D ISO blurays/high bitrate)

- But the larger chunks also lead to a slow initial reading of the bluray (so it takes approx. 2 minutes to start a bluray - which I think is logical as small R/W cycles are slowed down by large chunks). Question:  is it possible to open the smb connection with small chunk size for reading the iso file structure and then reinstantate the smb connection with the correct (large) check size so highbit media plays flawlessly via smb?

If not, please keep the large size as I searched like crazy to find out why a wired 100mbit connection cannot play 40mbit/s media w/o stuttering (recommended solution is to change to nfs btw) Smile

cheers
(2018-01-19, 13:00)KorbenDallas Wrote: Some feedback regarding the SMB fix (with seems to help a lot with the known bad SMB performance) in #0115:

- since you changed the checksize I'm able to play blurays with high bitrate without stuttering via a direct 100 mbit connection (HPProliant Gen10 server running libreelec 8.2.2 as smb server -> switch -> raspberryPi2 with increased read buffer settings in advancedsettings.xml). Great! Before that, there was constant stuttering every 20-30 seconds (esp. 3D ISO blurays/high bitrate)

- But the larger chunks also lead to a slow initial reading of the bluray (so it takes approx. 2 minutes to start a bluray - which I think is logical as small R/W cycles are slowed down by large chunks). Question:  is it possible to open the smb connection with small chunk size for reading the iso file structure and then reinstantate the smb connection with the correct (large) check size so highbit media plays flawlessly via smb?

Yes, that was my fear.
I've changed the chunk size to 32K which was the smallest value that fixed smp1's issue.
Let us know if that helps bluray open time and if it's also okay for high bitrate stuttering.
(2018-01-19, 13:00)KorbenDallas Wrote: - But the larger chunks also lead to a slow initial reading of the bluray (so it takes approx. 2 minutes to start a bluray - which I think is logical as small R/W cycles are slowed down by large chunks).
cheers
Do you get the slow initial reading with all blurays? All my blurays open pretty much immediately with the current 2048*1024 setting (I don't have any 3D ISOs though).
Ok, I just tried to play a BD ISO file and it does indeed open extremely slow.
But the BDMV folders work perfectly fine.
(2018-01-19, 15:26)smp1 Wrote: Ok, I just tried to play a BD ISO file and it does indeed open extremely slow.
But the BDMV folders work perfectly fine.
 Yes, same here - reading the ISO file structure / tree seems to have a lot of small read cycles...
Is it possible to reinitialize the SMB connection or is this not feasible?

Cheers K.
(2018-01-19, 14:27)popcornmix Wrote: I've changed the chunk size to 32K which was the smallest value that fixed smp1's issue.
I just tested with 32*1024 and I can confirm that BD ISOs work fine now.
New LibreELEC.tv Leia build #0119: RPi / RPi2
(Supercedes previous build)

SHA256 Checksum: 8071e5b2965cec52fdcd3a3c54daff7ed3a9751df42b6f3a563619d867784fad (RPi)
SHA256 Checksum: 21d85adb883c249ceb49cab275f5ea3bfb5bbfb78c6bfe99a40a8e57fbdbd956 (RPi2)

text:
# uname -a
Linux rpi512 4.14.14 #1 Fri Jan 19 21:04:36 GMT 2018 armv6l GNU/Linux

# vcgencmd version
Jan 17 2018 17:19:55
Copyright © 2012 Broadcom
version 334597236bcc2498b0a044e21aa2f5b255bf3d22 (clean) (release)

# lsb_release
LibreELEC (Milhouse): devel-20180119210323-#0119-g07482bc [Build #0119]

# Kodi version
(18.0-ALPHA1 Git:69a6725). Platform: Linux ARM 32-bit

Based on tip of LibreELEC.tv master (07482bc, changelog) and tip of XBMC master (a3f4c40, changelog) with the following modifications: Build Highlights:
  1. filesystem: test: Reduce chunksize to 32K
  2. [pm] resume last played media after sleep
Build Details:
  1. XBMC:
    • xbmcgui - add option to define listitem as folder (PR:13385, 1 commit, 2 files changed)
    • addonsettings - don't lowercase condition value (PR:13306, 1 commit, 1 file changed)
    • [Estuary] some delicate touches to the channelgroup selector (PR:13392, 1 commit, 1 file changed)
    • [pm] resume last played media after sleep (PR:13390, 2 commits, 3 files changed)
  2. newclock5:
    • New commits in this build:
      • filesystem: test: Reduce chunksize to 32K (9fffdd0b)
      • hack: Don't assert when unexpected buffer id but keep going (0bb0e771)
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.
@popcornmix 
I did some more testing with different chunk sizes and I think 64K is the optimal value. 32K works ok but I get occasional buffering at the start of playback of some TS files. With 64K the playback always start immediately. BD ISOs also work fine.
(2018-01-19, 12:44)KorbenDallas Wrote: Dear Team,

3D MVC support does not work any longer (tried with OMXPlayer activated and deactivated) - problem started after #0112. 3D MVC blurays play simpply as 2D since then. Is this bug already known or should I track it down more today evening?

...and thanks for the great work!

Yes, 3D is no longer working since #0115, possibly one or both of:
(2018-01-15, 23:57)Milhouse Wrote:
  1. New commits in this build:
    • fixup ffmpeg patches (9abc3001)
    • ffmpeg: hevc: Update to latest version (47888398)

Reverting both commits restores functional 3D playback.
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.
I can't reproduce. Placed some Bluray iso on a SMB share. Starts lightning fast here. Testing on Mac.
Ref my previous post I have been noticing more stable playback of live tv from iplayer www in latest nightly builds (placebo effect?) and thought perhaps a recent nightly included something that improves issue I was observing in earlier and recorded in #1012 & #0113 build logs.

Using #0119  another kodi.log where first attempt to playback live stream iplayer www only lasted a few minutes before audio/video pausing occured.
Stoping playback (because of annoying issue) and restarting the playback and was without any issues lasting good 20mins.
(Not a debug log but info may be useful?)

Now listening to Live Radio to see how long live playback has no Audio issues, compared to last weekend with #0114
RPi4, (LibreELEC 11.0) hdmi0 -> Philips 55PUS7304 4K TV, hdmi1 -> Onkyo TX-SR608 AV Receiver
how can I speedup the baud rate of i2c?
"cat /sys/module/i2c_bcm2708/parameters/baudrate" gives a value of 0
  • 1
  • 277
  • 278
  • 279(current)
  • 280
  • 281
  • 495

Logout Mark Read Team Forum Stats Members Help
LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)24