Media provider secondary connection usage?

Issue description:

Hello,

Following my previously reported issues with track skipping and/or not playing, I’ve reworked my network topology.
Not having symfonium connect through a reverse proxy helped greatly with the overall stability.

I use a livebox, which doesn’t support loopback.

I now connect directly to the media server, without hopping through a reverse proxy, with a local domain only reachable on this lan.

I’ve thought of using the secondary connection to fill in my publicly available domain (which works all in itself), but once I’m outside my lan symfonium still try to reach my locally available domain only and doesn’t fallback to the secondary connection.

My local domain is not a registered tld.

Am I using this feature wrongly or is there an issue there?

Logs:

Upload description: whinette

Additional information:

 

 

Reproduction steps:

 
Logged this:
launch app with wifi active
sync library
sync finish
deactivate wifi
turn off media lib
turn on media lib
sync library
observe media library is offline
 

Media provider:

Subsonic

Screenshots:

     

It does fallback after a couple of connection issues and can requires to press the reconnect button in the filter.

Pressed 20 times to no avail, still offline.

I will check the logs.

Does your router support NAT reflection? Mine does, so I just use my domain as the only address in symfonium. When I’m on LAN, the router sees that the IP the domain points to is itsown and routes the traffic within the LAN without needing to go out to wan and come back.

2025-08-03 16:04:38.228 Verbose SubsonicLogger  --> [955] GET https://https//lms.xxx.fr:443/rest/ping.view?apiKey=REDACTED&v=1.13.0&c=Symfonium&f=json

You entered the wrong values in the secondary connection part :wink:

Thanks!

I entered https://lms.xxx.fr in the second field, it may be doubling the https as you shown in the log.

I’m not at home and can’t validate the change for now, I’ll come back this evening :slight_smile:

@Ben1424 sadly no, this is a limitation from my isp

Confirming everything works as intended after removing https from the connection string. :slight_smile:

My playback issues came back, so I checked around a bit and it looks like the secondary connection has persistence, even after killing symfonium or rebooting the phone.

It seems a bit moot?

I will try setting up two different provider, hopefully the queues are provider independant. :slight_smile:

It switch between both as needed if the secondary still works then it’s used.

Ok. This is not the behaviour I was expecting.

I expected to have the secondary connection tried only when the first connection is unreachable.

I suppose that code wise this may increase latency for all the calls, so that wouldn’t be proper at all.

Can this middle ground be acceptable? Switch back to primary connection when application is started. It falls back to secondary connection if primary connection isn’t available and keep it as is as far as the application stays in the app history / phone is restarted.

Or having a button in the provider to force switch between the two connection would also work for my usage.

Again the switch is done if the connection does not work.

So what is your actual need to switch the connexion while it still works ?

symfonium reach my public domain, most of my receivers don’t (only one that does is upmpdcli, which isn’t deployed everywhere).

Enable proxy mode in Symfonium for those receivers or update network to allow access.

There’s no notion of app start on Android, and no reason to check non stop to fallback.

Proxying makes the track skips after a while (cf Casting to external renderer sometimes skips in middle of track - #8 by whinette )

I will lookup for other solutions / other app setup for my local usage.

Just use DNS views ?

This is somehow what I do and that doesn’t work well:

I do TLS termination at ingress level.

I have DNS rewrite to point to the ingress (which does reverse proxy) on my lan.

The only difference between the two endpoint is that reverse proxy (and the tls session).

I’ve double checked the proxy configuration and it looks good to me:

proxy_request_buffering off;
proxy_buffering    off;
proxy_buffer_size  4k;
proxy_read_timeout 10m;
proxy_send_timeout 10m;
keepalive_timeout  10m;

I will dig further once I have more time. :slight_smile: As it looks like dns rewrite and dns view are different concepts (I did not knew the second one).