Show Posts
1
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)
