App crashing for very large queues

[Whoever4976]

Since Yesterday, still on version 0.9.11, Finamp alway crashes within 10 seconds of opening it, no matter what or if i do anything.

This is what happens when i open the app:

1. App Opens
2. Bottom mini-player indicate "Restoring queue..."
3. Album Grid appears
4. about 6 seconds pass
5. 💥 Crash 💥

I have already tried to click on another album and then select one of its tracks. When i do that, the selected song does play, but only for a couple of seconds before the app crashes again.
I have also tried to change some settings, like album grid and player appearance settings
I have also updated to the newest version (0.9.12)
Nothing seemed to influence this "10 second rule" but one thing;

Once i turned offline mode off and on again, the app discarded the playback queue (since my server was offline) and the app continued to work like expected after.

My theory is that some song in my playback queue was causing some issue, but i dont know, because there was no error of any kind. It just crashed.

Sadly, i cannot provide any logs. It seems that finamp only keeps very few log entries, and the ones from the crashes have already been replaced by newer one that don't show any issues. So maybe that's another thing to improve 🙃.

[Chaphasilor]

Hey, thanks for the report. It's probably something that happens during loading of the queue, could be a rogue tracks or simply too many tracks. If this happens again, try going into Audio Service settings and disabling "Auto-restore last queue", then restarting.

As for the logs, Finamp only shows the logs since last startup within the app, but if you click the share button on the logs screen, it will export the full logs file. That might be useful :)

[Whoever4976]

Thanks for the tip 😀!
Here is the log file from today.
finamp-logs.txt

Some additional info that might be relevant:

My offline library contains 6639 Downloads (5975 tracks and 664 images). (all opus@128, total size ~22GB)
I also have many high quality cover images (<=3000x3000) in my Library. This has caused some lag in the past.
I encountered this issue today (2024-11-18) between about 08:00 to 08:30. It worked fine after around 08:30.

Thanks a lot for your work on this great app!

[Chaphasilor]

Okay, seems like the issue really is the huge queue size. Somehow you ended up adding 12k tracks to the queue, exactly twice the amount you downloaded.
I'm not sure how that happened, because there usually is a limit to how many tracks are requested from the server (250 by default), unless you're in offline mode where currently all tracks are added to the queue. But I'm not aware of a way to add all tracks to the queue twice, unless you have them all in a playlist or something. Do you have an idea how this might have happened?

I did manage to reproduce this though, by adding a playlist with a few hundred tracks to the queue multiple times I ended up crashing the app. After ~5000 track it took 2-3 seconds to add the playlist to the queue (in offline mode), after ~8-10k tracks the app was lagging while queuing up the tracks, and past 12k tracks the app crashed, and would keep crashing when trying to restore the queue. Restoring a queue with 11k tracks did work without crashing for me.

The queue is probably simply too long. Me and @flloschy identified a more severe version of this bug on iOS. There it already happens at around 2k tracks. So it looks like the best course of action is to limit the maximum length of the queue (maybe to some default length that is different on Android and iOS and can be changed by the user).
Also, keeping tracks in a "virtual" queue that isn't directly tied into the system player might also work. Maybe we can do this as part of #616

[flloschy]

Thought for a moment this is my issue haha

I would say a setting called "target queue length" with a description like
The amount of tracks added to the queue when starting playback (you can manually append to the queue still). Be aware that your system may run into performance problems starting at ~1.5k queued. and a default value of 1000 is totally fine

Creating a virtual queue system sounds like a lot of work and I doubt that anyone actually listens to 1500 or more tracks in one sitting and then also so annoyed if the queue stops playing

[Chaphasilor]

I mean the problem is always how the queue ends up behaving. If we just drop tracks at the end, only the first 1.5k tracks would be shuffled. So we need to shuffle first, and then add to the queue, which iirc already requires some internal changes (since shuffling is sadly handled by the player). It also means that when un-shuffling or re-shuffling, only these 1.5k tracks currently in the queue will be considered, leaving "gaps" when in linear order, which is odd.
So I'd like to remember all tracks that should be part of the queue, and then always pick a selection that gets added to the actual player queue.

Also, the "Play On" feature of Jellyfin (in this case, controlling other clients and showing what they're currently playing) is definitely planned and most likely requires changes to the queueing system too, so we can probably do it all in one go.

[Whoever4976]

I'm not sure how I ended up with 12k songs in my queue in the first place. I only have 2 playlists on my server (10 songs each) but I don't use playlist at all. So i usually just click on albums to find my songs or I listen to whole albums.
I definitely did not add all my songs multiple times on purpose and I think it's pretty hard to do that accidentally.
I almost exclusively use the app in offline mode and only go online to sync new songs.

I am aware that, by default, selecting a track from a album adds the rest of the album to the queue. But each time i click onto a track of another album, the queue gets replaced by the new album. So there's another issue here that caused the app to somehow add 12k Songs to the queue when it shouldn't have . I'm not sure how this can be reproduced. Maybe it stopped clearing the queue at some point and that led to the massive count of songs in the queue.

I will be using the app more attentively from now on and will let you know if this happens again or if i figure out how to reproduce this.

[Chaphasilor]

Well, if you select a track from within the tracks tab (like when searching for a track), Finamp will currently add all downloaded tracks to the queue. That would explain how half the tracks ended up there. Normally, selecting another track would then replace the entire queue again, as you stated. But it seems like for some reason that didn't happen.