It should be
It should be
Hi Roger, Gordon mentioned months ago, that the best disk format for speed is ext4.
He mentioned it could use 10% less CPU, thus allowing snappier response.
That’s what I’ve been using from day 1, never had any disk complaints.
I will try and find time today to create a build with the changed upnp.cpp
thanks, as part of testing and exploring, I thought I would explore all options, and I note your / Gordon’s comment. I will revert to exfat at some point. Don’t you ever want to take apart the new vacuum / washing machine / other device just to see how it works
Anyway, maybe good if someone tests NTFS for a while in the bloody builds. I am only using Slice for music so maybe the performance hit will be less than video. I am using FLAC files though, so will be a fair amount of disk reading compared with MP3.
why the very slow (max 75kbps ish) download rate, it is what kills the Slice update process as it takes soooooo long
PS, now I have the download (well in an hour or so…) replacing / testing will be much faster!
Everything I own has, or will be, opened up and or hacked in some way, even if it’s just to see how it’s done.
I enjoy keeping stuff running until they completely run out of steam, one way or another.
Kevin, me too… my daughter’s BF says isn’t there anything your dad can’t fix Roger
download, update OS and test with existing library: still alpha sort
reset openelec (soft) and rebuild library
test again:still alpha sorted
If you do another build, can you specify if you want an openelec soft reset done or not… saves time if not
Not sure why you’re getting such slow throughput, the updates.fiveninjas.com isn’t the bottleneck and my box here gets around 4MBytes a second… Are you sure it’s not a local problem?
Just tested here getting healthy 4.5 here
I downloaded a test build from Mike fine, in no time at all.Other downloads work fine.Pi Jessie was fine yesterday too.
The one for slice has always been slooow, not just today.
Almost as slow as a steam-driven analogue modem
It makes testing a bit of a pain, but now the download has completed at least I can copy it to the Slice… until you provide a new bloody for testing!
What about if you download the link I send yesterday? Is that slow as well?
yes it was. EDIT: to clarify both downloads direct to slice using the update function and download to a windows PC from the site are slow.
much later , the following day … Update: if there is not an obvious reason, years of computing have taught me to think outside the box… Gordon’s download was slow, Portable Apps LibreOffice was slow but not much else… … having slept on it, I reset the QoS settings in my router to default and rebooted it: both slooooow downloads now work fine. Gordon’s being the second one, and with a different source download server was the (tenuous) clue.
Happy now, and y’all no need to worry about a server issue at your end
Strange, very strange indeed.
Re the LEDs
extract the following to the configfiles share on the slice, or /storage/.config
let me know if that works for you
@MikeBuzz, does your file implement what was suggested here, ie. red both on power down and power up, or just power down??
Suggestion: make Slice display red LEDs on power off so you know it
is safe to unplug. Is it possible to set the LEDs to red on acting on a
power down request and for them to remain so. They should be set as the
last thing done before ‘control is lost’ and if we count to 10 then we
know it is OK to remove power.
Nice to have: do the same thing on reboot so we can see progress, LEDs go red then go out as the Slice starts its reboot.
As you described, only happens on reboot or power off, having it on power up seems a bit pointless as we have the startup pattern
yes that works fine for reboot and power off. A question: On power down, when the LEDs turn off, is there a wait period needed before removing power and if so, what? If needed, it may save support issues in the future by avoiding (potential) corruption to memory / hard disk / removable media. If none needed: even better. A bit like waiting for the green LED on a Raspberry Pi to finish flashing before removing power.
But: the action of the LED meets the NFR (new feature request) perfectly, thanks.
Ah! to clarify, tested on the build you did for me the other day
Slice (unofficial) Version: devel-20150930103019-r21394-g323b257
Slice git: 323b25791854895e6fdcd06d7ae5192c7906a42d
copying the files will work on any build.
The LED’s will remain lit until the system is total shut down, so you would be fine disconnecting the power once the LEDs go off
Perfect: a truly “idiot-proof” solution!
However, from my system design days, I do recall “to make things foolproof is easy, to make them idiotproof is nearly impossible”