Some tracks (opus files extracted from youtube) not marked as played

Issue description:

I am using the subsonic media provider with the upmpdcli upnp renderer, and it looks like listens for some tracks in my library (as far as I can tell opus files extracted from youtube) don’t get marked as played either in symfonium or in my navidrome instance. I start playing the track using the renderer and when it finishes it doesn’t get marked as played in the symfonium details page. It works fine if I play it locally through my phone’s speakers. I can provide a sample file if needed, but it looks like during play it doesn’t provide a completion bar/percent. Is it possible this is causing the problem?

Logs:

Upload description: aereaux

Additional information:

 
I can share one of the files that shows the problem if needed.
 

Reproduction steps:

 
Use upmpdcli media renderer. Start affected track. When completed see that it’s not marked as played in track details.
 

Media provider:

Subsonic

Screenshots:

     

If there’s no bar then the renderer does not return a duration and so there’s no way to know if the media is fully played or not.

@medoc It’s probably mpd that fails to extract a duration from the files. But since Symfonium does send a duration in the metadata do you think you can fallback to returning that in those cases ?

<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="37f0be7b-6456-4e00-9e11-db179db576b9" parentID="0"><upnp:album>Hadestown: Original Broadway Cast Recording</upnp:album><upnp:class>object.item.audioItem.musicTrack</upnp:class><upnp:genre>musical</upnp:genre><upnp:artist>Reeve Carney, André De Shields &amp; [theatre]</upnp:artist><res duration="00:03:12" protocolInfo="http-get:*:audio/ogg:DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000" size="3213403">https://REDACTED:443/music/rest/stream.view?id=bfadfec6ea42876db0497474449e5cb4&amp;u=REDACTED&amp;t=REDACTED&amp;s=REDACTED&amp;v=1.13.0&amp;c=Symfonium&amp;f=json</res><upnp:originalTrackNumber>5</upnp:originalTrackNumber><upnp:albumArtURI>http://192.168.0.175:39253/b8683fff6a470034eeab94e59768571d/%2Fstorage%2Femulated%2F0%2FAndroid%2Fdata%2Fapp.symfonik.music.player%2Fcache%2Fimages%2F3%2F3F103CEF518CA4838DDA807D9135B223.jpg</upnp:albumArtURI><dc:title>Epic I</dc:title></item></DIDL-Lite>

Thanks for the quick response! Would it also be worth it for me to ask in the MPD repo why it might not be able to extract a duration?

Don’t know how upnpmdpcli dialog with MPD so better to see with Medoc first.

Hello,
Don’t ask on the mpd forum for now, I should have a look at this first. Unfortunately I can’t do it this week. Please point me to or send a sample track: [email protected], and I’ll test this next week. jf (upmpdcli)
Edit, PS: being provided by the subsonic plugin may be a part of the problem, I’ll notify the plugin developper.

Hello, this is the developer of the subsonic plugin for upmpdcli.
From what I read, I don’t think the subsonic plugin for upmpdcli is involved. When using Navidrome via Symphonium and play to upmpdcli+mpd, we are only using the renderer part of upmpdcli.
Assuming this, the problem might be with the fact that just streaming a file to a renderer is not supposed to invoke the subsonic api “scrobble” method.
Instead, when you play to the local player, it’s Symphonium itself that does the operation AFAIK.
See this issue for a reference.
Also I don’t think the problem is with the length. I have observed that generally Symphonium provides the correct length to the upnp renderer.
If all of this is correct, this problem can be solved by simply deploying a mpd scrobbler for subsonic. See here

In this case this is the length/duration.

The renderer is the source of truth, so even if Symfonium have the duration, it will use the one returned by the renderer and in this case it does not return one.

So Symfonium can’t know the media is played and don’t call the scrobble part, something that works properly if the renderer properly returns a duration for the playing media.

Hello, interesting, I was assuming that scrobbling would not work when playing to a UPnP renderer.
Are there any other software renderers that actually return the correct duration for the playing media? Maybe gmrenderer-resurrect?
Thank you.

Hello @aereaux, can you please share the file? Thank you
Does the situation happen with other files (or file types)?

I just tried to play to mpd+upmpdcli, and the scrobbling worked as expected with a couple of my files.
The mpd-subsonic-scrobbler remains necessary when playing from the subsonic plugin for upmpdcli, but it’s not at all required when using Symphonium.

So the issue might be specific with opus files. There has been a recent (and solved) issue here, I will try and see if that one and this are somehow related.

UPDATE!

Hello again, I just tested an opus file, and yes, the two issues are actually related.
With mpd default settings, Symphonium does not receive information about the song duration for opus files.
This is an issue with the opus decoder when playing using the curl plugin, so, when streaming. It does not happen with opus local files.

It can be solved by adding this section to the mpd.conf file:

decoder {
    plugin "opus"
    enabled "no"
}

MPD must be restarted.
With this setting, Symphonium will receive the song duration, and scrobbling works.
@aereaux, please let me know if this solves the issue.

Here’s one of the files it fails with: https://jmad.org/tmp/37%20Wait%20for%20Me%20(reprise).opus . And it is indeed just some opus files.

This does actually seem to solve the issue. Is this just a hack or is it a good long-term solution?

Hello, glad to hear that this solves the issue.
It’s not a hack, we are simply disabling a plugin, I believe ffmpeg replaces its functionality (I might be corrected on this). If I find something about the opus decoder in the upcoming release notes of mpd, I will test this situation again.

1 Like

Unfortunately this workaround has started failing with mpd version 0.24. Now I get an http 416 error with the ffmpeg opus decoder that it falls back to when streaming from navidrome. I’m currently working on filing a bug report with MPD, but any other suggestions for what I can try?