-
-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not load cover art in music loader #802
Comments
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. |
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. |
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. |
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? |
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:
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.
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. |
Reopening to track the optimization you proposed anyway. It will simply take a long time. |
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. :) |
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. |
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
The text was updated successfully, but these errors were encountered: