1
MusicBee API / Re: [3.6.9202] Library_GetFileTag not updating on bulk edits of track ratings
« on: April 17, 2025, 09:16:23 PM »
I'm using the tag editor to save them in bulk, and using the keyboard shortcut for Save.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
MusicBee API / [3.6.9202] Library_GetFileTag not updating on bulk edits of track ratings
« on: April 13, 2025, 11:18:27 PM »
As part of my plugin, I process tags and ratings before submitting them to MusicBrainz. Library_GetFileTags seems to be able to get updated tags perfectly fine for text/string based tags, but for ratings, I've ran into a bug while bulk-editing.
To reproduce
1. Rate an album's tracks in bulk using MusicBee's built-in Tag Editor.
2. Edit only some of the ratings.
3. Execute Library_GetFileTags on the path/s of the tracks where the rating was changed in step 2.
Expected result
Library_GetFileTag should grab the newly edited ratings.
Actual result
Library_GetFileTag grabs the previous rating - e.g. if I edit an entire album to have their tracks rated 3 out of 5, then decide to rate a couple tracks 4.5, the affected tracks are stated as being 3/5 and not 4.5/5.
I presumed this was because MusicBee doesn't commit the edit until there's a situation where the file isn't being locked by it (e.g. moving to a new track, stopping playback, quitting MusicBee) - this was what I noticed when checking the updated tags of a song that was currently playing on MusicBee in the Picard tag editor. However ensuring it wasn't locked did not help. This also seems to be persistent - restarting does nothing to fix the issue. The only way to get those new ratings seen by that function is to remove the files and re-add them to the library. Where the file is doesn't matter either - initially I thought it was due to my library being saved on an SMB share, so I tried checking a locally stored copy. That did not help either. Bulk editing them again also doesn't let the API see the updated ratings. I've also tried to use Library_CommitTagsToFile to ensure the tags are committed, but this also didn't fix the issue.
This doesn't happen if the user edits the ratings individually upon being added to the library, and it also does not happen on the other tags, at least not ones that are exposed as strings to edit with textboxes - the plugin checks string based tags like genres, moods and even custom tags, but doing a similar bulk edit of the tags, changing some of them and them executing that function on them seems to use the updated tags on those perfectly fine.
I was thinking on posting this on the Bugs sub-forum but given it's an API issue, I've posted it here (feel free to move if required)
To reproduce
1. Rate an album's tracks in bulk using MusicBee's built-in Tag Editor.
2. Edit only some of the ratings.
3. Execute Library_GetFileTags on the path/s of the tracks where the rating was changed in step 2.
Expected result
Library_GetFileTag should grab the newly edited ratings.
Actual result
Library_GetFileTag grabs the previous rating - e.g. if I edit an entire album to have their tracks rated 3 out of 5, then decide to rate a couple tracks 4.5, the affected tracks are stated as being 3/5 and not 4.5/5.
I presumed this was because MusicBee doesn't commit the edit until there's a situation where the file isn't being locked by it (e.g. moving to a new track, stopping playback, quitting MusicBee) - this was what I noticed when checking the updated tags of a song that was currently playing on MusicBee in the Picard tag editor. However ensuring it wasn't locked did not help. This also seems to be persistent - restarting does nothing to fix the issue. The only way to get those new ratings seen by that function is to remove the files and re-add them to the library. Where the file is doesn't matter either - initially I thought it was due to my library being saved on an SMB share, so I tried checking a locally stored copy. That did not help either. Bulk editing them again also doesn't let the API see the updated ratings. I've also tried to use Library_CommitTagsToFile to ensure the tags are committed, but this also didn't fix the issue.
This doesn't happen if the user edits the ratings individually upon being added to the library, and it also does not happen on the other tags, at least not ones that are exposed as strings to edit with textboxes - the plugin checks string based tags like genres, moods and even custom tags, but doing a similar bulk edit of the tags, changing some of them and them executing that function on them seems to use the updated tags on those perfectly fine.
I was thinking on posting this on the Bugs sub-forum but given it's an API issue, I've posted it here (feel free to move if required)
3
MusicBee API / Re: [Question] Retrieving custom tag names
« on: April 10, 2025, 11:49:22 AM »
Welp, definitely overlooked that. Thank you!
4
MusicBee API / [Solved] Retrieving custom tag names
« on: April 09, 2025, 10:05:09 PM »
I'm currently developing a plugin for MusicBee to send data to MusicBrainz, and I have a configuration UI that needs to be able to read the custom tag names so the user is able to select those tags to be synced (e.g. if someone has a separate "album genre" tag and uses the standard genre for track genres), however I don't see anything in the current API to allow this - only their values. Should this be requested to be added, or have I overlooked something?
5
Bug Reports / Auto-calculated album ratings not showing up if album rating tag is not present
« on: April 09, 2025, 02:37:21 PM »
Don't know what else I should say here. If auto-calculation of album ratings is enabled and the tag isn't already present, MusicBee doesn't show it unless you go into the tag editor. I think I posted this before but in the wrong forum, I presume this is a bug.
MusicBee version is 3.6.9202, running on Windows 11.
MusicBee version is 3.6.9202, running on Windows 11.
6
Tips and Tricks / Re: MusicBee now works under wine
« on: October 10, 2024, 02:00:33 PM »
Just thought I should let the thread know, I'm now the maintainer for MusicBee's entry on the WineHQ AppDB. If you do run into bugs that haven't been reported yet, please report them on the Bugzilla, especially if you want MusicBee to be feasibly usable on Linux.
7
Tips and Tricks / Re: MusicBee now works under wine
« on: February 29, 2024, 02:40:44 PM »
Anyone know how to fix the performance issues on MusicBee? Mine gets awfully sluggish when scrolling...
8
MusicBee Wishlist / Re: Picard MusicBrainz standard tags
« on: October 03, 2023, 03:07:52 PM »
+1
Might be a little biased though, I use ScrobblerBrainz which has MBID submission with an external library.
Might be a little biased though, I use ScrobblerBrainz which has MBID submission with an external library.
9
Questions / Re: Automatic album ratings sometimes show, sometimes don't
« on: July 11, 2023, 01:20:41 PM »
Bump.
10
Questions / Automatic album ratings sometimes show, sometimes don't
« on: July 03, 2023, 11:59:49 AM »
Is there a pattern to the automatic album ratings showing sometimes or not? I have two albums - one has all of its tracks rated while the other omits one because I don't really rate intro tracks. The latter has the album ratings shown, while the other one doesn't. MusicBee tends to be inconsistent on this so I thought I'd ask.
FWIW, I have "exclude zero rated tracks" enabled.
FWIW, I have "exclude zero rated tracks" enabled.
11
Tips and Tricks / Re: Tag Hierarchy Files
« on: June 21, 2023, 12:49:09 AM »I aim to keep it as updated as possible, especially since I use RateYourMusic for genre classification (I help with genre voting when I can).I just did a cross-reference check between your and my hierarchy files, and RYM itself to see if and what genres I needed to update in my hierarchy file.
https://gitlab.com/Flaky/mb-rym-hierarchy
Looking at your most recent file, if I am correct, these genres have been renamed by RYM but still have a previous name in your file:
...
Thanks for letting me know! I'll get it sorted soon.
12
Tips and Tricks / Re: MusicBee now works under wine
« on: April 18, 2023, 11:28:21 AM »
the .NET Core on Linux is different from the .NET framework being used by Windows and WINE, if I recall. And while possible, if Steven wanted to port everything to a cross-platform UI framework, it would take a lot of his time when he could just be perfecting the player as is. I would love for a Linux-native, feature-rich client like MusicBee, hell if I had the expertise I'd do it myself.
One can still dream, but if anything it might be worth more your time sending some bug reports to the WINE developers, to fix the bugs present when running MusicBee in there. The thing with open-source (and also one-man projects like MusicBee) is that you can basically talk to a human to get something fixed, almost immediately. A recent example is that drag and drop issues on MusicBee seem to be getting/gotten fixed in the latest staging builds of WINE - so I'd say, focus on reporting bugs to WINE rather than nagging Steven to port MusicBee to cross-platform.
One can still dream, but if anything it might be worth more your time sending some bug reports to the WINE developers, to fix the bugs present when running MusicBee in there. The thing with open-source (and also one-man projects like MusicBee) is that you can basically talk to a human to get something fixed, almost immediately. A recent example is that drag and drop issues on MusicBee seem to be getting/gotten fixed in the latest staging builds of WINE - so I'd say, focus on reporting bugs to WINE rather than nagging Steven to port MusicBee to cross-platform.
13
Tips and Tricks / Re: MusicBee now works under wine
« on: November 21, 2022, 02:19:50 PM »
Anyone here having issues with their MusicBee library on a native Linux filesystem (in my case, ext4) and the automatic retrieval for new files? On both Arch and Fedora, it kept removing then adding back existing songs, seemingly at random. I've had to move to Quod Libet as a result.
EDIT: I think I know what the issue might be? I think it might be my files having characters that are incompatible with NTFS. Even though my file system is ext4, .NET and by extension MusicBee might still have those NTFS-related limitations. I'll test this theory later.
EDIT: I think I know what the issue might be? I think it might be my files having characters that are incompatible with NTFS. Even though my file system is ext4, .NET and by extension MusicBee might still have those NTFS-related limitations. I'll test this theory later.
14
Tips and Tricks / Re: MusicBee now works under wine
« on: November 01, 2022, 06:03:55 PM »Okay I managed to make it work, but the sound is super laggy, the cover art do not display in playlists for some obscure reason, and japanese characters are all messed up.
The Japanese character thing is certainly a WINE issue, unhelped by .NET's handling of certain fonts.
Use Meiryo UI, Microsoft Yahei or WenQuanYi Micro Hei (whichever works) if you want CJK.
15
Tips and Tricks / Re: MusicBee now works under wine
« on: June 30, 2022, 02:03:58 PM »Someone told me about https://appdb.winehq.org/objectManager.php?sClass=version&iId=33888&iTestingId=111465
so I fully reinitialized wine and tried to run MusicBee with only winetrickingCodeanddotnet48Code. I fell back on the initial error I had :gdiplus
The main difference I have is that I use wine's latest version (7) and the last tested one is the 6th. I'll try with the 6th to check if it is indeed a version compatibility issue.
This error occurs when it can't find a valid card to play on. Check your winecfg, and if it says winealsa.drv, then you need to install the 32-bit PulseAudio/PipeWire libraries.