I can probably introduce a crash with cpuburn too; but god knows why you’d do that.
I’ll add some temperature governing; but I don’t want to cripple performance for people that don’t do this regularly.
With that said, some increased governing over frequencies is probably needed. There was a guy running sabnzbd+ and other services and he found increased temperatures which caused occasional freezes during playback.
If you had a fresh install with just OSMC I’m confident you wouldn’t experience these problems.
Cheers
Sam
Don’t get me wrong, I’m not trying to find a problem where there isn’t one. And I’m also not trying to crash the system deliberately 
I do believe however that downloading a single torrent file while watching a movie is not too much to ask from this device ← this was the initial problem I faced before I started digging deeper.
The same setup was working fine on my RPI3. There were no crashes whatsoever.
Please let me know however if you think that Vero 4K is not fit for my use case.
I’m willing to test further and provide whatever information necessary for you guys to figure out what’s going on.
I don’t think a single torrent would be a problem at all.
Obviously however you are adding something that will contend for bandwidth, IO and CPU time. If you were seeding a large torrent, you’d probably notice problems with streaming.
The Ethernet on the Vero 4K isn’t connected via USB however; so this isn’t as problematic as torrenting via Ethernet and saving to a USB disk would be on a Pi.
Transmission tends to be more lightweight (you can do more at once) than Deluge; and the OSMC version has some performance improvements.
If you believe it’s overheating, then you could try changing the max scaling frequency temporarily to see if this is the case. There are still a couple of corner cases where the device can overheat because the governor doesn’t kick in quickly enough.
However, if the device is indeed overheating, then it would become unresponsive completely (no SSH or ping response).
The hangs sound different, and this could depend on customisations made to the system. top will let you see processes that are starved (high IO wait) for example.
Kodi’s render thread will exhibit skips if it is switched away. You may find that renicing the torrent client process resolves this. If it works, you can set a nice value in the systemd unit itself.
Even better would be to run: sudo systemctl restart mediacenter and see if Kodi comes back. That will determine if it’s a Kodi crash or not.
Also just to confirm: the device isn’t in a cabinet or anything sitting on top of it.
At the moment there are a lot of variables, and we need to narrow things down a bit so we can work out what the issue is (it will no doubt be software / configuration related)
Sam
Probably I didn’t make myself clear earlier in the thread…
The device hangs dead showing black/grey/blue/you-name-it screen
No response over network, neither does it respond to remote control.
Nothing in log files after boot
The only thing that brings it back is unplug/plug power.
You need to put some monitoring in place:
1 Add a simple top command to run every minute via cron. (If cron isn’t there already, install it from the app store or through apt-get.) Run crontab -e to edit the cron table then add the following line:
* * * * * /usr/bin/top -b -n1 | /usr/bin/head -5 >> /home/osmc/monitor.out 2>&1
2 Write your system journal to “disk”. (It’s normally just kept in memory.) To do this run:
sudo mkdir /var/log/journal
sudo systemctl restart systemd-journald
(The system journals can become difficult to read because the Vero4K doesn’t have a battery-backed clock, but in the event of a system crash, we should be able to figure out the latest date/time.)
I’ve already done that and can confirm that high CPU usage causes the crash.
Apologies. Where did you say that high CPU causes the crash? How do you know it’s not a symptom of something else, for example?
If you are certain that high CPU use causes the crash then this is good to know. How did you determine this?
One further recommendation to this would be to use max_scaling_freq to reduce the CPU frequency. If this improves things then we just need to tweak DVFS slightly to add some throttling for very high temperature workloads.
Sam