Casting from lms to upmpdcli repeats songs

Support
1

Issue description:

When casting from Symfonium to upmpdcli, at the end of a song it starts playing the next song without changing to it in the UI/MediaSession. Then when the 2nd song (still displayed as the first) finishes playing, it actually changes to the second song in the UI and plays it again. Thus each song except for the first is played twice.

Logs:

Upload description: 655321 lms upmpdcli casting repeated songs

Additional information:

 
To rule out battery optimization features being the culprit I left the display on the entire time.
I also tried disabling “UPnP alternative flags” for the device, stopped casting, closed Symfonium, opened it again and started casting again but the issue persists.
 

Reproduction steps:

 

  1. Queue multiple songs in Symfonium.
  2. Cast to upmpdcli.
  3. Wait for song A to finish.
  4. Song B is played but the UI and MediaSession still display song A.
  5. Wait for song B to finish.
  6. The UI switches to song B and plays it again.
     

Media provider:

Subsonic

Screenshots:

     

2

do you use a proxy and send basic auth headers ?

3

I do. Should I turn that back off? I use nginx proxy manager as a reverse proxy and basic header auth to be exact.

4

This is usually not supported by upnp but strangely it seems upmpdcli does.

@medoc do you support basic auth in urls ?

I guess yes since it works but then you return the url without the header so Symfonium does not match the active media.

I suppose you remove the user:password from the url for privacy reasons?

And in those logs the ids are “mpdid:35” not the one I send and would have worked too.

5

Do you mean would a URL like http://user:pass@host/… be passed to mpd to be fetched from the media server ?
I guess that it would, I don’t think that there is any URL parsing done at all inside upmpdcli. mpd then fetches the data, through curl, so it seems plausible that the credentials are used by curl, and possibly stripped by mpd when reporting state. Maybe the mismatch causes upmpdcli to then generate DIDL data from the mpd state and not from the original received DIDL, which would also explain the mpdid thing. This is all guesswork at this point.

If this is indeed what is happening, the fix would be to ignore the credentials when comparing URLs , but this would need URL parsing inside upmpdcli, so this is not a very small change.

6

@medoc
I can also workaround on my side but your explanation matches everything happening in his case.

But I guess that having the proper ids inside upnpmdcli could help other clients that can’t workaround.

Anyway the workaround on my side is not that complicated so I’ll do it.
Fixing on your side if too much work is probably not worth it as in theory those urls are nearly never supported by upnp renderers.

1 Like
7

It does make sense to ignore the creds when comparing URLs, I’ll take a look at changing this next time I am around the code.

2 Likes
8

I got curious and connected my Onkyo AVR to the wifi for a while to see if it can handle the basic auth.
The built-in UPnP does, the built-in Chromecast does not.
I guess the UPnP of the Onkyo is garbage tho as it always stops playback after 1 track.
No matter if I cast from lms with basic auth, from jellyfin (no basic auth) or from the local provider in Symfonium.
I created logs of it stopping to play after 1 song. I could upload these if you’re curious but I personally don’t really care since I don’t use the AVR for that. :grinning:

9

Onkyo often have issues with gapless and needs it disabled.

Yes Chromecast does not support basic auth but Symfonium should be proxying on that case will check.

So the should proxy check did not take in account the basic auth only the headers, fixing the check for Chromecast will also fix UPnP by making Symfonium proxy too.

If you do not want to proxy via the phone to upnp you should not use the basic auth.

10

I tried all 4 combinations of alternative flags on/off and gapless on/off, it always stops playback after 1 song. I can collect logs with gapless off if you’re interested.

Does that mean Symfonium would still proxy when casting to upmpdcli even if/when medoc adds url parsing?

11

Yes it will proxy as it’s the same path for both, but in all case basic auth headers does not really add any kind of security.

For Onkyo you don’t use the device so let’s ignore it :slight_smile: