finamp

finamp copied to clipboard

Description of the bug

In version 0.9.3-beta, when trying to shuffle large playlists to the queue (20,634 tracks in my test case), some time will pass before an error appears at the bottom of the screen. Tapping the error for more information brings back the following error:

Error Null check operator used on a null value.

To reproduce

1. Add a playlist with a large number of tracks.
2. Long press the playlist in the Playlists tab.
3. In the contextual menu that appears, tap "Shuffle to queue"
4. Wait.
5. An error will appear at the bottom of the screen.

Thanks for the report. I don't even have that many tracks to test with, but I actually don't think that the amount of tracks is the problem...
This sounds more like a case where there is some track inside that playlist that is causing trouble.

Could you maybe either provide logs, so I can pinpoint where the issue is occurring, or try to subdivide your playlist into smaller chunks to see if they all behave the same of only a part of it (containing said track) is showing the issue?

Thank you for your input on this. You were right about an issue with tracks.

I did as you suggested and started subdividing playlists out until I could identify the problem. It turns out that one of the albums did not have a cover image file, even though the cover was included in the metadata for the individual track files.

Once I added a cover image file to the album's directory and refreshed/replaced the metadata for that album in Jellyfin, I was able to add the smaller playlists that I had subdivided in Finamp.

When I tested the full playlist with the 20K+ tracks, that was also successfully randomized and added to the queue in Finamp.

I'm not sure if this is expected behavior, but I do usually include those album cover files in each subdirectory, so this did flag down a mistake for me.

Thank you for helping me resolve the issue so that I'm able to queue up that full playlist!

I'm really glad the queueing system wasn't the problem!
Tracks without covers not playing is a known issue with the beta version and will be fixed with the next update :)

It sounds like we can close this out, then!

For what it's worth, the queuing system is really impressive. That was a really key piece of missing functionality for me compared to other players I've used, so I really appreciate you adding it in the beta.

The Finamp beta is really amazing. Thanks for all your hard work on it!

I am running into some issues with the queue/playback that I don't remember experiencing before. I installed 0.9.3 just before opening this issue, since I wanted to make sure I was working with the latest, so a lot of my testing with the queue had been with 0.9.2.

I'm on Android, and I seem to be running into the issues even after clearing the cache and completely clearing the storage/logging in again.

For example:

• Just after clearing cache/storage and re-logging into Finamp, if I add an album with a single track to the queue (via a long-press on the album title), I get a message that it was successful, but then nothing happens. I don't see anything in the queue, and when I go to Restore Now Playing, it is empty.
• After that (without clearing cache/storage), I took the same album and long-pressed/selected "Shuffle to next up", and there's a message that says it was shuffled to next up, but nothing else happens, and when I look at Restore Now Playing, there is again nothing there.
• If I bring up the album detail by single tapping it, the "Shuffle" button works as expected, although it does seem to just keep repeating even without turning on repeat (I'm not sure if that's intentional).
• Sometimes when I try to shuffle the playlist from the detail screen (which is originally what I was doing), the app crashes. Here are some logs for that: finamp-logs.txt
• When I am able to successfully able to shuffle the playlist and have it play, it seems like there is something odd going on. I noticed it was playing continuously from the same album, and when I looked at the Restore Now Playing section, it said that there were only ~1500 tracks left to play out of the 20K+, even though only a few tracks had been played. And it was playing in order vs. a shuffle.

I'll keep testing, particularly after the next release comes out, but I wanted to let you know about these items in case it's helpful. Thanks again.

Yes, there currently is an issue where adding something to the queue with nothing playing before will not work properly. Thanks for reminding me about that, I still need to fix it.

Could you elaborate what you mean by shuffle seeming to keep repeating? And logs might be helpful here.

Sadly the logs don't help diagnose the crash, since logs aren't persisted across restarts yet :(

Regarding the wrong info in the restore now playing screen, what happens if you restore the queue? Does it restore correctly, with shuffle enabled and the correct position?

Thanks for the feedback!

Sorry for the delay on this.

Could you elaborate what you mean by shuffle seeming to keep repeating? And logs might be helpful here.

I was getting a behavior in which once the shuffle was completed, then the queue would restart. Now I can't replicate it, though. If I do, I'll grab the logs.

Regarding the wrong info in the restore now playing screen, what happens if you restore the queue? Does it restore correctly, with shuffle enabled and the correct position?

It's crashing. I'm not sure if my logs will help, but I'll post them here: finamp-logs.txt

Edit: fixed the styling, since everything was included in the quote.

I was getting a behavior in which once the shuffle was completed, then the queue would restart. Now I can't replicate it, though. If I do, I'll grab the logs.

And that was with repeat / "loop all" off? Either way, we made some improvements to the end-of-queue behavior that will land in the next update.

I bet the reason for the crash is that Finamp tries to restore all items at once, and the resulting HTTP request exceeds the maximum size (because it contains 20k+ Jellyfin IDs). The "Restore Now Playing" screen will also only contain info about the last played queue, not the currently playing one, so that might explain the other bug you were seeing.

I wanted to look into restoring the queue more efficiently anyway, but I don't know when I'll get around to it

And that was with repeat / "loop all" off?

Yes, it was. To your point, though, you made some changes and I have been unable to replicate.

I wanted to look into restoring the queue more efficiently anyway, but I don't know when I'll get around to it

Thanks. I understand - your hard work on this is much appreciated.

I'm going to update to 0.9.5.

Edit: I keep having to remember to put extra spaces after the quotes.