-
Notifications
You must be signed in to change notification settings - Fork 687
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mopidy randomly brings over the previous track title to the next track #1871
Comments
This looks related to mopidy/mopidy-mpd#23. |
No problem! Both reports came within hours, and we still don't know what component the root cause is in. |
I'd have said it was maybe something to do with #1751 if it wasn't for the statement saying this issue wasn't present in Mopidy 2.x. |
Got the same issue I believe, but I've had this issue for months. Also Arch here, everything updated. Mopidy retains the previous track title as the current. I.e track finishes - ncmpcpp and polybar extension shows previous track name (simply as "Eminem - In Too Deep"). While mpc shows "Godzilla: Eminem - In Too Deep", where Godzilla is the current song and In Too Deep was the previous. That's kinda freaky, one is a bug but why does mpc show both? |
This is a combination of things brought to light by #1751 and so it's also present in Mopidy v2.3.0. The first two tracks in my playlist are (1) 'Set Guitars To Kill' followed by (2) 'A Little Bit Of Solidarity Goes A Long Way'. The below log shows that after the track change from (1) to (2), we get a tag changed event but but we end up sending
This is because our call to It seems to be a race condition between |
Having a race condition here seems wrong, it should be one synchronous action when switching tracks - whether manual or not. But I admit I don't know enough of how mopidy works, so maybe there's some reason as to why. |
It's more complicated than that, but yes, if I wasn't clear, this is a bug. |
I didn't mean to come off rude, it was a late night. I think I just reacted to sleep(1) as a solution (no pun intended). |
No worries. I only mentioned EDIT: It's not exactly a race condition. |
@adamcik, why do we care about the tag updates we got between receiving |
Fixes mopidy#1871 PR mopidy#1871 introduced a regression where, following a normal gapless track change, the stream_title was incorrectly set to the previous track's title.
Fixes mopidy#1871 PR mopidy#1871 introduced a regression where, following a normal gapless track change, the stream_title was incorrectly set to the previous track's title.
Fixes mopidy#1871 PR mopidy#1871 introduced a regression where, following a normal gapless track change, the stream_title was incorrectly set to the previous track's title.
Fixes mopidy#1871 PR #7151 introduced a regression where, following a normal gapless track change, the stream_title was incorrectly set to the previous track's title.
Fixes mopidy#1871 PR mopidy#1751 introduced a regression where, following a normal gapless track change, the stream_title was incorrectly set to the previous track's title.
Better late than never, re tag updates and all these events it gets complicated since it's all async. And it's been ages since I've been looking at this stuff in detail. But here goes with a horribly over simplified pipeline diagram:
So think we can have cases where there are meaningful tags in between |
Hi,
After letting Mopidy finish a track and going to the next one, the track title is not properly updated, resulting in the next track having the same title as the previous one. This issue slowly seems to grow worse, and the entire playlist becomes skewed.
For the record; the audio plays fine, the artist is updated fine, the track number is updated fine, and so is the track length and progress.
Steps to reproduce:
I'm running Arch Linux, with the following versions of Mopidy and its extensions:
These are all updated to the latest known version on Arch and the AUR.
I've been dealing with this since updating to Mopidy 3 somewhere last year, whereas 2 never had this behavior.
This issue seems similar to #1528 #1528 , however that one talks about Mopidy 2.
The tracks shown below are played from mopidy-local.
In ncmpcpp:
Incorrect track listing https://camo.githubusercontent.com/fa91261107d7af341374ef03a1ab2a774e813e9f/68747470733a2f2f692e696d6775722e636f6d2f5547674830477a2e706e67
And in polybar's MPD extension:
Polybar MPD https://camo.githubusercontent.com/5b6207e174cd0cce829d2164aba91868c451d50b/68747470733a2f2f692e696d6775722e636f6d2f374d5a69367a4a2e706e67
This is the actual track listing:
Correct track listing https://camo.githubusercontent.com/c99c327c9505f563f9f96a92b2b54df2a4f02a28/68747470733a2f2f692e696d6775722e636f6d2f384d53666665422e706e67
With a different album, I tried to capture the logs with mopidy -v during the time it happened.
Log https://camo.githubusercontent.com/76bb6011e2138c5ca800ac2b7d18618e46a8ca75/68747470733a2f2f692e696d6775722e636f6d2f6d5339375a49702e706e67
DEBUG 2020-01-15 14:07:06,594 [79919:MainThread] mopidy.audio.actor
Audio event: tags_changed(tags=['minimum-bitrate', 'bitrate'])
DEBUG 2020-01-15 14:07:06,594 [79919:MainThread] mopidy.listener
Sending tags_changed to AudioListener: {'tags': ['minimum-bitrate', 'bitrate']}
DEBUG 2020-01-15 14:07:06,644 [79919:MpdSession-11] mopidy_mpd.session
Request from [::ffff:127.0.0.1]:34768: noidle
DEBUG 2020-01-15 14:07:06,644 [79919:MpdSession-11] mopidy_mpd.session
Response to [::ffff:127.0.0.1]:34768: OK
DEBUG 2020-01-15 14:07:06,644 [79919:MpdSession-11] mopidy_mpd.session
Request from [::ffff:127.0.0.1]:34768: status
DEBUG 2020-01-15 14:07:06,647 [79919:MpdSession-11] mopidy_mpd.session
Response to [::ffff:127.0.0.1]:34768:
volume: 100
repeat: 0
random: 0
single: 0
consume: 0
playlist: 5
playlistlength: 8
xfade: 0
state: play
song: 2
songid: 12
nextsong: 3
nextsongid: 13
time: 1:270
elapsed: 1.412
bitrate: 0
OK
DEBUG 2020-01-15 14:07:06,648 [79919:MpdSession-11] mopidy_mpd.session
Request from [::ffff:127.0.0.1]:34768: idle
DEBUG 2020-01-15 14:07:06,656 [79919:MainThread] mopidy.audio.gst
Got TAG bus message: tags={'artist': ['Ben Lukas Boysen'], 'title': ['Sleepers Beat Theme'], 'track-number': [3], 'track-count': [8], 'album': ['Spells'], 'datetime': ['2016'], 'album-artist': ['Ben Lukas Boysen'], 'organization': ['Erased Tapes Records'], 'genre': ['Ambient/Modern Classical'], 'isrc': ['ERATP085'], 'image':
There was a lot of noise in the debug output (from images) and it quickly went beyond my terminal's buffer size.
If any additional information is needed, please tell me and I'll do what I can.
Thank you.
The text was updated successfully, but these errors were encountered: