[BUG] - Instant Mix does not work

[SnoutBug]

Describe the bug

Instant mixes do not get any tracks from gonic.

To Reproduce

Outline the steps required to reproduce the bug, including any specific actions, inputs, or conditions:

1. Three dots
2. Instant mixes
3. Song plays but no other songs are queued

Environment

• App version: 4.6.0
• App variant: degoogled
• Other relevant details: gonic

Additional context

This error seems to be due to the app sending a wrong artist, in my case tr-654 which does not exist.
It should be ar-126.

getSimilarSongs2 is used but for tr- i think getSimilarSongs should be used instead.

[eddyizm]

Hi @SnoutBug,
This is a duplicate I believe. #293 has this as one of it's findings however I was dealing with crashing over there first. so I may close that and leave this open.

If you could help me by being very specific, as the InstantMix call gets routed, slightly different from each screen, eg it is handled by different repositories, that would be helpful on where you are seeing it, if everywhere, that would also help.

That being said, I mentioned in the other ticket that the single track has been an issue from before I forked this repo. The api is just returning an empty array. I tested a couple of things today, one, on an obscure track with poor tags, it returned a single track,

Tested this from the home /artist and then as well as a single individual track. With a more popular or well know track, the endpoint responded with a full list of tracks.

If I could have you test your endpoints with your problem track you identified, that would help as well.

for example, i'm using token based auth so my call looks like this from the album side. You should be able to swap your stuff in and post your response - I would be curious what the server responds with and if you change the endpoint from
getSimilarSongs2 to getSimilarSongs to see if the results change.

The original similar song call is still in the code base but is not being used/called anywhere. I think this may be an api issue and have considered some work around for libraries that struggle with this, basically trying to chain a random songs call to an empty result set but I have not gotten there yet.

See my results below:

# getSimilarSongs2 album works
curl -X 'GET' \
    "https://myserver.com/rest/getSimilarSongs2?p=<TOKEN>&c=Tempus&u=<USERNAME>&v=1.15.0&f=json&id=al-5034&count=20" \
    -H 'accept: application/json' | jq .

Response (truncated on the first entry

{
  "subsonic-response": {
    "openSubsonic": true,
    "serverVersion": "v3.73.0",
    "status": "ok",
    "type": "lms",
    "version": "1.16.1",
    "similarSongs2": {
      "song": [
        {
          "album": "Fleshwork",
          "albumId": "al-5034",
          "artist": "Pupil Slicer",
          "artistId": "ar-5658",
          "bitDepth": 0,
          "bitRate": 128,
          "channelCount": 2,
          "comment": "https://pupilslicer.bandcamp.com/track/black-scrawl-2",
          "contentType": "audio/mpeg",
          "coverArt": "art-3588-1762534733",
          "created": "2025-11-08T00:00:02.717Z",
          "discNumber": 1,
          "displayAlbumArtist": "Pupil Slicer",
          "displayArtist": "Pupil Slicer",
          "duration": 205,
          "explicitStatus": "",
          "id": "tr-51676",
          "isDir": false,
          "mediaType": "song",
          "musicBrainzId": "72855843-c157-4f0f-9101-ad7a8c7405d1",
          "path": "P/Pupil.Slicer/fleshwork/05.PUPIL SLICER - Black Scrawl.mp3",
          "playCount": 1,
          "played": "2025-11-14T21:42:53.000Z",
          "samplingRate": 44100,
          "size": 3377199,
          "suffix": "mp3",
          "title": "Black Scrawl",
          "track": 5,
          "transcodedContentType": "audio/mpeg",
          "transcodedSuffix": "mp3",
          "type": "music",
          "year": 2025,
          "replayGain": {},
          "albumartists": [
            {
              "id": "ar-5658",
              "name": "Pupil Slicer"
            }
          ],
          "artists": [
            {
              "id": "ar-5658",
              "name": "Pupil Slicer"
            }
          ],
          "contributors": [],
          "genres": [],
          "moods": []
        },
     

for a single track call (this one is set to bring back 10 records max

curl -X 'GET' \
    "https://myserver.com/rest/getSimilarSongs2?p=<TOKEN>&c=Tempus&u=<USERNAME>&v=1.15.0&f=json&id=tr-44468&count=10" \
    -H 'accept: application/json' | jq .

Also truncated on the first response, but note that my request is a tr-44468 -
looks like the endpoint per the docs is expecting an artistID but is processing these other values
https://opensubsonic.netlify.app/docs/endpoints/getsimilarsongs2/

{
  "subsonic-response": {
    "openSubsonic": true,
    "serverVersion": "v3.73.0",
    "status": "ok",
    "type": "lms",
    "version": "1.16.1",
    "similarSongs2": {
      "song": [
        {
          "album": "CantaGallo",
          "albumId": "al-4209",
          "artist": "El-Haru Kuroi",
          "artistId": "ar-5615",
          "bitDepth": 0,
          "bitRate": 320,
          "channelCount": 2,
          "comment": "",
          "contentType": "audio/mpeg",
          "coverArt": "art-889-1675016040",
          "created": "2024-10-02T19:52:30.346Z",
          "discNumber": 1,
          "displayAlbumArtist": "El-Haru Kuroi",
          "displayArtist": "El-Haru Kuroi",
          "duration": 318,
          "explicitStatus": "",
          "genre": "Latin",
          "id": "tr-49065",
          "isDir": false,
          "mediaType": "song",
          "musicBrainzId": "f3c182f5-5b13-4fc1-bf28-5317be16a619",
          "path": "E/el haru kuroi-Cantagallo/09 Trabajo No-El-Haru Kuroi.mp3",
          "playCount": 0,
          "played": "",
          "samplingRate": 44100,
          "size": 13883587,
          "suffix": "mp3",
          "title": "Trabajo No",
          "track": 9,
          "transcodedContentType": "audio/mpeg",
          "transcodedSuffix": "mp3",
          "type": "music",
          "year": 2012,
          "replayGain": {},
          "albumartists": [
            {
              "id": "ar-5615",
              "name": "El-Haru Kuroi"
            }
          ],
          "artists": [
            {
              "id": "ar-5615",
              "name": "El-Haru Kuroi"
            }
          ],
          "contributors": [],
          "genres": [
            {
              "name": "Latin"
            }
          ],
          "moods": []
        },

[SnoutBug]

I hope I did not miss anything, if I did let me know and I'll test that. But I am guessing most cases should work the same way.

1. Library -> "All Albums Folder" -> "Album Folder" -> Track -> Instant Mix = Track plays, but no instant mix is created
2. Home -> Discovery -> Track -> IM = same as 1.
3. Home -> Album -> IM = No track plays, no instant mix created
4. Home -> Album -> Track -> IM = same as 1.
5. Artist -> Radio = Tracks play, mix is created
6. Artist -> Track -> IM = same as 1.

Endpoint testing:

GET
/rest/getSimilarSongs2?s=XXX&c=Tempus&t=XXX&u=XXX&v=1.15.0&f=json&id=tr-654&count=1

{
  "subsonic-response": {
    "status": "failed",
    "version": "1.15.0",
    "type": "gonic",
    "serverVersion": "0.19.0",
    "openSubsonic": true,
    "error": {
      "code": 10,
      "message": "please provide an artist `id` parameter"
    }
  }
}

GET
/rest/getSimilarSongs?s=XXX&c=Tempus&t=XXX&u=XXX&v=1.15.0&f=json&id=tr-654&count=1

{
  "subsonic-response": {
    "status": "ok",
    "version": "1.15.0",
    "type": "gonic",
    "serverVersion": "0.19.0",
    "openSubsonic": true,
    "similarSongs": {
      "song": [
        {
          "id": "tr-655",
          "album": "F \\u0026 M (Deluxe)",
          "albumId": "al-120",
          "artist": "Lindemann",
          "artists": [
            {
              "id": "ar-126",
              "name": "Lindemann"
            }
          ],
          "displayArtist": "Lindemann",
          "albumArtists": [],
          "displayAlbumArtist": "Lindemann",
          "bitRate": 1701,
          "contentType": "audio/flac",
          "coverArt": "tr-655",
          "created": "2025-12-07T04:10:36.394872967Z",
          "duration": 289,
          "isDir": false,
          "isVideo": false,
          "parent": "al-120",
          "path": "Lindemann - F \\u0026 M (Deluxe) (Explicit)/02. Lindemann - Ich weiß es nicht (Explicit).flac",
          "size": 63068310,
          "suffix": "flac",
          "title": "Ich weiß es nicht",
          "track": 2,
          "discNumber": 1,
          "type": "music",
          "year": 2019,
          "musicBrainzId": "",
          "replayGain": null
        }
      ]
    }
  }
}

This also works with the default 20 songs.

[eddyizm]

@SnoutBug Thanks for doing this, it is very helpful!

[eddyizm]

@SnoutBug Would you be open to giving me a temp account to test against your server? You can send use my username here at gmail or use the contact form on my site, eddyizm.com

if not, I will continue to test and get you an debug apk to test. The instant mix is tangled in quite a few places so I am trying to consolidate it into one place and hopefully get it sorted out.

[SnoutBug]

Unfortunately, you will not be able to test as my gonic is not public.

I'd be willing to test with an apk, however I think, for testing purposes, gonic is quite simple to set up.

[eddyizm]

@SnoutBug
I added a debug apk (degoogled version) but the debug namespace should allow you to install it side by side to test with the changes in the PR ->
#330

[SnoutBug]

@eddyizm that's awesome! From the short testing I did instant mix seems to work now. However, when creating a mix from any track the first track will be played twice.

I am guessing the track is somehow queued twice, as the endpoint itself does not return a duplicate track.

A different behaviour is the following:
When creating an instant mix from a song from "recently played tracks" Tempus will call the correct endpoint (getSimilarSongs), but no tracks are appended to the queue.
The endpoint works as expected and returns a list of tracks.

[eddyizm]

@SnoutBug Thanks for testing it. I have more updates coming to as I was still tuning it up. I knew this would be a larger refactor but I will have another debug apk to give it a little bit more testing.

[eddyizm]

@SnoutBug I tracked down the bugs you mentioned and spent significant time testing on my end to try and get all the different areas it is used. I found the same initial track issue and resolved it (in more than one place) -
i also updated the fallback logic and it seems to be working now in my rounds of testing on albums, artists, along with all the instant mix calls.

This is labeled v4.6.2.BETA [https://docs.eddyizm.com/app-degoogled-arm64-v8a-v4.6.2.BETA.apk](https://docs.eddyizm.com/app-degoogled-arm64-v8a-v4.6.2.BETA.apk

This feels really close to done (not perfect by any means) so please let me know if you find anything that is goofy or plain broken.

[SnoutBug]

The double queueing is fixed, awesome! Also the fallback seems to work everywhere.
This gave the idea that whether it is useful to know when the fallback was used or actual similar songs were found. (But this should be out of scope for this issue)

One thing I noticed with, I think, only one of my tracks in my library:

The track in question was listed as first in "most played". When attempting to create an instant mix,

Tempus requested:

GET
/getSimilarSongs?s=XXX&c=Tempus&t=XXX&u=XXX&v=1.15.0&f=json&id=tr-536&count=9

And received:

{
  "subsonic-response": {
    "status": "failed",
    "version": "1.15.0",
    "type": "gonic",
    "serverVersion": "0.19.0",
    "openSubsonic": true,
    "error": {
      "code": 70,
      "message": "no similar song could be match with collection in database: Strobe"
    }
  }
}

However, the fallback did not seem to trigger (is this intended?)
This happens most of the times, only sometimes matching tracks are queued.

I noticed that mutiple getSimilarSongs requests were made when creating the instant mix.

First

GET
/getSimilarSongs2?s=XXX&c=Tempus&t=XXX&u=XXX&v=1.15.0&f=json&id=ar-123&count=19

Which contains the corresponding ar which returns a list of tracks and then

GET
/getSimilarSongs?s=XXX&c=Tempus&t=XXX&u=XXX&v=1.15.0&f=json&id=tr-536&count=9

which returns the error from above.

In short: both requests are always made, one is always successful and one is always unsuccessful.
Similar tracks are only sometimes queued, while most of the times, the queue remains empty.

This seems to me like an edge case but maybe you know what might be going on here.

[eddyizm]

@SnoutBug
there are a lot of paths to the IM. I'm in the process of writing up the changes but generally speaking there should be roughly 3 api calls max, routed through one of these basic types

   private void performSmartMix(final String id, final SeedType type, final int count, final MediaCallbackInternal callback) {
        switch (type) {
            case ARTIST:
                fetchSimilarByArtist(id, count, callback);
                break;
            case ALBUM:
                fetchAlbumSongsThenSimilar(id, count, callback);
                break;
            case TRACK:
                fetchSingleTrackThenSimilar(id, count, callback);
                break;
        }
    }

1. one should go to appropriate repo but then routes back to the song repo above
2. then when its an artist, it falls to a second similarSong2 by artist id (same for the album branch) song just goes to similar)
3. ideally if the count has not been reached, sometimes i noticed it is 10 or 20 i did not track all of them as I think a setting will be better later but i do want to limit the amount of calls, should fall back to a random songs call - This was much harder than expected to implement as getting the queue to start to play and then appending to the queue without something really weird happening or slowing down the UI was really challenging.

I think i got most of the way there but as you noticed, It is hard for me to handle the failed responses , or rather, replicate them to handle them correctly without being able to test on the server. I'm not realy a java/mobile dev so I'm learning the codebase as well as the tooling.

I was able to trigger some instances on poorly tagged tracks (homemade mp3's) to trigger a fall back to the fillWithRandom but it was not easy to replicate that throughout the different entry points.

Is it a particular track that always causes it? I'm actually surprised that it returns a failed, what is the http code? I feel like the proper response should be an empty array with no tracks

I want to say that I am at the mercy of the api response but in reality I just need access to unique environments since everyone has something interestingly different in either the server implementation or song collection. Handling tracks from around the globe has been interesting to say the least.

I will take a look, i think the fallback dilemma is due to network response time. I had to increase a debounce to account for a refresh or dismissal of the bottom sheet fragments.

[eddyizm]

@SnoutBug ok I used the ampache demo server and was able to recreate the failed response issue you encountered.
1st call got the ep tracks (3 tracks)
2nd one failed with no similar artist/tracks like your example
3rd fired random tracks and return 17,

set the queue up with 3 songs.

The song repo logic actually worked as expected however the UI did not refresh because the debounce is set at 300 ms and that final call ended up taking 1.2 seconds from the original start - I changed the debounce to 1500ms and it worked, sort of, because it had so few tracks one of the original 3 tracks was included in the 17 response tracks (20 tracks, one dupe)

I think I can fix that duplicate to check the queue however the debounce value is going to be a challenge because network latency is a b. lol