may i suggest you add following patch to kodi based on work by . . .
That workaround isn't really worth a dev wasting their time on. Far better to let them get on with fixing the issues we can't deal with ourselves.
It's implementation is well known, and even simpler if those bothered select a skin with the option embedded, and just click on the 'show intro at startup' button 
7.95 Beta5 looking good so far 
kszaq: I didn't try beta4(a) yet neither the stable version too.
What stable version? 
I am not sure but i have done 35 Re-Boots and Power off/on with this Temp Sensor ENABLED Version and
I cannot get a Freeze.
Now calm down Kostaman, heed these earlier words of yours . . .
We've all fallen for that reoccurring devil bug appearing. I mistakenly flashed non temp disabled on my MiniMx 2g/16g and didn't realise for 2 days until it froze on bootup.
Seriously though, something does seem to have changed.
I presumed with the 8.0 builds it was something to do with the progression to kodi 17.0rc4. Not sure what might have changed with the 7.0 builds though. Perhaps a change in the boot order might have allowed us to get past the temp sensor initialisation :s
Looking good anyhow 
kszaq, it does begin to look like the boot freeze issue may have been a bug in the kodi code. This new build with kodi 17.0rc4, so far, has not caused a boot problem on the boxes that were frequently freezing with earlier kodi builds.
Other than these two boxes, my other boxes, e.g. Mini MX didn't have boot issues in the past.
That's what makes it so elusive. Of my two Mini MXs, one fails regularly within half a dozen boots, the other rarely (but still occasionally).
Having said that, I am also monitoring the non-crippled build on these boxes as, so far they have booted fine each time (and seem to boot a little faster). You never know, maybe if some boot procedures have been re-arranged somewhere along the line, we might not have an issue now. Can only hope
Cold and warm boot couple of times and never missed one!It seems kszaq did something in the kernel to circumvent the u-boot bug. A temperature sensor disable build is no longer need. Thanks so much for your hard work.
I'd be checking more than a couple of times, it can take 50 boots or more to surface
Which Device Tree should I use to have everything working?
From O.P. of this thread . . .
For installation instructions refer to 7.0 builds, e.g. thread-3588.html
Your answer is on O.P. of that thread
[hr]
kszaq, There is no temp-sensor-disabled build of beta4. Does that mean we don't need it, or is it just not ready yet?
Can someone tell me how to replace the dtb file on the
internal installation without losing all the data/the installation?
rename the *.dtb file to dtb.img and copy it to /flash via SSH
That is why I asked this question in the first place - I cannot seem to find any relevant info, so I was hoping to maybe get some info from someone who tried it or knows more. But thank you anyway.
I tried to flash these files but the installation fails every time as reported here. Unfortunately, Merziyas has not replied as to which box he was able to see a result using this, so I decided best leave it alone. If it does actually do something on some devices, it most likely disables the temp sensor as a workaround, which kszaq is already doing.
What is this Update Channels used for ??
Something to do with PVR and Tuners I'm guessing.
I've never gone down that Road.
I believe the update channel pertains to the mainstream LibreElec builds, not this port specifically for Amlogic devices (for which there is no update channel available). This section should be left at it's defaults, since it is not intended for these builds
I would advise you a well known box like Mini MX III 2GB (with S905, not III-II), the components are stable now. Only drawback : wifi has poor speed.
EDIT : I missed you request for dual wifi ... forget my advise.
Which brings you to the Beelink Mini MX III II, which does have dual band WiFi and the extra decoding that the S905X can handle. No issues with this box and well within your budget
RayW, since normally it is not required to switch between Wifi and eth connections, have you considered putting something into autostart.sh to disable one or the other at boot as a workaround?
- I have downloaded the beta3 file and used the LibreElec CD creator to burn the files to the SD card
- I have downloaded the Device Tree file that has RTL in it as the link above says it has a Realtek wifi. I have then copied that to the SD card, deleted the existing dtd.img file and renamed the device tree file to that.
- I have then put in in the m9+ box and used the tothpick to reboot it, kept the toothpick in
The bloody LibreElec logo never appears... have kept it pressed down for up to two minutes.
If you renamed the device tree dtd.img, as you state, then that is where your problem lies - it should be dtb.img
Negative (high priority):
- My biggest concern right now: I have regular frame skips. These occur in various (all?) normal h264 and x264 encodes I tested, both 720p and 1080p. All are clean encodes which work flawlessly on the Pi. I think all were 23.976Hz. Frame rate switching is active and does seem to work.
Maybe I am making some mistakes too and there is a simple solution for some things?
I had the same problem with one of my TVs (Toshiba). The only workaround I found was to disable 24Hz frame rate switching.
when using the kodi start-up animation, whereby a 'ghost image' of the last frame of the animation is displayed momentarily before the animation starts.I have not seen this issue with the normal build, is there some cache that is not being cleared in the crippled builds?nvm: I've now seen it on the normal builds as well. (Maybe more to do with the animation itself)
It seems to be present with all animations more often than not. LE bug or kodi bug, I wonder ?
exactly. more of a workaround than a fix, but it works seamlessly. I made a mini how-to for those who like to try this.
Excellent, glad you're sorted now
zackito What, the browser?
