Posts by jbinkley60

I wasn't able to get to disabling the addon with the GUI. The Kodi crashes were happening too quick. Deleting the addon code files in safe mode via SSH was the cure. I had the same thing occurring on my Vero 4K+ units running OSMC. The same approach worked for them too.

My issue is resolved. I was behind 2 versions of the PVR addon running version 2.0.1 . The bug was fixed in 2.02:

v2.0.2 (2019.05.08)

- Update SQLite database engine to version 3.28.0

- Prevent multiple Kodi threads from simultaneously requesting EPG data

- Prevent individually malformed EPG data request results from aborting all remaining requests

- Fix bug that allowed extraneous EPG entries to be transferred to Kodi

- Fix bug that prevented successfully setting channel visibility flags

- Fix bug in database layer that could cause unhandled exceptions processing NULL column values

I've updated to 2.03 and the issue is resolved.

Ok, so I answered my own question. I found the kodi.FAILED folder. I deleted both the HDHomeRun addon and the unofficial HDHomeRun PVR addon and things stabilized. I reinstalled both one at a time and Kodi started crashing again once I installed the unofficial PVR client and it started processing the guide. I've placed a note in the HDHomerun foorum where the author closely monitors: Right now I am leaving the PVR client removed and things are stable.

I am convinced the HDHomeRun PVR Addon is likely causing the issue because the reboots occur while the EPG is being updated as soon a Kodi comes up. How were you able to disable the addon because in Safe mode it isn't installed and thus is stable ? I am stuck in a loop where the reboots and Kodi restarts occur faster than I can do anything in normal mode.

The 3 Addons which were automatically updated yesterday were:

Universal Artist Scraper

Universal Album Scraper

The Movie Database

I am seeing the same thing on my Intel NUC. It started a couple of hours ago. I haven't done any troubleshooting yet but it's been rock solid and never booted into safe mode until now. I had the same behavior, multiple reboots and then boot into safe mode. At a causal glance I see where some add-ons automatically updated today. I'll watch this thread and see what comes of this before doing anything else.

Have you disabled the low level noise option in the Audio settings within Kodi ? If not, I'd try that first.

I'll give that a shot and see what happens. My issue is related to when I run two interfaces out of my NUC and then switch away and come back. From what I know the autoexec.py file only runs when Kodi starts. In my case it disappears when running and a restart will fix it but that doesn't solve the fundemental issue. I will give it a shot and see what happens.

Is this what the screen looks like or similar ? Just wondering if it is the same thing I was seeing.

All of my testing above was done using Mediainfo to report on the bitrates. My testing was with a 3B+, with heatsinks and HW decoding enabled.

Are you running multiple video (i.e. HDMI and display port) outputs off of the NUC ? I've had this same problem when running multiple outputs. I ended up getting an HDMI splitter to resolve.

I continue to work on solving this issue. So far I updated the goFanco HDMI splitter to the latest firmware and updated the Intel NUC to the latest BIOS, v71, which just came out last week. Neither have resolved the issue. I opened a ticket with the goFanco folks and they have been extremely responsive and are looking into the splitter software, specifically the EDID parameters which are being presented to the NUC. They sent me a utility today which I loaded on a laptop and hooked the laptop HDMI output to the Yahama AVR. The software then was able to query the EDID responses from the Yamaha AVR receiver.. They are currently analyzing the data. They did have been try some configuration changes which do manipulate the EDID being presented to the NUC. That did not work. Hopefully the EDID dump will be useful in determining the issue. Through all of this the OSMC Vero 4K+ continues to work properly but from what I can tell it has a more fixed EDID configuration and doesn't appear to learn all of the EDID information from the external sources, just some of it.

A few months back I did some HEVC testing with various bitrates and a Raspberry Pi 3B+. here are the results:

Raspberry Pi CPU utilization results:

Failed either means the Raspberry Pi GUI locked up or typically the audio / video got so far out of sync it was unwatchable. I suspect due to video frame drops at high CPU utilization. However, playing 15 mbps HEVC was better than I expected.

Do you have Raspberry Pi heat sinks installed ?

You might want to check on your receiver what type of audio signal it is receiving. When you enable the sync display option look at the notes at the bottom of the screen. It says that when enabling sync display passthrough audio is not used by the player, even if you have it enabled. You do get sound but when I check on my Yamaha receiver I am getting PCM audio vs. DTS-MA or True-HD. This indicates that passthrough is being bypassed. When I use my Vero 4K+ and do not enable the Sync Display option I see the DTS-MA and True-HD being delivered to my AVR.

I've been thinking about that, at a minimum a TV which has HDMI 2.0 and supports DTS-MA or True-HD although most TVs don't supply those codecs.

On a whim I tried the latest Milhouse generic build from May 9th and I am getting the same results. Researching further I found this thread where there is a comment with regards to passthrough issues and v5 kernels. I am trying to find a 4.19 kernel build and see if it has coffee lake drivers.

Quote from HomerJau

The later Milhouse LibreElec 9 for Kodi 18.2 (Generic) test builds using Linux 5 have ALSA problems on NUCs (no Passthrough Audio). I’m hoping this will resolved with official LibreElec 9.0.2 build.

I’ve had to stay with last Milhouse LE build using Linux 4.19 to use Passthrough.

Which Milhouse build ar you running for passthrough and what NUC hardware are you running ? I am struggling with bitstream passthrough on a NUC 8.

I have a 5th and 6th generation NUC and they work fine with older and newer LibreElec but they run HDMI 1.4a. I went to the 8th generation NUC to get HDMi 2.0 which my older receiver doesn't support, hence the splitter which is much cheaper than a new receiver.. Since the NUC works when connected directly to the AVR running HDMI 1.4a, I don't know if the issue is because of something the NUC is seeing from the splitter (i.e. EDID but that looks normal) or because the driver has a bug when running in HDMI 2.0 mode. I suspect the latter especially since the Vero 4K+ works fine and the NUC does for non-bitstream formats. I can't use an older version of LibreElec because they don't have the Intel drivers for an 8th generation NUC. That's what got me here. I'd love to find someone who has an 8th gerantion NUC, running HDMI 2.0 with LibreElec and can tell me whether bitstream is working or not.