• 1
  • 278
  • 279
  • 280(current)
  • 281
  • 282
  • 495
v18 LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)
(2018-01-20, 02:56)smp1 Wrote: @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.
I did some intensive testing tonight:

- 32k chunks (thanks @smp1 for your build) plays almost well in a structurized 100 mbit environment. With typical 3D HBR ISOs very litle glitching during 2 hours & fast initial reading (<10 sec).

But as the usual purpose of SMB are servers w/o a structurized connection, I tested my real setup with ~100 mbit powerLAN and additionally with Wifi (~80 mbit/s):
- both connections don't work with 32k chunks (stuttering every ~10 secs.). So I changed to #0115 with large chunk size and both environments played absolutely w/o any stuttering Smile

Conclusio: chunk size seems to be the most important parameter for SMB users in terms of flawless playing. I think 64k could be still to small (as 32k didn't work at all with indirect connections).
- Is it possible to make this parameter visible/editable (e. g. in advancedsettings.xml)?
- Otherwise @smp1 could you share your test builds with 64k and 128k so I can further test (it would be great if you have pre #1501-builds for that, because then we have a version running SMB AND 3D flawlessly)

thanks
(2018-01-20, 03:54)Milhouse Wrote: 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. 
Thanks @Milhouse for clarification - do you plan to revert those until the bug is found? Any testing that I can provide?
Hope we get a SMB plus 3D version running - copying movies to usb sticks and put it then into the Pi is so old style ;-)
Hello,
sorry. with build #0119 i am unable to play all my bluray-files over smb.
Much buffering on br-menue or they would'nt start (bd50).

I do not have iso files on my network, only rips.
  New Reply
I'm back to #118, works fine for me.
Thanks
(2018-01-20, 16:20)KorbenDallas Wrote: Thanks @Milhouse for clarification - do you plan to revert those until the bug is found? Any testing that I can provide?
Hope we get a SMB plus 3D version running - copying movies to usb sticks and put it then into the Pi is so old style ;-)

Not at the moment - I'll leave that decision to @popcornmix. Using #0114 might be the best option until there's a fix.
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.
(2018-01-20, 16:12)KorbenDallas Wrote: @smp1 could you share your test builds with 64k and 128k so I can further test (it would be great if you have pre #1501-builds for that, because then we have a version running SMB AND 3D flawlessly) 
64K
128K
New LibreELEC.tv Leia build #0120: RPi / RPi2
(Supercedes previous build)

SHA256 Checksum: 746e9a0d78d037c72403d1a9b02174df2f855dd84453b9187e680b1b66e783bb (RPi)
SHA256 Checksum: 0659da4e0c33a97785e0327c35ab9ea44028ba50a9429a230f4bcfb3f2e03cac (RPi2)

text:
# uname -a
Linux rpi512 4.14.14 #1 Sat Jan 20 21:04:41 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-20180120210330-#0120-g92dcff2 [Build #0120]

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

Based on tip of LibreELEC.tv master (92dcff2, changelog) and tip of XBMC master (7781900, changelog) with the following modifications: Build Highlights:
  1. Music Artwork Consistently Available To GUI
  2. Edit: I forgot to stop reverting the ffmpeg commits so the 3D menu is working in this build
Build Details:
  1. LibreELEC.tv:
    • projects/Amlogic: add S912 support (PR:2411, 4 commits, 15 files changed)
    • fd628: new kodi service package to compliment fd628-aml driver (PR:2419, 2 commits, 6 files changed)
    • amlogic: Set colorspace to avoid no HDMI signal with non-4K output modes (PR:2422, 1 commit, 3 files changed)
    • linux: bump amlogic-3.14 kernel to c855778 and remove merged patches (PR:2423, 1 commit, 5 files changed)
  2. XBMC:
    • Music Artwork Consistently Availlable To GUI (PR:13352, 1 commit, 8 files changed)
    • [PVR] Guide window: Fix crash when switching profiles and both old an (PR:13397, 1 commit, 1 file changed)
    • [pvr][guiinfo] Fix PVR.EpgEventProgress. (PR:13398, 1 commit, 5 files changed)
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.
Re: build 0120

Having problems with 3d. iso and mkv files work fine. siff and m2ts files don't. 3d.mvc.mts files switch my tv to 3d but do not play properly.

Thanks
(2018-01-20, 16:12)KorbenDallas Wrote: I think 64k could be still to small (as 32k didn't work at all with indirect connections).
I did some more testing. 1024K and 512K are unusable - BD ISOs open very slowly.
256K is better but still slow with some ISOs (20+ seconds).
128K is better but much slower than 64K.

I get the best results with 64K.
(2018-01-21, 15:12)trevorjharris Wrote: Re: build 0120

Having problems with 3d. iso and mkv files work fine.

Thanks

Yes, this was actually a mistake on my part as I had forgotten to disable the revert of the 2 ffmpeg commits in build #0120. 3D ISO will not work in future builds (ie. #0121) unless a fix is committed upstream. Apologies for this unnecessary confusion.
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.
(2018-01-21, 19:18)smp1 Wrote: I get the best results with 64K

I've set it to 64K for tonight's build for further feedback.
New LibreELEC.tv Leia build #0121: RPi / RPi2
(Supercedes previous build)

SHA256 Checksum: afce1e371497aefdd96fc04ade0daef043940fdf5fa1ff789da20bb928d693a4 (RPi)
SHA256 Checksum: d0e3c9f7ac56f6faf12ffa38755b7286c2e96491372170afbf48b4342452c4f0 (RPi2)

text:
# uname -a
Linux rpi512 4.14.14 #1 Sun Jan 21 22:22:59 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-20180121222147-#0121-g92dcff2 [Build #0121]

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

Based on tip of LibreELEC.tv master (92dcff2, changelog) and tip of XBMC master (6b3552e, changelog) with the following modifications: Build Highlights:
  1. Filesystem: test: Increase chunksize to 64K
  2. Fix 3D breakage after ffmpeg patches
  3. AE: fix compensation distance
  4. VideoPlayer: fix stereoscopic playback (PR:13395)
  5. [PVR][Estuary] Guide window teaks for more consistency and readability
Build Details:
  1. XBMC:
    • FIX: [droid] let gradle handle debuggable (PR:13405, 1 commit, 1 file changed)
    • AE: fix compensation distance (PR:13404, 1 commit, 1 file changed)
    • [PVR][Estuary] Guide window teaks for more consistency and readability. (PR:13402, 1 commit, 2 files changed)
    • [xbmc] Update .gitignore (PR:13399, 1 commit, 1 file changed)
    • event stream: fix order (PR:13396, 1 commit, 1 file changed)
    • CHG: [droid] Draw GUI on own View (PR:13400, 1 commit, 14 files changed)
    • Resume last played media after sleep - DVD and stacks update (PR:13407, 1 commit, 3 files changed)
    • VideoPlayer: vaapi - fix bob and yadif methods (PR:13408, 1 commit, 3 files changed)
    • windowing: amlogic: set framebuffer to maximum size before initializing EGL (PR:13391, 1 commit, 1 file changed)
  2. newclock5:
    • New commits in this build:
      • depends: Fix guid build (f4a52e6e)
      • filesystem: test: Increase chunksize to 64K (7b9b261b)
      • Revert "fixup: CStereoscopicsManager reduce logging spam" (7335f092)
      • Revert "StereoscopicsManager: Wait for valid stream info before triggering stereo mode" (4c646f00)
      • VideoPlayer: fix stereoscopic playback (458c1641)
      • Revert "fixup ffmpeg patches" (2e670ede)
      • ffmpeg: Restore GMC patch (9dc09fa9)
      • ffmpeg: Restore MVC patch (c410d88e)
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.
Re Build 121 on Raspberry Pi 3

Just tested 121 for playing 3d files.

iso and mkv files work ok.

siff and m2ts files fail to be recognized as 3D.

3d.mvc.m2ts files are recognized as 3D but do not display correctly

Regards Trevor
(2018-01-21, 20:33)popcornmix Wrote:
(2018-01-21, 19:18)smp1 Wrote: I get the best results with 64K

I've set it to 64K for tonight's build for further feedback.  

64K seems to be the absolutely perfect setting. (RPI3 / Wired connection)
Hi Milhouse & Popcornmix.
I am getting a large memory leak while playing HEVC, it's worse with higher quality/bitrate files.
System Log and Crash log at:-
http://ix.io/Evy
http://ix.io/Evz
Full log extracted from logging directory https://www.dropbox.com/s/bgz6o72to1fb9t...5.zip?dl=0
I did enable debug logging for the most recent crash.
I am using a Pi3, I only tend to use your x builds, so this is with the latest 20180115215804-#0115x.
As an example, I started with memory reporting 592468K by the time I get the crash there is only 51500K being reported, this can be as quick as 5mins.
I could not log in using ssh once everything locks up, had to power off, could not reboot.
Let me know if you would like any other info.
Kevin.
(2018-01-21, 19:18)smp1 Wrote:
(2018-01-20, 16:12)KorbenDallas Wrote: I think 64k could be still to small (as 32k didn't work at all with indirect connections).
I did some more testing. 1024K and 512K are unusable - BD ISOs open very slowly.
256K is better but still slow with some ISOs (20+ seconds).
128K is better but much slower than 64K.

I get the best results with 64K
Thanks @smp1 for the test builds!

I tested more and agree with you that 64k chunk size works fine with direct (wired) connection. But from 64k to 128k there is a big improvement in terms of reduced stuttering for non-direct conncetions (the initial setup with 2048k worked flawlessly). 128k still has some glitches but ISO opening time is acceptible (ca. 15 secs). So I would vote for 256K - it prolongs the opening time (to my mind compared to stuttering in a still acceptible level hopefully) but increases the chance, that people can watch hibit media via SMP.

BTW: does the protocol level influence the overhead/net speed (i. e. is a SMP1 connection faster/slower than a SMP3 connection)? If so, I will test the fastest standard as this is selectable directly in KODI settings.

Any chance to make the chunk size selectable or distinguish chunk size for initial reading and media playing?

Cheers
  • 1
  • 278
  • 279
  • 280(current)
  • 281
  • 282
  • 495

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