Heavy CPU load by browsing Komposers

[9dIe2Hd0VGy3Pw0zYPYs]

Hi Simon,
sorry, bad new.
With 189 it's the same as with 188.
If I chose the composer view (under folderview) the index is loaded.
In 187 I can see folder images, in 189 the index is without any images.
If I chose an character (F for example) than the view is empty and the cpu load grows up to 90 percent on my synology.
Regards Jürgen

[simoncn]

Please do the following:

1) Start MinimServer update 189 and the LUMIN app
2) In MinimWatch, select 'Show log' and set the logging level to Debug
3) Leave the MinimServer log window open
4) In the LUMIN app, select folder view > Composer
5) Under Composer, select F
6) After 5 seconds, in the MinimServer log window, select 'Save as' and save the log to a file
7) Compress the log file to save space (zip or similar) and attach it to a post here

I hope this will provide some information about what is causing the high CPU.

[9dIe2Hd0VGy3Pw0zYPYs]

Hi,
hope you can see something.
The log freezes for a couple of minutes when I select the "F" folder at composer.
Jürgen

[simoncn]

Thansk for this log. It is very useful and shows that one of the MinimServer threads is looping, hence the high CPU. The log file doesn't have quite enough information to show exactly what is causing the loop.

To find the problem that is causing the loop, I need to see a thread dump taken while the loop is happening. Please do the following:

1) Start MinimServer update 189
2) Login to the NAS in a Terminal window as admin using ssh, putty or similar
3) In the Terminal window: run this command: ps -ef | grep mserver.jar | head -1
4) This will produce output like like the following:

Code:

root      7419  7417  1 15:15 ?        00:00:08 /volume1/@appstore/MinimServer/lib/minimjre(linux-arm64)-14.0.1.dir/jre/bin/java -jar /volume1/@appstore/MinimServer/lib/mserver.jar --launchrc --noprompt --nohup --noconsole

5) The first number in this line (7419) is the process ID for MinimServer
6) Start the LUMIN app, open the Composer index and select the F folder
7) MinimServer will become unresponsive. In the Terminal window, run this command:
sudo kill -quit 7419
with 7419 replaced with the number you found in step 5. It is a good idea to have this command typed in and ready to run before you do step 6. Enter your admin password when prompted.
8) Despite what you might expect intuitively, this doesn't kill MinimServer or cause it to quit. Instead, it writes a thread dump to the minimserver-out.log file in the MinimServer/appData shared folder.
9) Wait a few seconds and run the kill command a second time. Wait a few more seconds and run it a third time.
10) Zip the minimserver-out.log file and attach it to a post here.

Thanks very much for your help with this.

[9dIe2Hd0VGy3Pw0zYPYs]

Hi,
I sent you all the todays log information, I hope this will help.
Jürgen

[simoncn]

Thanks for this. It has helped me find a problem that would cause high CPU and long delays with a large library and I am thinking about how this can be fixed.

[simoncn]

This problem is fixed now in MinimServer update 190.

[Peter StreamMagic]

(18-03-2021 09:50)simoncn Wrote:  This problem is fixed now in MinimServer update 190.

I have just updated to 190 and all seems fine now, thanks!
There are now a few [unknown] items in "Artist", is this the same as [untagged]?

[simoncn]

Similar but not quite the same.

[untagged] is only on the top-level menu. It shows items that don't have any indexed tags (not counting "special tags" such as #AudioData).

[unknown] is on a menu for a single tag such as Artist, Composer, etc. It shows items that don't have that tag. So on the Artist menu, the [unknown] selection should contain items that don't have an Artist tag.

[9dIe2Hd0VGy3Pw0zYPYs]

Hi Simon,

yes, congratulations!
190 is working as we are used to have it.

Regards Jürgen