Posts by jbinkley60

Quote from thereddestdog

Long story short: There is some sort of hardware audio bug with NUC11 devices and LibreELEC, which causes the audio driver to break until I reboot the machine. Very frustrated with it, and not able to solve it (check my post history..)

Currently using the Intel NUC11PAHi3, and I want to get a new NUC or similar with which I can simply move the SATA SSD and not have to set up everything again like a fresh install. Potentially like the ASUS RNUC13ANKI30000UI for instance

Is LibreELEC picky about booting on similar x86 hardware? Anything I need to know?

Good luck on whether the ASUS NUC will resolve your audio dropout issue. See my response on this thread. I've given up on the Intel platform for now and bought a Beelink with AMD. So far it's been rock solid and no dropouts.

Thanks,

Jeff

Quote from racemaniac

I also use a Denon receiver and have the issue.

I did find an interesting thread on the Kodi forum where they found the same (or at least very similar) issue, and think it's an issue with the audio clocks in that mode causing issues:
https://forum.kodi.tv/showthread.php?tid=372242&page=3

They made this ticket for intel: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/8276

Sounds very close to what we're experiencing.

And after reading their thread, if taking the Denon receiver out of the equation solves the ticket, we should also test a non intel source on the denon to see if the issue persists. Because if other devices can perfectly play 4k hdr 24p through the Denon receiver, and only with intel we get the audio dropouts, it's some incompatibility between intel & Denon that coulds still have the root cause at either side.

Display More

I've been watching this thread for a long time and have had an Intel NUC (8i7BEK) and a newer N100 working with a Yamaha RX-A3080 AVR. Both Intel platforms have the same audio dropout issues with Dolby Atmos and other bitstream audio sources. I've been living with this issue on Intel for a few years.

I recently switched to a Beelink SER6 platform with an AMD processor and GPU. So far no dropouts with my Yamaha AVR. I realize it's way overkill but it's also lightning fast and no more dropouts. Prior to the Beelink SER6 I had tried a Raspberry Pi 5 for a few months with my AVR and no dropouts either. All running prior and the latest versions of LibreELEC.

I even tried OSMC and the Vero 4K+ and Vero V with no dropouts. Only LibreELEC with the Intel platforms have dropouts in my setup. I've not tried running Windows / Kodi on any of the Intel; mini-PCs.

Thanks,

Jeff

.

Thank you so much for LibrELEC 12.0.1 which has Kodi 12.1 and has the fix for the stereo upmix issue. I can confirm that I have my left front speaker back now when using stereo upmix with 2ch audio sources on an N100 box.

Jeff

You can use an internal SSD with a Raspberry Pi 5. Here's a picture of my test unit. SSDs do increase the price of the Raspberry Pi 5 to where an N100 box is close in overall cost and performance.

Jeff

The point I was trying to make earlier in my post but got a bit off track with the numbers is that I agree with you. An SSD will help with storage I/O but most folks won't see much of a difference. I have a few Raspberry Pi devices and only one has an SSD, my test unit and that was mainly to see what was involved in adding an SSD. SD card reliability has improved but isn't at the level of SSDs. Reliability would be the main thing which would drive me to put an SSD in a Raspberry Pi.

Jeff

Quote from LeannLL

Hi

In Internet and Youtube I saw “It’s time to ditch microSD”

I'm still new to Raspberry and co.

A MicroSD card is much easier to use. Have you installed an SSD in your Raspberry 5? My main use case is streaming from Jellyfin server (network traffic). Can anyone say whether the performance is significantly better with SSD instead of SDcard?

best regards

I view the SSD vs SD card discussion more of a question of reliability vs. performance with Kodi / LibreElec but SD card reliability has improved significantly over the past 5 years. As mentioned above the main advantage of SSD for performance is disk I/O. I run Mezzmo, which is similar to your Jellyfin server, and have an endpoint performance Wiki page where I compare certain performance characteristics.

The displaying of 150 items is mainly a function of computing power to parse the server response and display the items in LibreElec. The full sync compares disk I/O. This particular Raspberry Pi 5 being tested has an SSD in it for the Kodi database. If I switched it back to the SD card I suspect the performance would drop by 2-3X but the Mezzmo sync progress is a background process so the user is unlikely to see the difference. I am not sure how Jellyfin syncs the client to the server but I believe it does based upon the operating mode. If there is interest I can switch back to the SD card and post the comparison results ? The Raspberry Pi 4 listed is running an SD Card.

Thanks,

Jeff

So interestingly enough I upgraded VMWorkstation to 17.5 on my other server and Kodi running under Windows 10 on a Guest VM stopped working due to display driver issues. I ended up solving this the same way I did for the LibeElec OVAs. I had to do 3 things.

First, change the VM hardware compatibility for the Windows 10 Guest running Kodi to VM Workstation version 12.0. Second replace the ATI video card with the nVidia video card and third add the same mks.enableGLRenderer = "TRUE" configuration line to the VM config file.

Jeff

Quote from chewitt

The DXxxRenderers config probably has no effect as DX display drivers are a Windows thing. Enabling GL should be be the only config item to have impact, though I'm wondering if that truly means GL (only)? as GBM images are using GLES not GL (as shown by logs that heitbaum shared).

Yeah, you are correct. Only mks.enableGLRenderer = "TRUE" is needed. Interesting that it doesn't work with my ATI card only the nVidia card. At least I found a solution.

Jeff

To update further, the trick of adding these 3 lines:

mks.enableDX12Renderer = "FALSE"
mks.enableDX11Renderer = "FALSE"
mks.enableGLRenderer = "TRUE"

only works with my nVidia 710 cards and not my ATI Radeon 5450 video cards. I had to put the nVidia card back in my 17.5 system and both OVAs started working. With the ATI card I get an error about a bad value with the mks.enableGLRenderer = "TRUE" statement. The good news is that I have more of the nVidia cards laying around and they are still available for purchase.

I did some further reading and VM Workstation 17.5 wants video cards which support DIVX 11.1 and mine are older and limited to 11.0. I suspect that may be why others are working, depending upon the video cards and how new they might be.

Jeff

I found an answer here. I had to add these 3 lines to the virtual machine VMX configuration file.

mks.enableDX12Renderer = "FALSE"
mks.enableDX11Renderer = "FALSE"
mks.enableGLRenderer = "TRUE"

With them both the 9.2.6 and 11.0.6 OVA run properly under VM Workstation 17.5. There are a number of reports on the Internet about the graphics changes which VM Ware introduced with 17.5.

Jeff

Quote from vpeter

Here vmware workstation 17.5.1 works with LE 11 and LE12 - using vmware gpu (no passthrough).

Did you install the OVAs or create an ISO image and do a native VM Workstation installation ? Also, what host OS are you using, not that it should matter ?

Jeff

So the issue is definitely related to workstation 17.5. I loaded VM Workstation 15.5 on my Sandbox machine with the Nvidia GeForce 710 card. Both the 9.2.6 and 11.0.6 OVA loaded right up and came up with no issues. I then upgraded to VM Workstation 17.5 and both working VMs stopped working. I tried uninstalling 17.5 and installing it from scratch and still it doesn't work. I also tried pulling down the most recent version of 17, version 17.5.1 and that didn't work.

Lastly, I loaded Workstation 16.2.5 and that works. So there is something with Workstation 17 which is causing the issue.

Thanks,

Jeff

So the mystery deepens. I replaced the nVidia card with an ATI Radeon 5450 card, the same that is in the 1`5.5 machine The problem persists with Workstation 17.5. So right now it appears to be something with Workstation 17.5 or something else with this particular machine.

To isolate this once and for all, I have a third Sandbox test machine which has the same nVidia GeForce 710 card in it and the same hardware. I will install 15.5 on it, see if both the 9.2.6 and 11.0.6 OVAs work. If so, then I will do the in place Workstation upgrade to 17.5 and see what happens.

I'll keep folks posted.

Jeff

Quote from chewitt

First update the vmware hardware version on the 17.5 version, and if that makes no difference, then do that.

No difference with either, it still hangs at the LibreElec screen.

Jeff

Quote from chewitt

For kicks, can you update the 17.5 system to a currently LE12 nightly and see what happens?

Sure. Just so I am clear here. I will move the 11.0.6 OVA to the 15.5 system, upgrade it the latest LE12 nightly, then move the upgraded Kodi OVA back to the 17.5 system and see if the VM runs ?

Thanks,

Jeff

Quote from chewitt

Use snapshots or clone the disk for experiments. Are you mapping the GPU in the VM or using the vmare GPU?

Yeah, moving VMs across hosts and making copies is easy. I have VM workstation set for auto, which uses the VMware GPU. I cannot find a way to change the video card / GPU setting in VM Workstation. I did however take 2 debug logs in Kodi.

The first is the Kodi 11.0.6 VM running on the 15.5 system with the ATI Radeon card.
The second is the Kodi 11.0.6 VM running on the 17.5 system with the nVidia 710 card.

It's the same VM just copied between systems to do the testing.

Thanks,

Jeff

Quote from chewitt

The "Generic" image switched from Xorg to GBM graphics but IIRC the vmware GPU in the OVA should support that. However if the host GPU has been mapped through to the VM this will 100% fail on nVidia cards as there is no support for them without Xorg.

NB: I've been told the virtual hardware version of the OVA needs bumping for Workstation 17.5 (and likely other recent versions) but that something which can be tweaked locally.

I've tried every setting I can think of in the host OS and VM workstation Guest VM and can't get the Kodi OVA to work with Workstation 17.5. They work fine with 15.5. Worst case I do have a spare ATI Radeon card I can try swapping in the 17.5 system or I can upgrade the working 15.5 system to 17.5 and risk having 2 broken systems for Kodi

Jeff

So I have been picking away at this very issue and have some information. I recently upgraded VM Workstation from 15.5.0 to 17.5 and I had a LibreElex 9.2.6 OVA that was running and stopped after the VM Workstation upgrade. It starts and goes to a black screen. I moved the OVA over to another machine still running VM Workstation 15.5 and it started working again. I also tried installing the LibreELec 11.0.6 OVA on the VM Workstation 17.5 machine and it hung after starting. I moved that OVA over to the VM Workstation 15.5 machine and it worked fine.

So the issue is definitely related to Workstation 17.5 but there is also one other difference between the systems, which I believe may be the real issue. The Workstation 17.5 machine has an nVidia GeForce 710 card and the Workstation 15.5 machine has an ATI Radeon 5400 video card.

I need to do some testing with either upgrading the 15.5 to 17.5 with the ATI card, swap out the nVidia card to an ATI card or if you want me to move a working OVA back to Workstation 17.5 and grab some Kodi logs, just tell me what you need. With 2 systems and working OVAs I can easily do testing. I'd like to get this working on Workstation 17.5

Thanks,

Jeff