streamTitleChanged showing previous song

General
1

I am playing some local songs with Mopidy and noticed an odd behaviour of streamTitleChanged. Suppose I play 3 songs A, B and C.
When playback of song B comes to an end, then event:streamTitleChanged is fired, but with object {title: "title_A"}. At about the same time we get trackPlaybackEnded for song B (correct). Then follows playbackStateChanged and trackPlaybackStarted for C, etc. But the argument for streamTitleChanged is very odd and definitely not usable to update my client. What could be the reason?

Note that in this use case (playing local songs), the problem can be easily worked around by using trackPlaybackStarted. But this is not the case for a live stream (e.g. radio), where the stream does not end, just the songs. I do receive streamTitleChanged in that case, but don’t know how exact they are, if I can rely on them: which song are they indicating?

Thanks,

2

And what version of Mopidy are you using? The latest?

3

In fact, you can see this issue is documented in the PR from the changelog.

This still isn’t very good as we are still emitting the bogus stream_title_changed event for the previous track’s title. That is because we keep any tags we get after about_to_finish fires in pending_tags , and then emit them when the track change completes ( on_stream_start fires), even if they were old tags for the previous track.

And there’s a detailed bug for it at Erroneous stream_title_changed event for previous track on track change · Issue #1889 · mopidy/mopidy · GitHub

If I remember correctly, the streamTitleChanged event in the “live stream” case is OK as an experiment would probably show. So the workaround to clear out any stream title info on receiving a trackPlaybackStarted (or trackPlaybackEnded) might be enough?

4

Thanks. I am using Mopidy 3.0.2-1, seems to be the latest.

Note that the event is coming delayed “2 times”, i.e. for track A after the next track after A has been played. To be useful it should fire for track C at that time, so one level back would still not be enough.

I’ll try to check it for a radio stream, hopefully it can be used.

5

I don’t undestand what you are proposing there in regards to “one level back” - it doesn’t always fire in error, it entirely depends on the particular track’s tags and the time at which gstreamer emits them in relation to the next track starting.