Loading from DB not properly working in HomeSongs

[twistios]

Version of RiMusic

0.6.61 (custom version) or current latest commit in my master branch

Android version

14

Tell us how you trigger this bug

1. Open RiMusic
2. Open "Songs" section
3. Switch between different tabs (all, favourites, cached)

Submit a video

Screen_Recording_20241123_184723.mp4

What was your expectation?

The songs should be correctly loaded

What more can you tell us? (Optional)

This is a regression from 0.6.60 to 0.6.61.
Sometimes the songs don't load at all or only an incorrect number of songs is shown. When clicking on a song, it then only shows the correct amount of songs.

[knighthat]

I think this is a new recommendation system. It's supper annoying imo

[twistios]

I assume it has something to do with your pull request #4603 @knighthat

[twistios]

Just so it is clear, this is happening not in regular 0.6.61 but 0.6.61 custom version I got from fast4x. It also happens with the latest released changes.

[knighthat]

PR #4603 just got merged few hours ago so I don't think it made it way to any release version yet. Besides, I didn't touch the queue system. I'll take a look and do some comparison

[twistios]

It got merged 13h ago and I got the custom version from fast4x himself 6h ago. As I said, it also happens with the released/public changes from the Repo in the debug build I made.

[knighthat]

Idk if you made any changes on your end, but I cloned fresh repo straight from github then compiled it and I couldn't seem to recreate the problem.

Here's the queue after my PR

After-cut.mp4

Here's the video before all of my changes

Before-cut.mp4

Did you reset all settings to default?

[twistios]

The queue is correct, the menu is not. I showed the queue to show that the menu is incorrect. In the video you can also see, that it shows 69 for cached while zero are loaded. As it can be seen from the video, I have ~1000 cached songs but at some point it claims that it is ~3000.

[knighthat]

Confirmed! I'm looking into it right now

[twistios]

The funny thing is it says something like 3000 songs for cached and a similar but different value for all (which is correct), so somehow, this number is related but not the same. When it shows the same for favourites and cached, then it really is the same value, so I don't understand it.

[twistios]

This bug also has an interesting side effect: top 10 is fully broken.

Showcase for Top 10 Bug

Screen_Recording_20241124_004906.mp4

[knighthat]

I noticed that too, if you spam it by changing from "all", "favorite", etc. it'll show content from another tab (racing condition). Can't believe I let it slip right through.

A patch is in development. Will push to upstream soon

[knighthat]

The funny thing is it says something like 3000 songs for cached and a similar but different value for all (which is correct), so somehow, this number is related but not the same. When it shows the same for favourites and cached, then it really is the same value, so I don't understand it.

3000 is how many songs existed in the database, if you take a look at the code HERE and HERE you'll see that the query is actually query most if not all records from database, then perform sort after the fetch. With the current implementation of showing how many songs were fetched, it's normal to see large number of songs while not seeing anything on screen

[knighthat]

@twistios I just push a small change HERE. Idk if Git and Github let you cross pull branches from another project. But it'd be helpful if you can give me some feedback on this

[twistios]

I can clone your repo and then checkout the branch. But not today.

[knighthat]

take your time

[twistios]

It seems that I can confirm the fix for the problem.

@knighthat about that you asked me to help you or check something, is it still required and if yes, what should I test?

[knighthat]

I needed you to test the fix, but I went ahead and push it to upstream branch already