2.65 million local tracks in the database.
Qobuz and Tidal are not logged in until the local music tracks are fully identified.
Adding to the database was done with Metadata Optimizer paused.
Component Utilization:
The few errors in the CPU workload only affect the short startup phase, according to my observations. There is no correlation to database size.
The logs (response time behavior) showed that it is better to separate adding and identifying. Here the development should make new considerations for all users.
The logs (freezing) show that the simultaneous use of the services is a performance brake. Qobuz and Tidal are therefore not yet logged in even in the identification phase and later in a third phase more closely examined what the intensive use of the services with my system does.
In 4 hours, 3 log files were created with a total of 71705 lines. 8317 lines give information about debug: [easyhttp] […] POST…
Selected logs:
Login:
05/30 08:37:27 | login | returned | after | 1709 | ms, | status | code: | 200 |
---|---|---|---|---|---|---|---|---|
05/30 08:37:28 | login | returned | after | 1882 | ms, | status | code: | 200 |
05/30 08:37:34 | login | returned | after | 488 | ms, | status | code: | 200 |
05/30 08:52:55 | login | returned | after | 489 | ms, | status | code: | 200 |
05/30 09:03:33 | login | returned | after | 496 | ms, | status | code: | 200 |
05/30 10:03:34 | login | returned | after | 489 | ms, | status | code: | 200 |
05/30 11:03:38 | login | returned | after | 488 | ms, | status | code: | 200 |
05/30 12:03:48 | login | returned | after | 487 | ms, | status | code: | 200 |
It seems to be programmed to have a new automatic login every hour that works reliably with less than 500 ms after the manual start.
The machine is reported every 4 hours like this:
05/30 08:38:10 Debug: [easyhttp] GET to …://updates…after 497 ms, status code: 204
05/30 08:37:27 | machineallocate | returned | after | 1356 | ms, | status | code: | 200 |
---|---|---|---|---|---|---|---|---|
05/30 12:37:40 | machineallocate | returned | after | 490 | ms, | status | code: | 200 |
05/30 08:37:28 | Debug: [easyhttp] […] GET to …://devicedb…1949 ms, status code: 304 |
---|---|
05/30 12:37:40 | Debug: [easyhttp] […] GET to …://devicedb…467 ms, status code: 304 |
35 device-map logs are usually also under 500 ms. Maximum 10:51:20 with 838 ms
HEAD imagecache.roonlabs 2992 lines with status code 200 returned after … ms
On average 288 ms were needed. The longest time intervals were at 08:49:17 with 3313 ms and 11:27:12 with 3372 ms. Despite some outliers, I would describe this performance data as performant over the entire period under investigation.
Debug: [easyhttp] […] POST …identifier…returned after…ms with status code 200 is in the same seconds range. There are 5193 log lines evaluated. The highest value at 11:41:34 with 3549 ms. Only 9 values are above 1000 ms.
GET internetradio.roonlabs shows 22 entries between 542 and 880 ms