More > JRiver Media Center 28 for Mac

JRiver 28.0.32 - Mac Mini M1, high swap & kernel_task CPU usage after a while

<< < (3/5) > >>

YogiPL:
All my files are stored on an SMB share from a NAS (OpenMediaVault) on my LAN.
There are no video tracks or anything else besides music on that share.
All my files are FLACs and ~99% of them are 16/44 CD rips (with some rare 24/44 downloads here and there)

bob:

--- Quote from: YogiPL on July 01, 2021, 02:24:34 pm ---All my files are stored on an SMB share from a NAS (OpenMediaVault) on my LAN.
There are no video tracks or anything else besides music on that share.
All my files are FLACs and ~99% of them are 16/44 CD rips (with some rare 24/44 downloads here and there)

--- End quote ---
Thanks, I'll see if I can duplicate it. The different filesystem is interesting, there are some file operations that are different on remote filesystems.

YogiPL:
If anyone is still interested: I've tested this behavior further and I've found that while doing Audio Analysis the file cache portion of memory usage consistently rises BUT it can be freed by remounting the network share (you don't even have to close jriver)

So basically, it can be done in chunks while watching the Activity Monitor ram usage. Once it hits swap though it's best to stop and remount the share because it WILL crash the system eventually if left alone. Not ideal but with 16GB of memory I could do it in about ~400-500 files per batch without running into swap. I think this could be a bigger issue on the 8GB macs...

This seems to have something to do with the way macos handles network drives? Not sure,

YogiPL:
Another bit of info: after buying jriver mc license (you guys are really the "only game in town" on macos it seems ;) ) I installed it also on my old Macbook Air with i5-5xxx and 8GB of RAM.

I ran the media import process from the same share and somehow it found more files to analyze (maybe my M1 stored some info only locally, not in tags? anyway the number of files was the same it just re-analyzed about 500 of them).

It chewed through them no problem (albeit slower) WITHOUT the same file cache/swap issue!

So it seems this is limited to the ARM platform.

bob:
That's quite interesting.

There are still at least 2 variables, one the arch, the other the NAS connection.
Disconnecting the Mount likely kicks out the file modification notification.
It would be interesting to see if the M1 would still have the issue with local files.

It's possible there is a bug in the notify system in general on the M1 or over the network. It really shouldn't be trying to do that over SMB, I'm pretty certain SMB doesn't support it.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version