Playlist History 1.0.0 - Added WMP's playlist history functionality to MusicBee

[SonicRings]

The original author seems to be on Bluesky now.
alexrosegames.bsky.social

Also have you read the txt file that comes in the zip with the dll? It mentions some options you might need to change.

Awesome, thanks for the link. He doesn't have chat enabled there but I tagged him in a post.

I also checked that text file but it didn't seem to help me in this case.

Another odd behaviour I found is that while the plugin is disabled, the SongHistory.txt continues to get updated. All the while MusicBee doesn't use any additional CPU, so no 8-12% CPU issue. Truly odd behaviour, but for me this is great, as it's the reason I've been using this plugin (I quickly stopped using those back/forward buttons, but it still would be nice to be able to use them).

I initially thought the issue would be due to my max lines being set to 10000000000 lines, but considering the text file continues to be appended to with no issue while the plugin's disabled while being on line 123252, that doesn't seem to be the case. Especially considering it still has the CPU issue when the text file only has 1 line.

EDIT 2025-04-29: He replied on Bluesky with:

it might be that a newer version of musicbee caused it to be called more regularly than it's supposed to be called. I'm not even sure I have the source code anymore

https://bsky.app/profile/sonicrings4.bsky.social/post/3lnuylqu3a22r

[Migue]

I have found that this plugin causes MusicBee to get stuck using 8-12% CPU usage when the queue is a certain size and a song is added to the queue. This happens on 3.5 and 3.6. I would love to continue using this plugin if it can be updated by anyone to fix this strange issue. I'd reach out to the OP on Twitter, but they've deleted their account. Hopefully Migue sees this and is able and willing to make the necessary fixes, but I'm documenting them here for anyone who has this issue in the future.

Here are some more details I can offer:

- No matter the queue size, MusicBee starts and play just fine as long as no song is added to the queue
- When the queue size is large enough (mine is 100k but I haven't tested at which point this occurs), adding a song to anywhere in the queue causes MusicBee to get stuck at 8-12% CPU usage, which tanks single core performance and causes my 120fps games to lose up to 50fps at times
- Restarting MusicBee fixes this issue until the next time a song is added to the queue
- This issue is absent when the plugin is disabled

I would have updated my forum thread with this information so as to provide closure, but sadly it was locked before I had a chance to report back as I said I would. Here is the thread if you would like more context: https://getmusicbee.com/forum/index.php?topic=42903.msg235233

My collection is only about 4k songs so I had to add entire collection to queue multiple times to be able to trigger the issue. However, at 30k songs on the queue, the CPU usage spiked to 8-10% for about 16 seconds when adding a song to the queue (on a 9800X3D) before it went back to 0.2%.

I'll try to see if there's anything I can do anything about it.

[BoringName]

The bottleneck will be accessing the text file. Either appending records or deleting after it hits the MaxSize.

[Migue]

Another odd behaviour I found is that while the plugin is disabled, the SongHistory.txt continues to get updated. All the while MusicBee doesn't use any additional CPU, so no 8-12% CPU issue. Truly odd behaviour, but for me this is great, as it's the reason I've been using this plugin (I quickly stopped using those back/forward buttons, but it still would be nice to be able to use them).

I initially thought the issue would be due to my max lines being set to 10000000000 lines, but considering the text file continues to be appended to with no issue while the plugin's disabled while being on line 123252, that doesn't seem to be the case. Especially considering it still has the CPU issue when the text file only has 1 line.

I can't reproduce the SongHistory.txt (songhistory? it's supposed to be PlaylistHistory.History.txt) being updated while plugin is disabled. Do you have duplicate plugins installed? Maybe one in AppData and one in Program Files?

And with a simple modification, changing string concatenation to use StringBuilder instead, saving history for 140k files went from 15 minutes to 2 seconds.

Here's the link to the new version: Modified Playlist History Plugin

[SonicRings]

Another odd behaviour I found is that while the plugin is disabled, the SongHistory.txt continues to get updated. All the while MusicBee doesn't use any additional CPU, so no 8-12% CPU issue. Truly odd behaviour, but for me this is great, as it's the reason I've been using this plugin (I quickly stopped using those back/forward buttons, but it still would be nice to be able to use them).

I initially thought the issue would be due to my max lines being set to 10000000000 lines, but considering the text file continues to be appended to with no issue while the plugin's disabled while being on line 123252, that doesn't seem to be the case. Especially considering it still has the CPU issue when the text file only has 1 line.

I can't reproduce the SongHistory.txt (songhistory? it's supposed to be PlaylistHistory.History.txt) being updated while plugin is disabled. Do you have duplicate plugins installed? Maybe one in AppData and one in Program Files?

And with a simple modification, changing string concatenation to use StringBuilder instead, saving history for 140k files went from 15 minutes to 2 seconds.

Here's the link to the new version: Modified Playlist History Plugin

Thus far I had been using the plugin from the OP, not yours. I figured the only thing you changed was the working directories so hadn't tried yours yet. I'm giving this version a shot now, and it looks like it solves the CPU issue completely! Thank you very much for the fix.

However, I don't know if this is an issue with your plugin or the old one as I haven't used the back/forward feature in a while, but when I do so with your plugin, it goes to the FIRST instance of the last song I was on, vs. the actual position in the queue it was in (there are 3 instances of the song I tested).

I tried testing the original version of the plugin, but that kept erroring and clearing my queue (thank god I had made a backup before trying this). I had only put your version in a completely new copy of my portable MusicBee install so as to not mess with my original install, so that rules out your version conflicting with the original, at least.

So, I'm not sure if this is something you can fix with the specific queue position, but if so, it would be amazing! I think you could just have it remember the position in the queue, as I believe you're essentially restoring the entire queue when using this plugin, so it's bound to land on the correct track still.

Also, earlier I mentioned that SongHistory.txt was seemingly still functional with this plugin disabled. I had forgotten that that's a completely separate plugin that I simply set to save the txt file in the PlaylistHistory plugin's folder, which is why I thought it was part of this plugin when in reality it is not!

[Migue]

However, I don't know if this is an issue with your plugin or the old one as I haven't used the back/forward feature in a while, but when I do so with your plugin, it goes to the FIRST instance of the last song I was on, vs. the actual position in the queue it was in (there are 3 instances of the song I tested).

I tried testing the original version of the plugin, but that kept erroring and clearing my queue (thank god I had made a backup before trying this). I had only put your version in a completely new copy of my portable MusicBee install so as to not mess with my original install, so that rules out your version conflicting with the original, at least.

So, I'm not sure if this is something you can fix with the specific queue position, but if so, it would be amazing! I think you could just have it remember the position in the queue, as I believe you're essentially restoring the entire queue when using this plugin, so it's bound to land on the correct track still.

Unfortunately, this is a limitation on MusicBee's API. The method to play a song on the now playing queue takes a file as a parameter and not an index, so it will just pick the first match.

[BoringName]

I haven't looked into how the addon works. How did you get the source code?

But from comments in here and the documentation it seems to store the playlist and the song URL it was currently on.

Could it be modified to record the current song index instead?

Code

NowPlayingList_GetCurrentIndex

Then use that index to get the song url to play it.

Code

NowPlaying_GetFileUrl;

[Migue]

I haven't looked into how the addon works. How did you get the source code?

But from comments in here and the documentation it seems to store the playlist and the song URL it was currently on.

Could it be modified to record the current song index instead?

Code

NowPlayingList_GetCurrentIndex

Then use that index to get the song url to play it.

Code

NowPlaying_GetFileUrl;

I got the source code by disassembling the dll with ildasm, I think. It's been awhile.

Your suggestion won't work, because passing a file url to

Code

NowPlayingList_PlayNow (string sourceFileUrl)

is what the code already does and that just goes to play the first instance of the file url present on the queue.

[BoringName]

is what the code already does and that just goes to play the first instance of the file url present on the queue.

Yeah, after looking at the gif in the OP, I think SonicRings might be confusing what this thing is meant to do.

If I'm deciphering it properly, it's supposed to keep track of what song you were on in a playlist so you can switch between playlist without losing your position in each playlist. But SonicRings is expecting it to keep track of the "now playing list" as well which isn't it's function.

[SonicRings]

is what the code already does and that just goes to play the first instance of the file url present on the queue.

Yeah, after looking at the gif in the OP, I think SonicRings might be confusing what this thing is meant to do.

If I'm deciphering it properly, it's supposed to keep track of what song you were on in a playlist so you can switch between playlist without losing your position in each playlist. But SonicRings is expecting it to keep track of the "now playing list" as well which isn't it's function.

How do you play a song in a playlist without adding it to your "Now Playing List"?

[BoringName]

How do you play a song in a playlist without adding it to your "Now Playing List"?

Yeah ok, I see the issue now. It is using the now playing list to keep track. eg) if you have 2 playlists (A and B) with 4 and 5 tracks respectively. Where track 1 of both playlists is the same track. You queue up both playlists which adds all 9 tracks to the now playing list. If you play track 1 from playlist B for 10 seconds (this is track 5 in the now playing list) then play track 4 in playlist A for 10 seconds then hit the plugins back button, it should jump to track 5 at the 10 second position in the now playing list. But it will actually jump to track 1 because that is the first instance of that track URL.

I think this is a limitation of the plugin and the Musicbee Api. As far as I'm aware there is no way to set the current position in the now playing list.

You can get a URL by querying the index. eg) NowPlayingList_GetListFileUrl(index) then play that URL. Which will jump to the first instance of that track in the now playing list. Or add it to the now playing list if it doesn't already exist.

But you can't tell Musicbee to jump to track 3 in the now playing list and play it. As Migue already mentioned, NowPlayingList_PlayNow() takes a URL string, not an index int.

TL;DR Queuing up multiple playlists that contain the same track/s will break the plugin functionality and there is no way to fix that. Even if you kept a running copy of the now playing list with the URL at each index, you wouldn't be able to set Musicbee to play the second instance of a URL in the list. As far as I'm aware.....