02:50 <By-Tor> Hey I'm running 10.0b5 on an RPi4b, and a couple days ago I started getting some strange errors. In the logs, the arrow addon is throwing errors in constants.py that it "should not be". It looks like something internal is clobbering the datetime.datetime module

02:51 <By-Tor> _MAX_TIMESTAMP = datetime.max.timestamp()

02:51 <By-Tor> is throwing an AttributeError, which it should not.

02:51 <By-Tor> somehow datetime.max is a timedelta(0) object

02:53 <By-Tor> and of course everything works fine if I run the code in the python interpreter

20:21 <diederik> when looking at system info > hardware, I see that 1 core is always at ~35% on my rock64. Why is that? (The active core switches from time to time)

20:23 <diederik> AFAICT it's just idling, so that seems excessive (and consequently keeps the temperature high(er))

20:30 <ndufresne> diederik: try running top or perf to learn more

20:31 <diederik> top shows it's kodi.bin

20:31 <ndufresne> ok, that's what I hoped

20:31 <ndufresne> got a rule out other thing running in the background ;-D

20:31 <ndufresne> if perf is installed, I'd run that

20:31 <diederik> indeed. Should've mentioned that before

20:32 <ndufresne> and try to find some symbols that get called a lot, that would eventually pin point and make for a better bug report

20:33 <diederik> I'm not familiar with 'perf' yet. Should I run 'perf top'?

20:33 <ndufresne> I'd run "perf top -g "

20:33 <ndufresne> you can then expend the top consumer with <space>

20:34 <ndufresne> or enter, can't remember

20:35 <ndufresne> ah, it's 'e' to expand now

20:36 <ndufresne> and you can use -p <kodi pid> iirc to focus on that process

20:36 <diederik> https://pastebin.com/yiAjamjL <- output of 'perf top -g'

20:36 <ndufresne> of course, kernel overhead cause by a process is always good information, e.g. abusing some ioctl

20:37 <diederik> it's not a steady screen output as you'd see with (normal) top

20:37 <ndufresne> that was rather unexpected

20:37 <diederik> so I don't know if/how I can do the other things you requested

20:37 <ndufresne> squashfs overhead really ?

20:39 <ndufresne> it's doing massive amount of read()

20:39 <diederik> could that be due to a bad SDcard?

20:39 <ndufresne> which on the squash fs is very surprising

20:39 <ndufresne> the SD card data partition is FAT

20:39 <ndufresne> the squash FS is the read-only OS

20:42 <diederik> yeah. I've already made a backup to an external device and already prepped a spare SDcard as I noticed it had some difficulty starting up recently

20:43 <diederik> Main issue I have is that my rock64 gets HOT. So hot that basically any 4k stream will make it overheat and thereby freeze up. Pulling the plug is the only remedy then

20:44 <diederik> I don't know if it's relevant, but mentioned it just in case

20:46 <diederik> I'm running kernel "Linux kodi-rock64 5.10.47 #1 SMP Mon Jul 5 19:05:21 CEST 2021 aarch64 GNU/Linux" and this version: "nightly-20210705-7e5854c (RK3328.arm)"

20:49 <ndufresne> well, 4K on RK3328 is a lot, just mentionning

20:49 <ndufresne> have you consider just adding a passing heatsink ?

20:49 <ndufresne> * passive

20:50 <ndufresne> https://pine64.com/product/rock64-pine-a64-pine-h64-heatsink/

20:51 <diederik> Yep. Plan to order the alu heatsink (https://pine64.com/product/model-b-premium-aluminum-casing/) soon. And the one you linked as well (I'm aware they're mutually exclusive)

20:51 <ndufresne> Yeah, the cooling case looks pretty nice

20:52 <ndufresne> yes, they are exclusive, you cannot use both together, as both have a thermal pad to the same spot

20:52 <diederik> IMO Pine64 should have mentioned that the rock64 really needs a cooling solution

20:52 <ndufresne> it only needs cooling if you turn on the GPU

20:53 <ndufresne> i.e. it's not black and white, depends on what you do with hit

20:53 <ndufresne> it

20:53 <ndufresne> in early panfrost demo, we melted a table top with an rock-pi4 (rk3399)

20:54 <ndufresne> the cpu would throttle to try and cool down the GPU, was not very efficient

20:54 <diederik> Trying to experiment with it, I tried to build a custom kernel on it -> freeze. So far it _looks_ like if you actually/really use it, it gets so hot it shuts down

20:55 <ndufresne> perhaps the performance setting are too agressive, since it should just throttle these days, but it depends a bit on what build you got for the GPU, I bet it'S using the mali blob on released LE

20:56 <diederik> possibly inspired by me/my reports, someone (on irc:Pine64/#rock64) created this: https://forum.pine64.org/showthread.php?tid=14148&pid=96262#pid96262 (which uses the heatsink you linked)

20:56 <ndufresne> not that it's better with Lima, not sure how far they are on GPU scaling

20:57 <ndufresne> I hope there is i2c fan controller cheaper then an Arduino

20:59 <diederik> yeah, it could be further improved upon. My main problem is that I don't have a 3D printer

21:00 <diederik> when I run 'perf top -g' on my main pc, it does have a stable screen output (like top)

21:02 <diederik> while I fully agree that I should have some cooling device (esp when playing 4k streams), I did expect it to cool down when doing nothing, like right now when it's (still) on the sysinfo hardware page

21:04 <diederik> Current temp is 62C and while it does fluctuate a bit, it's consistently around that. That screen also shows CPU usage and that surprised me (hence the question here)

21:06 <diederik> IIRC a while ago, it only froze when playing a 4k HDR x265 stream, but now it's essentially any 4k stream

21:07 <diederik> I have a video conversion script where I though to convert 4k x265 to 1080p x264, but there was a bug in there, so it was a 4k x264 stream

21:09 <diederik> ndufresne: "it depends a bit on what build you got for the GPU" do you mean HW build or SW (ie LE) build?

21:57 <diederik> is there something like a 'toram' option? 'free -h' reports 157Mi in use, 3.4Gi free. I wouldn't mind it using more RAM, especially if apparently the squashfs read is causing so much load