is it counting all cores so maxing out would be 400%?
Yes. The last value is the sum, Kodi is using at all CPU cores.
is it counting all cores so maxing out would be 400%?
Yes. The last value is the sum, Kodi is using at all CPU cores.
I'm running dual-boot Win10 / Kubuntu since a couple of years. I always install Windows first, and the Linux OS after that. Should work with LE, too. Sometimes one have to re-select the Linux bootloader at the EFI menu when major updates overwrite the EFI settings. But that's not very often the case.
PS: Having a fresh thread for this issue would be nice. Especially because it's maybe a backup bug. The original issue has been solved, I think, and should be marked that way.
I bet some temporary files are responsible for different backup size. A quality backup system shouldn't copy those stuff, so it's maybe a small bug.
Having a long LE run time, it seems like increasing temporary data will lead to an out-of-memory error, see here. If so, we have a heavy Kodi bug.
Thanks for responding, but we're already quite a long way past that kind of thing.
No problem, you're just already deep into it.
So, I assume you know that all add-ons are OK, and all switchable services (Bluetooth etc.) are OK, too.
You can play around with compile switches now, and start inserting your own debug log messages. That's the way I would go from there.
OK, I expected something like that. And you probably already have log level 1 activated to see as much as you can.
- You can deactivate add-ons for testing.
- You can look at the tmpfs entries of the "df -h" output. I think tmpfs runs at the RAM, too.
You could use the command "top -o %MEM" to see what process uses most RAM (on top of the list).
Can RPi 3B+ go to suspend and resume (that would be a real reason to drop the cubox-i
)
A couple of months ago I was trying to switch off / on the display of the RPi 3B+, which is some kind of a suspend mode. I was able to switch off the display, but switching it on again didn't worked (Kodi issue, I guess).
So, I have been quit the idea of an always-on-device, and built in a power button, which works fine.
I'm using this case with an RPi 3B+, without using the fan. Never had heat problems when running LE.
I tried to put in 5.0 and the sound of the voice is cut, going back to 2.0 it come back, that's why I do not know how to configure it,
Interesting. I'll try what happens on my 5.1 setup.
I think it's only for GUI sounds, and don't affects A/V playback.
We _are_ forks, and insignificant to the LibreELEC project. Relax.
OK, then just do the change log part right, and everything is fine.
Hey guys, this looks like a fight before a fork. Scary. Don't forget: users don't care about intellectual ownership, and you both know (or belief to know) what you did. So, forget the past and start writing change logs. Peace!
SD cards are cheep, but this kind of repair works for expansive storage media, too. I have seen such a GParted (Live) repair on a broken hard disk. Do it as a proof of concept on your SD, you never know what's up next.
Well I guess I went as far as I could, thanks for all the help guys, it was greatly appreciated.
No, you have been ignored my suggestion. Remember?
The tool should do:
1) an intense (!) test by reading / writing different patterns (surrounding bits can change the behavior of a bad bit)
2) create a list of bad blocks
3) format the medium by leaving out all identified bad blocks
The tool I mentioned above can do this, and maybe you'll find free Windows tools with the same functionality.
Weird part is, when I do a disk check it says in good.
Then it's a quick check. Start using quality tools.
Knowing the precise version of LE would be helpful for developers. Providing a log file (log level 1) of a glitch session may help, too.