RPi hardware is a little fantastic miracle from a price/performance perspective and its ability to "hardware decode" 1080p video etc. but this is all about CPU and I/O from accessing the DB file. Your Chromebox has ~20x the CPU grunt of the RPi3 and probably uses higher spec/speed flash for the internal storage which is why it has no visible I/O issues. 50k FLAC files tells me you're really into your audio and quality.. so it's time to do the collection justice and get a second Chromebox (or similar).
Posts by chewitt
-
-
-
No idea. First I heard of that issue. Kodi debug log from a clean boot and demonstrating the problem would be a good idea.
-
DIsable LIRC .. as clearly documented in the release notes that nobody reads.
-
The fix went into 8.1.2
-
What Windos OS base is WHS?
-
It's a binary add-on that must be compiled, it cannot be simply downloaded and installed. I'm not sure which repo this is distributed from..
-
^ now edit EnableOnlineCheck to false and it will not perform the check. However, reading the text in the file it will remain in READY state and may not go ONLINE automatically. I'm not sure what the implications of that are (and I'm not near a box to test).
-
-
Intel has a habit of adding regressions for older hardware as they introduce support for newer hardware. In this case the reason newer OE has given you issues vs. older OE is very likely that the combination of GPU drivers + mesa + Xorg have changed and I doubt anyone from Intel (or anywhere else; definitely not us) tests that combination of old hardware. In this respect LE will be no different to OE as we track/update the same combination of code parts. The main difference is that the entire ecosystem that surrounded OE is now resident here so you'll get answers to posts - although maybe not the answers you're looking to hear, e.g. the comment on the RPi is completely true.
If you run "cat /var/log/Xorg.0.log | paste" we can see if Xorg is starting and what errors are logged - although Intel drivers aren't very verbose.
-
In 99/100 cases the failure is due to a lack of clean shutdown in Windows; Linux will not mount the "dirty" NFTS filesystem to prevent corruption. If you run "dmesg | paste" and share the URL we can see the mount failure in the system log and hopefully confirm.
-
Connman is integral to networking in our OS and something is abnormal for it to generate that many requests. If possible please capture and share a pcap of the box coming on to the network along with the system journal log for that boot.
-
-
Backwards seek is/was one of the main unresolved issues for AML users on Krypton and the 3.10 kernel used on WP1 isn't the focus for most of the developers. There are seeking improvements in the Leia codebase but that's still a long way from being stable or something we'll produce alpha releases for, and unfortunately Leia has diverged far enough from Krypton to prevent simple backporting of the changes. TL/DR; it is what it is until Leia comes along.
-
This is the correct way to put /storage on NFS: Network Boot - NFS - OpenELEC
-
That will not be the PERFECT solution because all we do is detect it's an old config and rename it out of the way. Samba will then start with our default template and whatever customisations you did before will still be missing. We make no attempt to fix your previous config .. that's your own problem to solve.
-
Worst that can happen is you miss the 5-second window to type run and then it boots into the graphical installer where to actually screw things up you need to select install to the internal HDD and confirm (twice) that you want to nuke the contents of the disk. Users never cease to redefine our boundaries for the definition of stupid, but assuming you're not it's a safe process.
-
It's usually a problem with the IPTV source and/or bandwidth. Share a Kodi debug log and we might be able to tell more.