Library loading slower than pre 4.0

[lineinthesand]

Describe the Bug/Crash

For me, the loading of my library (8400 flacs) now takes considerably longer than with the pre-4.0 versions. It used to take about 5-10 seconds (estimated), now it is ~40 s for every startup until I can start browsing my library.

Describe the intended behavior

From what I read in the release notes I had hoped, it would be even quicker than before that I can start using the app after launching it.

What android version do you use?

Android 12

What device model do you use?

Moto g41, 6 GB RAM

Provide a sample file

Not related to a single file

Bug report

Not a crash

Duplicates

• I have checked the Troubleshooting page.
• I have checked this issue for duplicates.
• I have checked that this issue occurs on the lastest version.
• I agree to the Contribution Guidelines.

[OxygenCobalt]

I've been getting a few reports like this. I can't tell if this is a caching failure, a cover art storage failure, or a bottleneck in the loader. I personally get nothing like this for my library. I'll get back with some test builds later.

[VoxelPrismatic]

For me, it takes a while only after updating. I have 1800 files.

[OxygenCobalt]

For me, it takes a while only after updating. I have 1800 files.

That's expected @VoxelPrismatic since I had to upgrade the cache schema to work with SAF, requiring me to wipe the cache. But it should load faster once the cache is built again.

The problem here is that for some reason the cache just...isn't working for large libraries. Frustrating.

[OxygenCobalt]

Okay, I was working on a parallel pipeline revamp and successfully merged it in. It uses a different method for cache cleanup so it might be less likely to fail? Here's a release build @dseomn @lineinthesand @foss- @vrigal (pinging anyone that liked these issues)

Auxio_NewPipeline.zip

My only assumption for why the cache was failing is that my timestamp management system was failing to due to some part of it not being monotonic (despite explicitly trying to ensure this...). Now I just do the slow method of "query the whole cache and delete the entries i didnt load lol".

Note that since this is a release build it'll take the place of your current install, you'll have to uninstall any install from F-Droid, and you might want to make backups in the case you want to revert for any reason.

[OxygenCobalt]

v4.0.3 has been released which I hope has a faster loader and less caching issues @lineinthesand @dseoms @foss- @vrigal. Try it out and let me know.

[foss-]

Tried the test build and did not encounter more trouble than I was with the stable. Loading was never fast for me, as you know due to library size and it still takes a good while with 4.0.3 but I have not taken times pre 4.x and 4.0.3. Thanks for releasing 4.0.3.

[OxygenCobalt]

I'd love to see if v4.0.4 has fixed this issue for you all @lineinthesand @dseomn

[dseomn]

Just upgraded to 4.0.4.

I opened the app once, waited for it load, then went to do other stuff when it took more than ~30ish seconds. It seemed to load normally when I looked back at it a while later.

Then I tried again to see if it was faster after an initial load. I opened it in the last few seconds of 15:31. Instead of the circle progress bar behaving normally like it did last time, it very quickly went to around ~95%, then flickered between that and 100% for a few seconds, then stayed at 100% until 15:38 when it finished loading.

I'm not sure if this is relevant, but I have some… unusual music in my collection:

• https://musicbrainz.org/release/08f1fe71-8ef3-42f5-ab53-1c3a47dffca6 has 555 tracks
• https://musicbrainz.org/release/7cc060cd-e61f-49f4-a58e-7fd66f29862e is a track with 1 sample (i.e., ridiculously short) and the metadata includes Mongolian vowel separators which can confuse code that tries to do anything with unicode whitespace (like trimming leading/trailing whitespace, or telling if a string is only whitespace)

[OxygenCobalt]

Just upgraded to 4.0.4.

I opened the app once, waited for it load, then went to do other stuff when it took more than ~30ish seconds. It seemed to load normally when I looked back at it a while later.

Then I tried again to see if it was faster after an initial load. I opened it in the last few seconds of 15:31. Instead of the circle progress bar behaving normally like it did last time, it very quickly went to around ~95%, then flickered between that and 100% for a few seconds, then stayed at 100% until 15:38 when it finished loading.

I'm not sure if this is relevant, but I have some… unusual music in my collection:

• https://musicbrainz.org/release/08f1fe71-8ef3-42f5-ab53-1c3a47dffca6 has 555 tracks
• https://musicbrainz.org/release/7cc060cd-e61f-49f4-a58e-7fd66f29862e is a track with 1 sample (i.e., ridiculously short) and the metadata includes Mongolian vowel separators which can confuse code that tries to do anything with unicode whitespace (like trimming leading/trailing whitespace, or telling if a string is only whitespace)

That's actually a good sign. The new optimized pipeline makes reading from the cache about as fast as exploring your music folder, so the progress bar will flicker like that @dseomn. This might mean my reworked pipeline/cache is working.

[dseomn]

I don't think it used to take 6-7 minutes to load though? But it's been a while so I might not be remembering right.