Music skip to next randomly

Hi Tolriq,

Issue description:

I’m testing Symfonium since yesterday, to remplace DSub.
But randomly, it starts to skip song before it is finished, maybe at 2/3 of the song. After a first occurence, it happens for every song.

Server : Navidrome last version (0.48.0)


Logs are here (I redacted public URL of my instance. But I have original logs if needed).

In logs, issue happens when playing Lomepal - 50°. The song after is Lomepal - À peu près (near 14:57:02 timestamp).


Not applicable

Additional information:

Not applicable

In further logs reading, I saw this : 2023-01-29 14:57:02.663 Verbose/ExoPlayer: positionDiscontinuity [eventTime=17839.18, mediaPos=0.02, window=1, period=1, reason=AUTO_TRANSITION [...]

Maybe AUTO_TRANSITION is the reason ?

AUTO_TRANSITION is when the song is finished and it plays the next.

This sounds like you have forced transcoding on Navidrome side and the transcoding stops.

The other possible issue would be some security / limit on Navidrome that prevent multiple streams and the song stops when Symfonium start buffering the next song for gapless.

Can you provide / check Navidrome logs when it happens?

Ping @deluan to check if there’s such settings or security that could kick in.

Just checked Navidrome : I have 2 players for Symfonium.

  • Symfonium [Symfonium/Android]
  • Symfonium [stagefright/Android]

None have forced transcoding on Navidrome side.
But both had Scrobbles activated : turned off now.

As DSub works as expected (no transcoding too, no Scrobbles, 3 songs in in buffer for gapless), I don’t understand how it can be on Navidrome side.

I’m away from home for now, will check Navidrome logs in few hours.

Thanks for give your time on this !

The X does work so it’s not Y the cause :slight_smile: Wonder how many times I get that answer.

If you want to achieve the DSub kind of Gapless in Symfonium you need to enable the option Playback cache in the settings else the comparison is completely irrelevant already on that point, not talking about all the other pieces involved.

Anyway I can only answer based on the logs you provide, in those logs there’s absolutely no errors just normal transitions, in that case 90% of the time it’s a issue external to the player.

Since from your description it happens randomly and not always on the same songs, I suppose this is not because of the format of the songs too.

That does not leave a lot of possibilities.

You can still try to uncheck the option prefer internal decoder, in case there’s a bug on ffmpeg and your device / files, but I would probably heard about that already.

Understand you first sentence, but I tried other compatible players (substreamer, …) and Symfonium is the only one whit that issue : it’s easy to think that if multiple X work, Y should too :wink:

Playback cache is enabled.
Tried with prefer internal decoder to off, same issue.

Will trie when able to read Navidrome logs ASAP.

Playback cache is enabled in the logs you uploaded ? It does not match that.

it’s easy to think that if multiple X work, Y should too

And yet not at all, simple example would be how Symfonium is the only real offline first app that do full database sync. No other app do leverage the search3 endpoint for that. (Some readings Subsonic API extensions - Symfonium support :wink: )
So the fact that all other apps would be able to do X would be 100% irrelevant as not using the same endpoint at all.

In the same idea, you could test E10 fuel in thousands of cars that would work, it would still not work on the one diesel car.

Playback cache was not enabled at logs time, but it is now :wink:

Then I need new logs with it as it might have more details about download issue from server.

Actually making further tests :

  • Playback cache is enabled (128MB)
  • Prefer internal decoder disabled
  • Debug mode for Symfonium
  • Navidrome logs accessible

But, I looked to old Navidrome logs, this is what I found : Jan 29 16:04:07 navidrome navidrome[6594]: time="2023-01-29T16:04:07Z" level=warning msg="Request was interrupted" error="context canceled" path=stream (time is UTC, need to add 1h).

Earlier today, I added some settings to my HAProxy configuration, relative to Navidrome : connection and server timeout (to 10 minutes).
→ it’s 5 or 6 songs without any problem right now (no more same warning in Navidrome logs)

So, you seem to be right : 5 X and 1 Y can work differently :smiley:
I’m not a network expert, any thought about how you handle network/stream connection ?

I will run long play session tomorrow, after that I will be able to confirm that everything is working (and pay for the license :slight_smile:)

It’s hard to know for sure, but Symfonium is top of the notch :wink: So depending on your proxy it can use HTTP/2 or even HTTP/3. It will reuse connection and fully embrace HTTP/1.1.
Things that most app wont.

Furthermore there’s many optimisations in the caches and buffer sizes so it’s possible there’s no read for some duration and your server decide to wrongly close the connection.
Could also be a navidrome limit if your proxy handle HTTP/2 and tries to open too many connection to Navidrome and do not close them fast enough for Navidrome.

You can probably see more on the proxy and Navidrome logs. Deluan is Navidrome author and I named it earlier, he will probably jump in if he have some details about those.

For the record if you want to really use the playback cache, it’s better to use at least 256Mb to have more songs pre cached at max speed to handle longer tunnels :slight_smile:

Just re-enabled internal decoder : issue is here again (to be sure, tested on another album).

Re-disabled internal decoder : issue stills here (see next message for links to logs).

Nothing to see in HAProxy logs : only connections (i.e. 2023-01-29T20:54:02 Informational haproxy Connect from REDACTED:58952 to (HTTPS_Frontend/HTTP)).
Switched to debug logs, actually make further tests (with some other fine tuning on fronteds).

For the record if you want to really use the playback cache, it’s better to use at least 256Mb to have more songs pre cached at max speed to handle longer tunnels :slight_smile:

Always stayed to 3 songs in DSub, no issue as I don’t have tunnels :wink:

Just run in flagged as spam because Pastebin links :slight_smile:
Will try to edit precedent message when I can.

Here is logs that I was talking :

  • Symfonium logs : pastebin[.]com/EdPVHeSR (near 20:33:09, skipping from Saycet - Half Awake to Saycet - Northern lights)
  • Navidrome logs : pastebin[.]com/JWgpWpxu (need to add 1 hour to logs)

But, since last tuning in HAProxy, it seems good : 3 songs without skip.

As I said, I will show tomorrow, on long listening session, if it is OK or not.

Hum pining @deluan again about the “level=warning msg=“Request was interrupted” error=“context canceled” path=stream”

According to level=warning msg="Request was interrupted" error="context canceled" path=stream · Issue #2000 · navidrome/navidrome · GitHub they are not the issue, but there’s no coincidence here.

Saw yesterday in logs : 2023-01-29 20:21:34.188 Error/ExoCacheManager: Unable to initialize cache!
→ I remember that, at the first open of Symfonium, I didn’t have any invitation to authorize access to storage (needed to authorize manually yesterday evening)
→ Shouldn’t Symfonium request authorization to access the storage, at first start?

Today, first session of 40mn of listening : no problem.

Second session of maybe 20-30mn of listening : no problem, and logs show that cache is enabled and working.

2023-01-30 09:49:51.260 Verbose/ExoCacheManager: Caching: d5d4332e-a857-42a3-b894-c8377b0916f6[false][B:-1-Vald/NQNT33/Mana.flac] - Mana
2023-01-30 09:49:51.260 Verbose/ExoCacheManager: Cached: d5d4332e-a857-42a3-b894-c8377b0916f6[false][B:-1-Vald/NQNT33/Mana.flac] 16.9 MB - Mana```

There’s no need for permissions for the playback cache at all.

That error was caused because of all your attempts and at some point a lock was not released. Unfortunately the logs don’t show how you reached that point.

In all cases if you found the proper HAProxy configuration, would be nice to give the details here for the others that may face the same issue.

There’s no need for permissions for the playback cache at all.

That error was caused because of all your attempts and at some point a lock was not released. Unfortunately the logs don’t show how you reached that point.

So, just needing to select storage location in Advanced settings (if needed ; I just have internal storage in this smartphone), and no permissions ?
Absolutely not an Android/Kotlin/whatever related expert, it seems to me strange but OK !

For HAProxy, as each installation is different, it’s hard to define what is working for everyone.
But, on mine, I needed to add some client, server, connection, http-request and http-keep-alive timeouts, on frontends and/or backend (examples below are not fine tuned actually) :

frontend HTTP_Frontend
    timeout client 10m
    timeout http-request 10m
    timeout http-keep-alive 10m
frontend HTTPS_Frontend
    timeout client 10m
    timeout http-request 10m
    timeout http-keep-alive 10m
backend NAVIDROME_backend
    timeout connect 10m
    timeout server 10m

As I had change some settings in Symfonium and in HAProxy, I need to restart all testing process to show what is mandatory and what is not.

All apps are allowed to write in their own folder without permission, else no apps would even be able to save a single setting without asking for permissions and that would be a complete mess.

Make sense, just used to permit other applications to access to all storage.
Thanks for the clarification.

Will test again this noon, and try to fine tune all of this.