7.9 Problems/Bugs

[jstraw]

Did, about 15 minutes ago. I'll check the logs tomorrow morning.

7.9.2 seems much happier:

[19-02-07 02:11:40.7538] Slim::Music::Import::runScanPostProcessing (435) Starting Database optimization.
[19-02-07 02:22:14.2275] Slim::Music::Import::endImporter (643) Completed dbOptimize Scan in 633 seconds.

I'm still hopeful that such things as randomization, searches, etc., will experience a boost when that box goes from 8gb of RAM to 32gb.

Thanks for the help and all that you do, Michael.

[mherger]

>> Did, about 15 minutes ago. I'll check the logs tomorrow morning.
>
> 7.9.2 seems much happier:
>
> [19-02-07 02:11:40.7538] Slim::Music::Import::runScanPostProcessing
> (435) Starting Database optimization.
> [19-02-07 02:22:14.2275] Slim::Music::Import::endImporter (643)
> Completed dbOptimize Scan in 633 seconds.

Cool! How large is your library.db?

--

Michael

[jstraw]

>> Did, about 15 minutes ago. I'll check the logs tomorrow morning.
>
> 7.9.2 seems much happier:
>
> [19-02-07 02:11:40.7538] Slim::Music::Import::runScanPostProcessing
> (435) Starting Database optimization.
> [19-02-07 02:22:14.2275] Slim::Music::Import::endImporter (643)
> Completed dbOptimize Scan in 633 seconds.

Cool! How large is your library.db?

--

Michael

1.62gb

[mherger]

>> Cool! How large is your library.db?
>
> 1.62gb

Well yes, that's pretty large. The change I applied in 7.9.2 is
typically for this case: previously in "max" memory configuration LMS
would use tell SQLite to create temporary tables in RAM. The final step
after the scan thus would build the full library table in RAM. Add to
this other buffers etc. and the scanner would easily use multiple
Gigabytes of memory for this (in addition what is being used by the
server itself).

That recent change was to prevent this situation: it would temporarily
disable that behaviour for the duration of the scanner's optimization step.

--

Michael

[jstraw]

>> Cool! How large is your library.db?
>
> 1.62gb

Well yes, that's pretty large. The change I applied in 7.9.2 is
typically for this case: previously in "max" memory configuration LMS
would use tell SQLite to create temporary tables in RAM. The final step
after the scan thus would build the full library table in RAM. Add to
this other buffers etc. and the scanner would easily use multiple
Gigabytes of memory for this (in addition what is being used by the
server itself).

That recent change was to prevent this situation: it would temporarily
disable that behaviour for the duration of the scanner's optimization step.

--

Michael

It will be interesting to see if the duration of the nightly scan changes with the addition of more RAM. Or, if other operations such as the launch of random play or a search happen faster.

[jstraw]

With 32gb of RAM:

The server has finished scanning your media library.
Total Time: 00:45:46 (Saturday, February 9, 2019 / 12:48 AM)

[mherger]

> With 32gb of RAM:
> The server has finished scanning your media library.
> Total Time: 00:45:46 (Saturday, February 9, 2019 / 12:48 AM)

I'd say that's ok for 500k tracks? How long did it take before?

--

Michael

[jstraw]

> With 32gb of RAM:
> The server has finished scanning your media library.
> Total Time: 00:45:46 (Saturday, February 9, 2019 / 12:48 AM)

I'd say that's ok for 500k tracks? How long did it take before?

--

Michael

With 8gb RAM, on 7.9.1, 6-7 hours. On 7.9.2, 2-3 hours.

[jstraw]

So the last two nights have been about an hour and a half. I'm happy with that.

[Apesbrain]

If I edit the TITLE tag in a file to correct punctuation or something else minor that does not require a file rename and then do a "New/Changed" rescan, the COMMENT field for that track in "More" view appears as multiple (see below). If I click through on "View Tags" it is displayed correctly. It's a little thing, but only way to "fix" it is to run a full rebuild.