Posts by Stereodude

Quote from relkai

Sure, it's easier to blame the devs instead of searching for problems in your own attitude.
In the thread you mentioned, several users (not only the devs) offered their help and asked you to switch to NFS for testing, because it has less overhead than the SMB protocol.

Yeah, maybe you would have ended up with the same results, but that would have helped the devs a lot to isolate the real problem.

But you decided not to switch to another protocol (even for testing purposes), but to give rude and arrogant answers to everyone trying to help you.

That was the reason, why some of your really inadequate answers were being deleted by the moderators.

Here is a link to the thread:

Blu-ray playback pausing and buffering on gigabit network - Kodi - CoreELEC Forums

Display More

Sorry the facts hurt you so badly that you had to venture over here, create an account, and try to spin the situation. Clearly I've struck a nerve. Thanks for providing a link so others can see a heavily edited thread showing how the CE developers treat users. Too bad they can't see all the innocuous posts that were deleted.

At the end of the day the LE devs found the problem without telling me the C2 was crappy hardware. No one insisted the problem would be solved with NFS and that a Windows user should try to implement it.

Oh, and lets not tell just half the story. Here's the thread on this forum showing on the LE devs handled the same basic report. The difference in how the the two projects responded will be very stark to any reader who reads both.

It unfortunate that the CE team will benefit from the work of the LE team by inheriting the fix in the upstream Kodi codebase. Of course I wouldn't put it past you all to intentionally exclude it to spite me either.

Quote from Shoog

Frankly I don't believe you. Just more mud slinging. I have already satisfied myself that one of your complaints is false.
I like LE and use the current Leia release on my RaspPi without issues, but this constant bad mouthing of CE from certain member of the LE team is just a bit pathetic.

Shoog

Well, I'm just a user, but the CE team is a perfect example of what's wrong with some open source communities. They don't take user reports of bugs seriously and are rude and unhelpful. When I reported a bug in CE on the Odroid C2 with network performance when they weren't deleting my forum posts they blamed the network protocol (SMB) and told me I was expecting too much of my hardware. I identified the same issue in LE. In contrast the LE team took my complaint seriously, identified the issue, and made test builds within hours that addressed the issue. I guess the issue wasn't my expectations after all...

So you can cheerlead the CE all you want, but some of us know better.

Quote from Tim_Taylor

I tested today - CE 8.95.7

Tested some UHD samples

ok_Sony_4K_HDR_Camp, Sony Mont Blanc HDR UHD 4K Demo, Sony Swordsmith HDR UHD 4K Demo

all with buffering issues running CE/KODI18 using wired Gb network

Files playing without buffering issues running LE/KODI17.6

Don't worry, head on over to their forum, make a post informing them of it, and they'll tell you that you're expecting too much from your hardware, and that you need to run NFS on your file server.

Quote from sky42

I just posted them as a reference if there will somebody build a 8.2.5.1. The problem should not exist in Kodi 18 and LE 9 is not so far away.

So they found their way into the Kodi 18 codebase then?

So do I understand the comments correctly that the patches to fix the issue are orphans that are going nowhere?

So what are the recommended cheap-ish 905D boxes for 4K HDR + audio bitstreaming w/ gigabit Ethernet that are fully supported by LE? I also would like to be able to control the box with an IR MCE compatible remote.

What's the extent of the patches in the 32k version? Are they limited to SMB access of .ISO files, only video playback, or is all Kodi SMB file share reading enhanced?

Quote from sky42

I added a 2nd patch and updated the test builds here Index of /testing/825-smb-chunk-32k/

So 32k version has now 2 patches.

This one has dramatically improved the network speed. Smooth .ISO Blu-ray playback is no issue now on both the Chromebox and the C2.

The Chromebox gets to the simple menu in 2 seconds now after selecting the .ISO. The C2 takes 3 seconds. Huge improvement!

Thanks for not blowing me off and telling me it's just how SMB is and to use NFS instead.

Quote from sky42

I build a 8.2.5 test version with a patch that wrxtasy suggested.

You find it here Index of /testing/825-smb-chunk-64k/

I started another build for Odroid C2 with the same patch, but when that is finished i am in bed, so that needs to wait until tomorrow morning.

Thanks for the test build.

I tried this on my Chromebox and it behaves the same as the official 8.2.5. Time to the simple menu after clicking on the .ISO is still 25 seconds and it can't play the Blu-ray smoothly.

Edit: Here's a debug log with the video and SMB component enabled: http://ix.io/1kud

I skimmed it. It seems to show the symptoms, but I didn't see a smoking gun.

LibreELEC 8.2.5 seems to have some sort of issue playing back Blu-ray .ISO files over SMB shares. Neither my HP Chromebox or Odroid C2 can play them smoothly running it (bone stock LE 8.2.5 install). On both the time from clicking on the .ISO in the file menu until the simple menu is displayed is 25-28 seconds. After selecting the title to play the throbber thingy comes up in the middle of the screen, slowly counts up to 100 and then playback starts. However, within about 40 seconds playback starts stuttering with dropped frames / gaps in the audio / stutters & pauses in the video.

In contrast the Raspberry Pi3 running LE 8.2.5 can play back the .ISO file fine. On it the simple menu pops up in about 14 seconds after clicking the .ISO. The Odroid C2 running wrxtasy's 32-bit 8.2.4.2 build of LE also can play them smoothly. With that HW/SW combo the simple menu pops up in 5 seconds after clicking the .ISO.

The same .ISO will play fine on all of these from a USB flash drive. The simple menu pops up instantly and playback is smooth from USB. The server is a Windows 10 Pro box with a 10Gb SFP+ connection to the switch and 1GbE from the switch to the boxes (except the Pi which only negotiates 100Mbit). I can get >100MB/sec copying the ISO file from the server to other PCs. Likewise I can copy data over the default SMB shares to the Chromebox and the C2 at >100MB/sec.

Forcing SMB 2 or SMB 3 from the LE menu didn't change the behavior with the C2. I didn't try that on the Chromebox.

wrxtasy suggested there is an underlying problem that's affecting multiple LE Kodi platforms and to start a thread here. I can provide logs files for troubleshooting if someone tells me what to log/do and which of the log files are desired.

To close the loop should anyone stumble across this thread in the future... This is a CPU limitation, not a disk I/O limitation. I recently received an Odroid C2 and it is only slightly faster than the RPi 3 in navigating the music library. eMMC vs. uSD makes no difference in the C2 in this regard. The Odroid C2 is only about as much faster as you'd expect for a 1.5gHz CPU vs. 1.2gHz. The Chromebox is slightly more twice as fast as the Odroid C2 (takes a little less than half the time for the artist or album list to appear).

Quote from chewitt

RPi hardware is a little fantastic miracle from a price/performance perspective and its ability to "hardware decode" 1080p video etc. but this is all about CPU and I/O from accessing the DB file. Your Chromebox has ~20x the CPU grunt of the RPi3 and probably uses higher spec/speed flash for the internal storage which is why it has no visible I/O issues. 50k FLAC files tells me you're really into your audio and quality.. so it's time to do the collection justice and get a second Chromebox (or similar).

Yes, but the Chromebox has a fan. Is it the "disk" (SD card) I/O subsystem that's the bottleneck or the CPU? An Odroid C2 with eMMC solves the disk I/O subsystem side of the equation, but doesn't have that much more CPU grunt than an RPi3.

Quote from grael

For music, I don't use tv screen to browse on my Pi.

I use yatse on an android tablet, much smoother and efficient.

I use Yatse also. It is definitely much, much more responsive. It's pretty rare that I try to navigate the music library via a keyboard or remote, but I'd like to speed it up if possible for those times. However, an Android Tablet or phone has a similar CPU to the RPi3 yet is also much more responsive with the same music library database to parse...

I'm running LE 8.1.1 on a Raspberry Pi 3 using a 64gB Samsung Evo+ U3. I have the SD interface overclocked to 83.333MHz.

I have >50k FLAC files in my music library. I don't have any other libraries on it. The UI is fairly responsive until I start navigating my way into the music section. Then it's sluggish with waiting. Like when I pick artists I get the circular throbber as it's doing something for a few seconds before I get the list. Going up one menu level and back into artists results in a similar delay.

LE on my Chromebox doesn't have anything like these pauses with the exact same music library.

Is there anything that can be done to minimize these pauses like increasing disk caching or tweaking some parameters?

Can anyone else with a Pi 2 or 3 post a screenshot of what their main Music - Library screen looks like?

So LE 7.0.2 on my RPi3 shows this for the main Music Library menu screen:

LE 7.0.2 on my Chromebox shows this for the main Music Library menu screen:

Is this a bug, some feature that's not turned on? I've scanned the same SMB network share on both systems so the music library is the same. If I pick Artist or Album from the Music submenu option on the main screen, I can see the RPi3 has a real & working Music library on it. Just nothing shows up on this screen.