[macauleyr4]

@schamane

Here's a pvr.hts compiled the other day and is working with the kodi build from 28th of Feb. Its not zipped correctly to install from the UI so unzip and manually move to ~/.kodi/addons folder.

[schamane]

Thank you, will give it a try when I am at home.

[soder]

I got a question, or request, that might sound strange.

I use these EGL versions on my NUC, and running MySQL against my old HTPC with the standard OpenELEC stable version.

Since I got an older Nvidia graphic card in the HTPC, it's no longer gonna be supported by OpenELEC. The last year I've been using the special nvidia build for this old HTPC. I know it's a strange way using this old HTPC, but it's been working for me and I got a lot of services running on it that I want to continue doing.

I will now update my NUC to the latest OpenELEC-Generic.x86_64-6.0.398-Intel_EGL which I guess gonna work fine. My problem is that I will soon install Kodi version Jarvis on my Mac and soon will OpenELEC be updated with Jarvis, and my problem will then be my MySQL database version that is running on the OpenELEC version on my old HTPC.

My question, or request, is if there's a way to still making versions of OpenELEC that I can run on my old HTPC, still with the old version of the nvidia card and drivers.

I know this is strange, but I kind of need to have it that way right now.

Thanks.

/Söder

[Desty]

Hello,

The dropbox link (image file of Matt Devo) on the 2nd post does not work. Can somebody please fix that?

Thanks

[fritsch]

Fixed.

[_Spook_]

Any fix to the black screen on boot?

fritsch if you let me know what logs you need I maybe have some time later tonight

[fritsch]

No - as my screen is not black.

Hint: Always post what the second post wants.

[tovaxxx]

My screen is black on boot, too.

[Roby77]

Try using Custom EDID guide: http://wiki.openelec.tv/index.php/Config...#tab=Intel

talking about it ...is there a command via ssh to check that edid is correctly loaded ? like xrandr --prop or verbos to check video output

(i'm sure that is loaded correctly cause dts-hd and true hd in audio settings are available even if amp is not switched on before htpc.....just curious)

[n2vwz]

Attn: Fritsch

I have encountered a problem with the recently released 'OpenELEC-Generic.x86_64-6.0.298-Intel_EGL' and 'OpenELEC-Generic.x86_64-6.0.398-Intel_EGL' firmware. The OpenELEC/Network/Advanced Network Settings/Kodi startup time delay function has stopped working. I can specify any delay time but the resulting delay is always zero.

I was previously operating with 'OpenELEC-Generic.x86_64-6.0.198-Intel_EGL' with a 2 second KODI startup delay without any issues. Without the startup delay, my NAS Shares cannot be seen or take several minutes to appear.

I'm running an Asus Chromebox.

Please advise on where the problem might lie and any recommended solution.

Thanks

[Matt Devo]

Attn: Fritsch

I have encountered a problem with the recently released 'OpenELEC-Generic.x86_64-6.0.298-Intel_EGL' and 'OpenELEC-Generic.x86_64-6.0.398-Intel_EGL' firmware. The OpenELEC/Network/Advanced Network Settings/Kodi startup time delay function has stopped working. I can specify any delay time but the resulting delay is always zero.

I was previously operating with 'OpenELEC-Generic.x86_64-6.0.198-Intel_EGL' with a 2 second KODI startup delay without any issues. Without the startup delay, my NAS Shares cannot be seen or take several minutes to appear.

I'm running an Asus Chromebox.

Please advise on where the problem might lie and any recommended solution.

Thanks

assuming you're referring to the 'wait for network before starting Kodi' setting, a minimum timeout value of 10s is advisable, regardless of wired/wireless. Any changes between .198 and newer versions were to correct an issue with that setting not working with Wifi connections, and may have added another 1-2s for wired connections to become available as well.

[n2vwz]

Attn: Fritsch

I have encountered a problem with the recently released 'OpenELEC-Generic.x86_64-6.0.298-Intel_EGL' and 'OpenELEC-Generic.x86_64-6.0.398-Intel_EGL' firmware. The OpenELEC/Network/Advanced Network Settings/Kodi startup time delay function has stopped working. I can specify any delay time but the resulting delay is always zero.

I was previously operating with 'OpenELEC-Generic.x86_64-6.0.198-Intel_EGL' with a 2 second KODI startup delay without any issues. Without the startup delay, my NAS Shares cannot be seen or take several minutes to appear.

I'm running an Asus Chromebox.

Please advise on where the problem might lie and any recommended solution.

Thanks

assuming you're referring to the 'wait for network before starting Kodi' setting, a minimum timeout value of 10s is advisable, regardless of wired/wireless. Any changes between .198 and newer versions were to correct an issue with that setting not working with Wifi connections, and may have added another 1-2s for wired connections to become available as well.

I'm running a wired connection. I started out with a 10s delay on .198 and was able to reduce that number to 2s and still have reliable operation.

On .298 and .398, the delay is zero regardless of the number that I specify. That's the problem I am trying to describe. This looks a like a new bug.

Meanwhile, I've switched back to .198 and the delay is working correctly again. Again, I'm using a wired connection, not wireless.

[Matt Devo]

I'm running a wired connection. I started out with a 10s delay on .198 and was able to reduce that number to 2s and still have reliable operation.

On .298 and .398, the delay is zero regardless of the number that I specify. That's the problem I am trying to describe. This looks a like a new bug.

Meanwhile, I've switched back to .198 and the delay is working correctly again. Again, I'm using a wired connection, not wireless.

I'm not able to reproduce that here. The delay isn't an absolute value, it's a maximum wait time until the network is up; wired connections are going to be nearly instantaneous, so the delay will likely appear to be zero. What sort of network connections / mappings are you using such that this isn't working?

[n2vwz]

I'm running a wired connection. I started out with a 10s delay on .198 and was able to reduce that number to 2s and still have reliable operation.

On .298 and .398, the delay is zero regardless of the number that I specify. That's the problem I am trying to describe. This looks a like a new bug.

Meanwhile, I've switched back to .198 and the delay is working correctly again. Again, I'm using a wired connection, not wireless.

I'm not able to reproduce that here. The delay isn't an absolute value, it's a maximum wait time until the network is up; wired connections are going to be nearly instantaneous, so the delay will likely appear to be zero. What sort of network connections / mappings are you using such that this isn't working?

The delay is needed and used to be present on wired connections. With .198, if I punch in a 60s delay, I must wait 60s for KODI to start. With .298 & .398, if I punch in 60s, the wired connection is instantaneous. Because no delay is present, my NAS shares cannot be seen. I need a minimum delay of 2s on a wired connection for proper operation. The delay needs to be restored for wired connections like it was on older versions.

[Matt Devo]

The delay is needed and used to be present on wired connections. With .198, if I punch in a 60s delay, I must wait 60s for KODI to start. With .298 & .398, if I punch in 60s, the wired connection is instantaneous. No delay is present and my NAS shares cannot be seen. I need a minimum delay of 2s on a wired connection for proper operation. The delay needs to be restored for wired connections like it was on older versions.

given that the only actual difference (affecting the x86_64 version) between .198 and anything after is the WiFi startup / network delay fix, your best bet is to stick with .198. I'm not going to be chasing issues on OE6 builds since Kodi 15 is now 2 versions back from where development is focused, and fritsch moved on long ago. If it's an issue on these Kodi 17 test builds still, then it's something we can investigate