More > JRiver Media Center 26 for Linux

Is there any way to speed up views on a Pi?

<< < (5/5)

Mastiff:
This stuff is a bit out of my league, I'm a Windows man. But the load average is 2,28, 2,24 and 2,18 on a Pi 4. And MC regularly goes over  100 % CPU, and that's just illogical to me! It jumpes from 27 % to 125 %, and up and down. At least memory is no problem, that stays around 9 %.

But I found something else that may explain much of the slowdown. My library has been multiplied when converting it from my main media server library to the Pi! I ran Rename, move and copy files from Library tools with "Update database to point to new location (no file rename, move or copy)" to replace E:\MP3 with /media/pi/MP3 and "Convert Windows File Path Syntax to Mac/Linux" ticked off. Turns out that it didn't work correctly, and the E:\MP3 was replicated with "invalid path" or something like that, while at the same time I had an auto-import set up that I didn't even remember I had, so the library was doubled, to more than 350 000 tracks... Suddenly it got a lot more responsive!  ;D

mwillems:

--- Quote from: Mastiff on October 07, 2020, 06:04:09 am ---This stuff is a bit out of my league, I'm a Windows man. But the load average is 2,28, 2,24 and 2,18 on a Pi 4. And MC regularly goes over  100 % CPU, and that's just illogical to me! It jumpes from 27 % to 125 %, and up and down. At least memory is no problem, that stays around 9 %.

--- End quote ---

Linux reports CPU utilization on a per core basis, so 125% CPU means one core is fully utilized and another core is 25% utilized.  A load average of 2-ish under load means that there are typically only two processes running or waiting for CPU time on average, which (given that the OS is also running necessary tasks too) suggests that whatever MC is doing is either a series of single-threaded tasks or tasks that are very lightly multithreaded (i.e. don't even use two cores fully).


--- Quote ---   
But I found something else that may explain much of the slowdown. My library has been multiplied when converting it from my main media server library to the Pi! I ran Rename, move and copy files from Library tools with "Update database to point to new location (no file rename, move or copy)" to replace E:\MP3 with /media/pi/MP3 and "Convert Windows File Path Syntax to Mac/Linux" ticked off. Turns out that it didn't work correctly, and the E:\MP3 was replicated with "invalid path" or something like that, while at the same time I had an auto-import set up that I didn't even remember I had, so the library was doubled, to more than 350 000 tracks... Suddenly it got a lot more responsive!  ;D

--- End quote ---

Hey that's great news that you found something out of it!  As I recall MC's process for checking if files in the library are missing is very "expensive" in terms of I/O and CPU, and there's a menu option to disable checking it in views (under Tree & View-->Advanced and called "display missing file image in lists (slow on network drives)").  I suspect that was a big part of your slowdown (i.e. not just doubled library, but also lots of missing items).  You should try disabling that setting; auto import would still clean up if you have fix broken links on, but your views would probably be much faster.

Mastiff:
Aha, I see. :) So that's not so bad to go over 100 % on the CPU, then.

And I found that missing files to, under "Options", "Tree & View", "Advanced" there's "Display missing file images in lists". So I have remove that now. I hope that will take care of all my problems with this. :) Thanks again for the help!

Navigation

[0] Message Index

[*] Previous page