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.
The story behind is that some format tools can deal with bad blocks by leaving them out, and other tools can't. GParted Live should work.
Yes, it's possible, read here. You can start a Python script by remote button. Python is able to send IP messages.
The mouse.xml file in /usr/share/kodi/system/keymaps/ is write protected. What should I do?
Copy it to /storage/.kodi/userdata/keymaps and edit it there.
