My mode of operation is casting to Upmpdcli (headless Ubuntu 22.04) from Symfonium with Jellyfin as the media provider. For the purpose of this issue, I play/queue whole albums.
Starting from version 7.2.0, (most) titles in the playlist play twice in a row, although they are only queued once. I did not observe this in version 7.1.0. It does not matter if I enable/disable gapless playback, or the alternative UPnP mode. I tried all four combinations of the two settings.
Logs:
Upload description: elagil
I queued a whole album. Afterwards, I started logging close to the end of one of the titles (some seconds remaining). Then, the title repeats (although only queued once). After that, I stopped logging some seconds into the repeated title.
Additional information:
I have an album with a very short (30 s) first title. This one does not play twice - as the only title of the album.
Side note: Symfonium also randomly starts playback after an idle period on my UPnP renderer, when previously paused. I don’t know if that is related somehow.
Reproduction steps:
1) Queue whole album
2) Wait for a title to finish
3) Title plays again
4) Next title plays
For the logs to contains everything you need to not be casting, enable logs then connect to upnp renderer and reproduce.
All I can see is
Error creating Cds
java.lang.IllegalArgumentException: Malformed item
at hm.a.<init>(SourceFile:25)
at qq.z.o0(Unknown Source:2)
at qq.z.o1(Unknown Source:67)
at re.z.E(Unknown Source:1359)
at re.i.x(Unknown Source:11)
at ys.a.k(Unknown Source:5)
at wt.i0.run(Unknown Source:109)
at ho.y6.run(Unknown Source:27)
at cu.i.run(Unknown Source:2)
at cu.a.run(Unknown Source:91)
So Upmpdcli returns invalid data that is probably the cause, proper logs would show what to report to the dev that is active.
Trying to reproduce the exact issue as you described, I did not succeed yet. I will retry a few more times.
However, I get a different issue that is somewhat similar to the first one.
Steps I took:
Local playback enabled, as advised
enable debug
Select casting to UPnP
Play song A from album
Seek until close to the end of the song A (here, -16 s)
Wait for next song B
Song B indeed plays
disable debug
So, the correct next song plays, but Symfonium displays information of song A again. Switching back from casting to local playback, Symfonium plays song A, instead of song B that was playing via UPnP.
I see. Yes, I missed reconnecting to the renderer or restarting the application after switching off gapless playback.
Apparently, there were some recent updates to Upmpdcli and libupnp. I will try those first and see if a fix is included. If not, I will raise this issue.
upmpdcli developer here. I just uploaded a log (under my user name: medoc), demonstrating an issue with the detection of track changes using a looped playlist of 2 short tracks, played on gmediarender so that I should not be suspect of upmpdcli favoritism (the same bug is there with upmpdcli too). What happens is that at the end of the second track, the playing does switch back to the first, but the playing indicator and progress bar stays on the second. There are also minor glitches during the first to second track transition.
More generally, according to the UPnP standard (UPnP-av-AVTransport-v1-Service-20020625.pdf) a renderer is under no obligation to return the original data in any form of CurrentURIMetadata or variants (NextURIMetadata, Current/NextTrackMetadata). It can very well return"NOT_IMPLEMENTED" for this data, or data extracted from the stream itself.
The only foolproof indicator of what is currently playing is the URI.
Also by the way, upmpdcli will actually return the original data in general. The only exception that I’m aware of is that if it was just restarted, it will synthetize metadata from the mpd playlist, and this has none of the UPnP Media Server details of course. If it then receives a play action (without a SetURI first), the metadata emitted will be like what you got in the originally uploaded log, and I guess that it is what happened. Tthis is probably a red herring because, if an album is loaded in a running upmpdcli, then a track set to play, you will receive only your original metadata, not the one from mpd.
The issue reported here was different and based on the missing ID value that is mandatory in UPnP if you return an item.
You can return NOT_IMPLEMENTED or you need to return a valid object and in that case the ID is mandatory as per the spec.
The issue in the logs is different and tied to looping on 2 tracks, there’s a workaround for some devices issues with starting media and repeat one and since you loop again to the starting media this triggers so ignore the change. I’ll fix, I just forget to reset a flag when a change of song was done and so that workaround became not necessary.