OK just post the crash log with MQ8 on the Kodi forum as Kodi shouldn't be crashing, but MQ8 could be doing something weird.
Posts by milhouse
-
-
When reporting bugs in the RPi test thread you should be testing with stock Estuary.
If the bug is only reproducible with MQ8 then it may still be investigated but probably at a lower priority and may require the involvement of the skin maintainer, so reporting it to the MQ8 forum isn't entirely wasted effort.
But if you want it fixed then a crash log with stock Estuary and debug logging enabled posted to the Kodi forum test thread is your best bet.
-
You should post your crashlog in the Kodi RPi test thread where these RPi builds are announced, as that's where the support is, not here. Try testing without Yatse. Enable debug logging when reproducing the crash.
-
Do post an update if installing python3.6 works - I'm not entirely sure if that is the correct solution (although it may avoid the issue) as I don't know why the python3.6 package would need python3.6 in the build host (and why python 3.5 wouldn't be used)... there may be a cross-compile issue here.
-
Do you have python3 installed in docker? Maybe that's required for the build - it looks like python2 is being used to execute subprocess.py.
-
Netflix isn't supported by Kodi 17.6 in LibreELEC 8.2.3, and for that reason Pycryptodome is not installed.
Netflix needs Kodi 18, and Pycrptodome is now pre-installed in LE 9.0 alpha builds, where Kodi 18a1 does indeed falsely claim that Pycryptodome is not installed - this is a Kodi defect that you can ignore.
-
No, use an alternative pastebin site such as pastebin.com
-
SMB has nothing to with the web server - are you sure you're accessing the Kodi web server on the correct port (default :8080)?
-
When I leave the raspi on minim smb protocol smb2, and I can't use web interfaces anymore.
This makes no sense. Post your debug log.
Is it safe to leave the raspi on smb1, and any computer trying to connect at smb2?
No.
-
-
Why hasn't anyone posted a debug log yet?
-
You'll need to adapt the script to work with the different hardware. If you can do that then it should work, but there'd be no guarantee.
-
You define LE as an embedded product sealed for the benefit of the user.
That's not my definition. I said the system being read only is a secondary benefit - user safety is not the reason for shipping a read-only file system.
At the same time you say it is an open system.
The code is open source, but the file system we distribute is read-only, in much the same way as most embedded solutions are. This is not to stop users from tinkering, but because it's created as a compressed squashfs which is the easiest way to distribute a single binary image.
Im afraid there are too many HW permutations to allow this strategy. You will most likely have to allow some access to handle such problems.
HiassofT has outlined the solutions for you, which don't require any changes to the LibreELE read-only filesystem (by which I mean the root filesystem, not /flash which is made read/write with a simple mount command). The problems you think we face have already been solved.
-
It claims to work with LibreELEC.
-
I think lot of users would like to turn libreelec in of state that only turns HDMI off but keep Libreelec running for samba and ssh.
If you only want to use samba/ssh why not just unplug the HDMI cable? Or add the vcgencmd command to autostart.sh. Are you even using Kodi at all?
You can probably map a script to a Kodi remote button if this is what you want - it's a little hard to understand from your post.
You can also use Asavah's pidisplaypower screensaver Kodi addon which will automatically turn off the HDMI after the configured idle period, and any button/input will turn the display back on: GitHub - asavah/script.pidisplaypower: Screensaver for Kodi running on raspberry pi that turns display power off by using vcgencmd display_power command.
-
I can‘t say that I like this rock solid write protection.
I think you misunderstand the purpose of the squashfs filesystem - LibreELEC is an "embedded" product and a read-only compressed image is the best and most convenient solution for distribution, and has nothing to do with "safety" although admittedly that is a secondary benefit.
Many config files can in fact be modified, but not all services support this so If you can explain what files you want to modify maybe more focused advice can be given.
Most of all I thought this SW was meant to be open to the community for fine tuning and experiments or did I get the wrong message?
There's nothing "closed" about LibreELEC, you just need to understand what it is and, perhaps more importantly, what it isn't.
-
We recently removed older firmwares as they're just a waste of space since almost nobody is using these older devices (some of which are only capable of 802.11b). Your device probably falls into that category and is now missing firmware.
We're willing to consider adding the firmware file(s) back when users work with us and help us identify the required firmware, but I guess you're not willing so enjoy OpenELEC and see you again in a few months.
For obscure hardware we can also tell you how to install the firmware yourself, which would get you up and running with LibreELEC in a few minutes, but unless you tell us the required firmware by providing "dmesg" details we can't help you.
-
H264 10bit playback should be improved with RPi LibreELEC 9.0/Kodi 18 test builds.
