# Casting albums to UPnP plays songs twice **URL:** \ **Category:** Support\ **Tags:** handled\ **Created:** [January 18, 2024, 5:59pm UTC](http://support.symfonium.app/t/casting-albums-to-upnp-plays-songs-twice/3263 "2024-01-18T17:59:20Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![elagil](http://support.symfonium.app/letter_avatar_proxy/v4/letter/e/c57346/32.png) [@elagil](http://support.symfonium.app/u/elagil)\ **Post date:** [January 18, 2024, 5:59pm UTC](http://support.symfonium.app/t/casting-albums-to-upnp-plays-songs-twice/3263/1 "2024-01-18T17:59:20Z")
## Issue description: 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  ## Media provider: Jellyfin ## Screenshots:       ---
**Author:** ![Tolriq](http://support.symfonium.app/user_avatar/support.symfonium.app/tolriq/32/726_2.png) [@Tolriq](http://support.symfonium.app/u/Tolriq)\ **Post date:** [January 18, 2024, 8:16pm UTC](http://support.symfonium.app/t/casting-albums-to-upnp-plays-songs-twice/3263/2 "2024-01-18T20:16:04Z")
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 ```auto Error creating Cds java.lang.IllegalArgumentException: Malformed item at hm.a.(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. ---
**Author:** ![elagil](http://support.symfonium.app/letter_avatar_proxy/v4/letter/e/c57346/32.png) [@elagil](http://support.symfonium.app/u/elagil)\ **Post date:** [January 18, 2024, 9:15pm UTC](http://support.symfonium.app/t/casting-albums-to-upnp-plays-songs-twice/3263/3 "2024-01-18T21:15:30Z")
Ok, I see. 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. Logs are found under `elagil1`. Thank you in advance! ---
**Author:** ![Tolriq](http://support.symfonium.app/user_avatar/support.symfonium.app/tolriq/32/726_2.png) [@Tolriq](http://support.symfonium.app/u/Tolriq)\ **Post date:** [January 19, 2024, 7:51am UTC](http://support.symfonium.app/t/casting-albums-to-upnp-plays-songs-twice/3263/4 "2024-01-19T07:51:55Z")
So yes this is an Upmpdcli bug that needs to be reported to him. They do not return the mandatory ID in the `CurrentURI` answer of `GetMediaInfoResponse` but strangely correctly returns it in `NextURIMetaData` You can tell him that Symfonium sends : ```xml 0https://xxxxx:443/Audio/7122a96aa553d4e4feb97eb756e0bb71/stream.flac?static=true&dlnaheaders=true&api_key=REDACTED<DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:sec="http://www.sec.co.kr/" xmlns:dc="http://purl.org/dc/elements/1.1/"><item restricted="1" id="9ede03cf-38ed-4ed1-9fb7-4771b8c0a26a" parentID="0"><upnp:album>Day Breaks</upnp:album><upnp:class>object.item.audioItem.musicTrack</upnp:class><upnp:genre>Contemporary Jazz</upnp:genre><upnp:artist>Norah Jones</upnp:artist><res duration="00:03:41" protocolInfo="http-get:*:audio/flac:DLNA.ORG_PN=FLAC;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000" size="23137911">https://xxxxx:443/Audio/7122a96aa553d4e4feb97eb756e0bb71/stream.flac?static=true&amp;dlnaheaders=true&amp;api_key=REDACTED</res><upnp:originalTrackNumber>3</upnp:originalTrackNumber><upnp:albumArtURI>http://10.10.20.225:38349/db75674c1384426f138fe11b54b71eeb/%2Fstorage%2Femulated%2F0%2FAndroid%2Fdata%2Fapp.symfonik.music.player%2Fcache%2Fimages%2FB%2FBCE6FE67116A24E255E3F2A526C71ADA.jpg</upnp:albumArtURI><dc:title>Flipside</dc:title></item></DIDL-Lite> ``` But then he answers: ```xml 1 0:03:41 https://xxxxx:443/Audio/7122a96aa553d4e4feb97eb756e0bb71/stream.flac?static=true&amp;dlnaheaders=true&amp;api_key=REDACTED <?xml version="1.0" encoding="utf-8"?><DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/"><item restricted="1" searchable="0"><dc:title>Flipside</dc:title><orig>mpd</orig><upnp:class>object.item.audioItem.musicTrack</upnp:class><upnp:album>Day Breaks</upnp:album><upnp:originalTrackNumber>3</upnp:originalTrackNumber><res bitrate="653000" sampleFrequency="44100" bitsPerSample="16" nrAudioChannels="2">https://xxxxx:443/Audio/7122a96aa553d4e4feb97eb756e0bb71/stream.flac?static=true&amp;dlnaheaders=true&amp;api_key=REDACTED</res><upnp:genre>Contemporary Jazz</upnp:genre><dc:creator>Norah Jones</dc:creator><upnp:artist>Norah Jones</upnp:artist></item></DIDL-Lite> https://xxxxx:443/Audio/2517b741582a4d638280b0f889202c10/stream.flac?static=true&amp;dlnaheaders=true&amp;api_key=REDACTED <DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:sec="http://www.sec.co.kr/" xmlns:dc="http://purl.org/dc/elements/1.1/"><item restricted="1" id="2382a7db-e3ff-42f5-ad6a-8ad08ed077ba" parentID="0"><upnp:album>Day Breaks</upnp:album><upnp:class>object.item.audioItem.musicTrack</upnp:class><upnp:genre>Contemporary Jazz</upnp:genre><upnp:artist>Norah Jones</upnp:artist><res duration="00:03:53" protocolInfo="http-get:*:audio/flac:DLNA.ORG_PN=FLAC;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000" size="20410056">https://xxxxx:443/Audio/2517b741582a4d638280b0f889202c10/stream.flac?static=true&amp;dlnaheaders=true&amp;api_key=REDACTED</res><upnp:originalTrackNumber>4</upnp:originalTrackNumber><upnp:albumArtURI>http://10.10.20.225:38349/db75674c1384426f138fe11b54b71eeb/%2Fstorage%2Femulated%2F0%2FAndroid%2Fdata%2Fapp.symfonik.music.player%2Fcache%2Fimages%2FB%2FBCE6FE67116A24E255E3F2A526C71ADA.jpg</upnp:albumArtURI><dc:title>It’s a Wonderful Time for Love</dc:title></item></DIDL-Lite> NETWORK NOT_IMPLEMENTED NOT_IMPLEMENTED ``` So no Id for CurrentURIMetaData this breaks UPnP contract. Even if he loose the ID I send he must return one. ---
**Author:** ![elagil](http://support.symfonium.app/letter_avatar_proxy/v4/letter/e/c57346/32.png) [@elagil](http://support.symfonium.app/u/elagil)\ **Post date:** [January 19, 2024, 8:07am UTC](http://support.symfonium.app/t/casting-albums-to-upnp-plays-songs-twice/3263/5 "2024-01-19T08:07:15Z")
Thanks for the insight, I will report to the author of that application then. I could also replicate the original issue now with the logs `elagil2`. I guess it would be the same cause. ---
**Author:** ![Tolriq](http://support.symfonium.app/user_avatar/support.symfonium.app/tolriq/32/726_2.png) [@Tolriq](http://support.symfonium.app/u/Tolriq)\ **Post date:** [January 19, 2024, 8:10am UTC](http://support.symfonium.app/t/casting-albums-to-upnp-plays-songs-twice/3263/6 "2024-01-19T08:10:13Z")
Yes since you enable upnpgapless and Symfonium can’t read the media playing it can’t know what to do. Disabling gapless (and restarting the app/ stop casting then casting again something you probably did not do) should workaround that. But if he fixes gapless will work. ---
**Author:** ![elagil](http://support.symfonium.app/letter_avatar_proxy/v4/letter/e/c57346/32.png) [@elagil](http://support.symfonium.app/u/elagil)\ **Post date:** [January 19, 2024, 8:21am UTC](http://support.symfonium.app/t/casting-albums-to-upnp-plays-songs-twice/3263/7 "2024-01-19T08:21:25Z")
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. I will report back, if there is an update. ---
**Author:** ![splinter](http://support.symfonium.app/user_avatar/support.symfonium.app/splinter/32/10_2.png) [@splinter](http://support.symfonium.app/u/splinter)\ **Post date:** [January 19, 2024, 11:37am UTC](http://support.symfonium.app/t/casting-albums-to-upnp-plays-songs-twice/3263/8 "2024-01-19T11:37:11Z")
The dev from upmpdcli is very responsive and fixes issues quickly. You can open a ticket through his page, did that a couple of times. ---
**Author:** ![medoc](http://support.symfonium.app/letter_avatar_proxy/v4/letter/m/4bbf92/32.png) [@medoc](http://support.symfonium.app/u/medoc)\ **Post date:** [March 1, 2024, 7:41am UTC](http://support.symfonium.app/t/casting-albums-to-upnp-plays-songs-twice/3263/9 "2024-03-01T07:41:49Z")
Hello, 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. ---
**Author:** ![Tolriq](http://support.symfonium.app/user_avatar/support.symfonium.app/tolriq/32/726_2.png) [@Tolriq](http://support.symfonium.app/u/Tolriq)\ **Post date:** [March 1, 2024, 9:24am UTC](http://support.symfonium.app/t/casting-albums-to-upnp-plays-songs-twice/3263/10 "2024-03-01T09:24:16Z")
@medoc 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. ---
**Author:** ![tappsz](http://support.symfonium.app/user_avatar/support.symfonium.app/tappsz/32/1841_2.png) [@tappsz](http://support.symfonium.app/u/tappsz)\ **Post date:** [June 16, 2025, 2:32pm UTC](http://support.symfonium.app/t/casting-albums-to-upnp-plays-songs-twice/3263/11 "2025-06-16T14:32:15Z")
I’m getting the same (or at least very similar) issue… When casting to upnp device (a cambridge audio player), each track is played twice. Interestingly each track is only scrobbled once. I’m getting an error trying to upload logs (they are only 3.5mb), so is there another way i can upload logs ---
**Author:** ![Tolriq](http://support.symfonium.app/user_avatar/support.symfonium.app/tolriq/32/726_2.png) [@Tolriq](http://support.symfonium.app/u/Tolriq)\ **Post date:** [June 16, 2025, 3:00pm UTC](http://support.symfonium.app/t/casting-albums-to-upnp-plays-songs-twice/3263/12 "2025-06-16T15:00:14Z")
Open your own issue it’s unrelated. The wizard explains how to upload logs, but you probably just need to disable Gapless on the renderer settings in symfonium cast bottom sheet.