rmpcd doesn't fire song_change when in repeat and single mode: expected behavior, or bug?

[rmunn]

While testing my "increment playCount" plugin, I discovered that if MPD is in "repeat" and "single" mode (so that it loops a single song over and over), then rmpcd won't fire the song_change event repeatedly (it fires only once, when the song is first played, but it does not fire again with old = "This Is The Song That Never Ends.mp3" and new = "This Is The Song That Never Ends.mp3"). So my "increment playCount" plugin will only increment the song's play count once, no matter how many times you loop it.

That might be desired behavior in some cases (and indeed, even if rmpcd did fire the song_change event multiple times, the way I double-check song_id in my plugin's logic means that the plugin would only increment playCount once even if the song was looped a dozen times). And in fact, that might be because that's just what MPD does and there's nothing a client can do about it.

I just wanted to double-check, before opening an issue, whether song_change is expected to fire every time a song loops in "repeat+single" mode, or only just once no matter how many times it loops. It's a weird edge case, and there are pros and cons either way.

[mierak]

The logic for this is here

rmpc/rmpcd/src/event_loop.rs

Lines 73 to 96 in 5cb3372

	AppEvent::StatusUpdate(new_status) => {
	let song = client.run(|c| c.get_current_song()).await?;
	let mut album_art_changed = false;
	let mut album_art = None;
	let ro_mpd_state = ctx.read().await;
	let ro_status = &ro_mpd_state.status;
	let ro_song = &ro_mpd_state.current_song;
	if ro_song != &song {
	album_art = if let Some(s) = &song {
	let uri = s.file.clone();
	album_art_changed = true;
	client
	.run(move |c| c.find_album_art(&uri, AlbumArtOrder::EmbeddedFirst))
	.await?
	} else {
	None
	};
	tx.send_safe(PluginsEvent::SongChange {
	old: ro_song.as_ref().map(Song::from),
	new: song.as_ref().map(Song::from),
	});
	}

I wouldnt mind having an option to cause it to trigger with repeats, but the logic would have to be more advanced than a simple old != new -> song changed.

MPD emits a single player event for "the player has been started, stopped or seeked or tags of the currently playing song have changed (e.g. received from stream)" so we have to do this client side. It would probably have to be something like old != new || old.elapsed == old.duration to fire when the song is the same but the whole song duration has been played, not sure if I am missing any edge cases with this though. Or do you have a better idea?

[rmunn]

It's probably fine as-is, I'll document in my playCount plugin that it will only increment once no matter how often a song loops in repeat+single mode. That's the logic I would want anyway: if I am going to loop a song, it's probably going to be atmospheric background music for a tabletop roleplaying game or something like that. And in that case, my personal preference would be to increment playCount by only 1, even if the song is an hour long and the session lasted for four hours.

And since MPD doesn't make it easy to resolve this edge case, it's not worth adding extra complexity to solve it, IMHO. If there's widespread opinion from other users that "No, we would really like our playCount to increment repeatedly when a song is looped" then it might be worth revisiting that. But for my use case, I don't actually need this solved.

[rmunn]

I won't open an issue, then, since IMHO it's fine as it is. So I've marked this question as answered so that it's clear there's no more work needing to be done.

[rmunn]

The logic you described (detecting whether elapsed == duration) is something I could implement in my playCount plugin, actually. If I wanted to, I've realized that I could look at the remaining duration of a song at the moment I'm incrementing its playCount, and then set a timeout for (time remaining + 2 seconds) or something. That timeout would check whether MPD still reports the same song_id as playing, and if it is, then set up to increment playCount again.

Since I've decided I like the current behavior where playCount only increments once no matter how many times the song is looped, I don't think I'll put in the work. But it could be done, without needing any code changes to rmpcd.

[rmunn]

I should add that if rmpcd does fire song_change with old and new being the same song when it's on repeat+single, then that fact should probably be mentioned in the plugin documentation so that plugin authors will know to check for that scenario (if it matters to them).

As for why in the world you would ever want to put the same song on repeat a dozen times... well, I have young kids. My wife and I ended up having to make a rule that they were NOT allowed to queue up the same song a dozen times on Spotify. If they want to listen to it a dozen times, they had to put one of their parents' chosen songs in between. So the Spotify queue at our house often looks like this:

• Kids' favorite song
• Parents' chosen song 1
• Kids' favorite song
• Parents' chosen song 2
• Kids' favorite song
• Parents' chosen song 3
• Kids' favorite song
• Parents' chosen song 4
• Kids' favorite song
• Parents' chosen song 5
• Kids' favorite song

... You get the idea.

[mierak]

As for why in the world you would ever want to put the same song on repeat a dozen times... well, I have young kids.

No, I see it as completely valid, I repeat songs myself too and I haven't been a kid for decades 😄 .