Skip to content
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

mpdstats: mpd events are processed twice #773

Closed
rafi opened this issue May 16, 2014 · 2 comments
Closed

mpdstats: mpd events are processed twice #773

rafi opened this issue May 16, 2014 · 2 comments
Labels
bug bugs that are confirmed and actionable

Comments

@rafi
Copy link
Collaborator

rafi commented May 16, 2014

Running beet -v mpdstats shows that mpd events are processed twice, for example:

mpdstats: playing /mnt/media/music/10 Her Majesty.mp3
Sending event: database_change
mpdstats: updated: last_played = 1400247006 [/mnt/media/music/10 Her Majesty.mp3]
mpdstats: playing /mnt/media/music/10 Her Majesty.mp3
Sending event: database_change
mpdstats: updated: last_played = 1400247006 [/mnt/media/music/10 Her Majesty.mp3]
Sending event: database_change
@sampsyo sampsyo added the bug label May 16, 2014
@brunal
Copy link
Collaborator

brunal commented Jan 8, 2015

This does not happen for all events, and depends on the sequence of commands executed. Example following. Music redacted for terseness (it's actually some awesome Grateful Dead).

# standard stuff
user configuration: /home/bru/.config/beets/config.yaml
data directory: /home/bru/.config/beets
Sending event: pluginload
library database: /home/bru/.beetsmusic.blb
library directory: /home/bru/Musique
Sending event: library_opened
mpdstats: connecting to localhost:6600
mpdstats: playing /home/bru/Musique/A.mp3
Sending event: database_change
mpdstats: updated: last_played = 1420711398 [/home/bru/Musique/A.mp3

# the song is now naturally over
Sending event: database_change
mpdstats: updated: play_count = 1 [/home/bru/Musique/A.mp3]
mpdstats: played /home/bru/Musique/A.mp3
Sending event: database_change
mpdstats: updated: rating = 0.6875 [/home/bru/Musique/A.mp3]
mpdstats: playing /home/bru/Musique/B.mp3
Sending event: database_change
mpdstats: updated: last_played = 1420711519 [/home/bru/Musique/B.mp3]
mpdstats: playing /home/bru/Musique/B.mp3
Sending event: database_change
mpdstats: updated: last_played = 1420711522 [/home/bru/Musique/B.mp3]
# it is happening twice indeed. Now I'm skipping to the next song

Sending event: database_change
mpdstats: updated: skip_count = 1 [/home/bru/Musique/B.mmp3]
mpdstats: skipped /home/bru/Musique/B.mp3
Sending event: database_change
mpdstats: updated: rating = 0.3125 [/home/bru/Musique/B.mp3]
mpdstats: playing /home/bru/Musique/C.mp3
Sending event: database_change
mpdstats: updated: last_played = 1420711578 [/home/bru/Musique/C.mp3]
# happened only once! Now I'm skipping back

Sending event: database_change
mpdstats: updated: skip_count = 1 [/home/bru/Musique/C.mp3]
mpdstats: skipped /home/bru/Musique/C.mp3
Sending event: database_change
mpdstats: updated: rating = 0.3125 [/home/bru/Musique/C.mp3]
mpdstats: playing /home/bru/Musique/B.mp3
Sending event: database_change
mpdstats: updated: last_played = 1420711592 [/home/bru/C.mp3]
# happened only once!
# and again when I let it play naturally

Therefore 'playing' (i.e. on_play(=) is incorrectly triggered a second time on natural music advancement...

@brunal
Copy link
Collaborator

brunal commented Jan 8, 2015

mpd responds to the command idle only once on user-requested song change, and twice on "natural" song change. See specification of the command: http://www.musicpd.org/doc/protocol/command_reference.html.
Patch incoming.

brunal added a commit to brunal/beets that referenced this issue Jan 8, 2015
mpd responds twice to an 'idle' command upon a 'natural' song change
(i.e. not a skip). Checking the reason for mpd response avoids
registering twice the song change.

Fix issue beetbox#773
@sampsyo sampsyo closed this as completed in e9834ef Jan 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug bugs that are confirmed and actionable
Projects
None yet
Development

No branches or pull requests

3 participants