Do not load cover art in music loader

[SEAPUNK]

Description

Instead of refreshing the music library in the foreground, can't it be updated as a background thread, relying on the existing built library instead?

Additionally, it randomly fails to load, giving me a timeout error.

Problem solved

No response

Other implementations

I've yet to see another music player that doesn't already do this.

Benefit

I'd be able to just start the app and start listening to music instead of waiting for a very long time while it scans through ~600 songs.

Duplicates

• I have checked this feature request for duplicates.
• I have checked that this feature is not implemented in the lastest version.
• I have checked the Why Are These Features Missing? page.
• I agree to the Contribution Guidelines.

[OxygenCobalt]

It is using a background thread, I just would rather openly indicate that Auxio is loading rather than quietly do it and have items wildly jump around for around a minute.

How big is the cover art that you use? Auxio tends to choke and timeout on very huge (1000x1000x+) album art since reading file data is very slow on modern android. When it timeouts, it ends up being unable to cache anything to speed up subsequent loading. I'd highly recommend shrinking your cover art.

[OxygenCobalt]

I've decided to turn off the timeout system @SEAPUNK given that no matter how much I adjust it I doubt it'll work. Will probably show up in 3.5.0.

[SEAPUNK]

Still, I don't have this issue on other music players. I just installed Poweramp and tested this on the same folder - not only did Poweramp scan the entire library within 10 seconds (compared to Auxio, which takes almost a full minute), it did it all in the background, so I could still listen to music as it did it, even if it lagged during the process.

My best guess as to what's going on, after comparing the two:

Poweramp appears to lazily load the album art. I dont think it cares about what the album art for the songs are at library scan, and it tries to load it as I scroll through the library. I also noticed that Auxio, in a folder of many different songs, is using the same album art for every song in there, presumably by looking for an album art image in the folder, and applying the first one to all of them. It just so happens to be that the first match is a 950x950 1.8MB PNG file, which probably contributes to the slowdown.

So aside from album art being scanned and applied incorrectly for the music (the files already have the album art embedded in them, so I'm not sure how it's determining what the album art for the song should be), it probably is prematurely caring about the album art as well. Maybe Poweramp also optimizes by reading the file in a way where it skips over the part where the album art data is, I'm unfamiliar with Android development and what's possible with it.

[SEAPUNK]

I just would rather openly indicate that Auxio is loading rather than quietly do it and have items wildly jump around for around a minute

Does it really have to update the UI in realtime? Why not just show the stale library as it refreshes in the background, applying the changes all at once when it's done? Hell, maybe even on an interval to reduce how often things jump around?

[OxygenCobalt]

Still, I don't have this issue on other music players. I just installed Poweramp and tested this on the same folder - not only did Poweramp scan the entire library within 10 seconds (compared to Auxio, which takes almost a full minute), it did it all in the background, so I could still listen to music as it did it, even if it lagged during the process.

Poweramp appears to lazily load the album art. I dont think it cares about what the album art for the songs are at library scan, and it tries to load it as I scroll through the library. I also noticed that Auxio, in a folder of many different songs, is using the same album art for every song in there, presumably by looking for an album art image in the folder, and applying the first one to all of them. It just so happens to be that the first match is a 950x950 1.8MB PNG file, which probably contributes to the slowdown.

Poweramp is paid with a full-time developer to basically build an entire audio stack from ground-up. I have to use limited off-the-shelf components, everything I do is a hobby, and I can go weeks without the time to make single-line changes.

Poweramp probably has:

• A full self-rolled native tag extraction stack with low-level workarounds to the horrible post-scoped storage APIs that add artifical delay to every file read for """"""security""""" (read: google doesnt want me using local storage). I have media3, which is slower, maintained passively by google, and requires drastic patches to even do simple versions of the same optimizations you want.
• A full image cache implementation that allows instant cover art loading, likely with it's own deferred pipeline that does further background processing while you aren't looking.//
• Dynamic tag management that likely allows them to skip any cover art loading. I would have to probably make an insanely complicated vendor patch wrecking dozens of systems my end to do the same.

The size of these efforts are extreme for me currently. They would require multiple cross-dependency patches and whole new systems to be built out and likely around +5kloc of changes, and I am managing dozens of other active issues on my limited time. It is NOT as simple as it seems. There is a reason why Poweramp costs money.

Does it really have to update the UI in realtime? Why not just show the stale library as it refreshes in the background, applying the changes all at once when it's done? Hell, maybe even on an interval to reduce how often things jump around?

This would up the complexity to an extreme amount and be slower than right now as it means a total relayout and player reload multiple times. Try using vinyl music player (which does this) and have a great time as the app becomes completely and totally unusable for 3 minutes when it reloads the library.

[OxygenCobalt]

Reopening to track the optimization you proposed anyway. It will simply take a long time.

[SEAPUNK]

That's fine, no rush. I understand that this is an OSS project, and if I would help if I had the time to dig into this myself. I appreciate that a project like this exists. :)

[OxygenCobalt]

Just looked into it and it seems like ExoPlayer does dynamically do file reads up until it reads metadata, in which it just reads out everything into memory and decodes it from there. No wonder it's so in-efficient. If I make the reads on-demand and dynamically toggle images, it would allow me to avoid image loading I think.