getmusicbee.com
Support => Developers' Area => MusicBee API => Topic started by: ganamide on November 21, 2016, 06:34:53 PM
-
Any progress on this plugin? It was working great the first day I used it, but since I didn't get the Discogs account registration email, my account was disabled until I emailed support to get it reactivated. Now this plugin refuses to work no matter how many times I reinstall it and re-authorize it. Very frustrating since Discogs is so much better than the other options and the Discogs plugin works just fine in Mp3tag so I know it's not a Discogs problem.
I am a programmer and I might be interested in taking a crack at fixing this plugin since it would be very useful.
-
try deleting the file "discogs.token" in the musicbee appData folder
-
Believe me, I tried that many times. I also applied latest MB patch and restarted my computer. Then I replaced the mb_Discogs.dll file with an older version, restarted MB and that didn't work. I gave up on it for about an hour, then put back the latest mb_Discogs.dll file and restarted. Now it works. I'm thinking the old code or settings got cached somewhere.
Still, it would be nice to make some improvements. Often times I get unexpected results when using the Album Auto-Tagger depending on the search criteria being used, especially when dealing with Various Artists album compilations. Adding the release id as others suggested would help a lot in this regard.
Another related topic is the individual track auto tagger. Would be great if we could preview the changes before applying them. I often want to replace existing tag fields based on the digital sound signature, but if the wrong song is detected I don't want to lose the existing tag values.
-
Spoke too soon. I tried Album Auto-Tagger again on a large box set that I was having problems with and it no longer picks up Discogs result. I am thinking it has to do with the large number of files selected for the search. Is it possible that the plugin is sending multiple requests to Discogs based on how many files were selected? Seems like an inefficient way to do things, and it might lock us out for violating the Discogs API hit rate. The box set in question has 63 tracks. When I use Mp3tag program, I never have a problem getting results and it only takes a few seconds.
-
you can easily tell what MB is doing by using fiddler2
-
Thanks for the tip! Fiddler is a neat tool. I ran fiddler while doing the Album Auto-Tagger and I didn't see any web requests for Discogs despite it being enabled in the Tags (2) Preferences. I see requests going out to freedb and musicbrainz. When I run Mp3Tag, nothing gets logged in fiddler even though the queries work. Maybe they don't use http? Is there anything else I can do to debug my broken Discogs Tagger? I have lots of experience debugging C# applications in VS. Did some VB stuff a long time ago.
-
Check the fiddler documentation. I think you need to temporarily configure mp3Tag to connect to a specific port that fiddler listens on while fiddler is running. Not sure why you cant see the discogs but try the same by configuring MB to connect via the same port
-
I changed Mp3Tag proxy settings to go through fiddler and I can now see their requests going to api.discogs.com on port 443. I still don't see a similar request coming out of MB. I think the problem is either in MB or in the Discogs Tagger plugin for MB. Is there any logging we could enable to debug this problem further?
MusicBee is a great program and I really appreciate you making it and giving it away for free. I would love to help fix it or contribute in some other way. I am actually surprised you are giving such a feature rich and good looking program away for free. Have you thought about monetizing it or making it completely free and open source so that others can help fix it? I am willing to help you out in either direction.
Thanks, Chris.
-
i dont have time to maintain this plugin. I have sent you a PM with the plugin code if you want to fix or enhance it
-
Thanks for the code.
I found a few issues that were specific to the box set I was trying to get data on:
1) Any release that contains at least one item in one of the following formats is skipped: PAL, Cassette, 7", 12", 45 RPM, Single Sided, Vinyl, LP, Minidisc. My box set contained one 7" vinyl and 5 CDs, so all returned results were skipped.
2) A matching Album Artist and a matching Album Name are BOTH required. Many times I blank out the album artist field when I do a search and apparently this would prevent any result from being returned.
I propose to change these rules to:
1) Don't skip any release because of the listed format. Just because something was on vinyl doesn't mean it can't be used as metadata for a digital copy of the same.
2) Only require a similarly matching Album Artist if it was not empty in the search form
Do you agree with these changes, or do you have any other suggestions?
-
i am happy for you to do as you wish. If you want to open-source it then i just ask you dont make the api key and secret available.
-
Hi Steven,
I am trying to further modify the discogs plugin to work with the box set, however, it looks like the plugin was not designed to handle box sets, and instead treats each release as a single disc. There is some code that handles splitting tracks by disc, but in the end only the first disc gets returned by the plugin to MB.
I want to ask before I spend much more time on this if MB will be able to handle a result from function GetReleaseInformation with multiple discs in it, and if so, how would this look? I would prefer if the result that the plugin returned was a flat array of tracks which contain tags for track#, track count, disc#, and disc count, in addition to the other standard tags. This would let a user map all the tracks in a box set at once instead of working with individual discs one at a time.
On a related note, I noticed that discogs can have non-numeric track# tags, such as "A", "A1", "CD1-1", etc. I guess they call them positions, and most of these strange ones seem to be related to non digital media. I wonder if I should leave these alone or convert them all into integers starting with 1.
Thanks,
Chris
-
I want to ask before I spend much more time on this if MB will be able to handle a result from function GetReleaseInformation with multiple discs in it, and if so, how would this look? I would prefer if the result that the plugin returned was a flat array of tracks which contain tags for track#, track count, disc#, and disc count, in addition to the other standard tags. This would let a user map all the tracks in a box set at once instead of working with individual discs one at a time.
the "QueryReleases" function allows you to return multiple results and is already the case as implemented, so i guess i am not understanding your question. Did you try? and if its a problem, show an example
-
I was actually talking about "GetReleaseInformation" function, which appears to return all the tracks for the selected release. If you take a look inside this function you will see a call to a private function called "GetReleaseDiscs" that does most of the parsing, and returns "List(Of RequestResponse)". What I was referring to is that only the first item of this list is actually used in "GetReleaseInformation":
result = GetReleaseDiscs(lastQueryResults(index))(0)
Notice the last zero? So even if I fix "GetReleaseDiscs" to return a list of all discs in the box set, only the first one gets passed back to MB. Since I don't have the code to MB I can't tell what it's expecting. I can only guess based on what the plugin is currently returning, or I could spend time trying different things to see what works. Right now it looks like calls to "GetReleaseInformation" are expecting a single disc.
I guess I'll try setting track#, track count, disc#, and disc count tags on each track and return all tracks as if they belong to the same 'disc' as returned by "GetReleaseDiscs".
-
After looking at GetReleaseDiscs some more, I realized that what I wanted to do might not be possible without changes to MB. I was a bit surprised to find that the tags for multiple tracks are concatenated together for each tag type. For example, adding the track number for each track after the first is done with the following line:
item.Tags(MetaDataType.TrackNo) &= ChrW(0) & trackNo
So for a 9 track disc we end up returning a Key Value pair that looks something like:
key = MetaDataType.TrackNo, value = "1 2 3 4 5 6 7 8 9"
Or should that look more like this and MB parses the hyphens into disc-track?:
key = MetaDataType.TrackNo, value = "1-1 1-2 1-3 1-4 1-5 1-6 1-7 1-8 1-9"
I just don't see how I could return a list of track entries that would span multiple discs using the current data structure. I was hoping for something more along the lines of returning a collection of Track records, each record having its own set of tags.
-
you can include the disc number in the results appending that to the results:
MetaDataType.DiscNo
and MetaDataType.DiscCount if you wish
-
DiscNo and DiscCount are currently being returned as single values. Would I be able to put many different TrackCount and DiscNo values using the same concatenation construct that is being used for TrackNo?
Here is an example using a master release that has two discs where the first disc has 4 tracks and the second one has 3 tracks. Let's give them the following position values 1-1, 1-2, 1-3, 1-4, 2-1, 2-2, 2-3.
The current plugin code would split the results into two discs and only return the first one with the following pairs of interest:
key = MetaDataType.TrackNo, value = "1 2 3 4"
key = MetaDataType.TrackCount, value = "4"
key = MetaDataType.DiscNo, value = "1"
key = MetaDataType.DiscCount, value = "2"
Would the plugin be able to return something like this instead for both discs in a single result?:
key = MetaDataType.TrackNo, value = "1 2 3 4 1 2 3"
key = MetaDataType.TrackCount, value = "4 4 4 4 3 3 3"
key = MetaDataType.DiscNo, value = "1 1 1 1 2 2 2"
key = MetaDataType.DiscCount, value = "2"
DiscCount is the only value that is the same for all tracks, so it can remain a single value. BTW, there are additional key/value pairs that I am leaving out of this example that would also be in the result, such as TrackTitle, Artist, and Duration, which of course would contain data for all 7 tracks in my 2 disc example.
-
i can make changes for v3.1 to support your requirement.
The current MB version doesnt actually parse TrackNo, so to keep backwards compatibility i suggest TrackNo be loaded with either multiple track numbers for single discs or multiple disc and track numbers for multiple discs
eg.
for multi-disc
key = MetaDataType.TrackNo, value = "1-1 1-2 1-3 1-4 2-1 2-2 2-3"
MB could also support this for single disc but its not really necessary as it can be inferred like now
key = MetaDataType.TrackNo, value = "1 2 3 4"
track count could be inferred as is the case now
Let me know if thats acceptable and you are going to make the change and if so i will update v3.1 which is already released for testing
-
That's acceptable. I assume you will be inferring both the TrackCount and the DiscCount in the multi-disc scenario, correct? I'm ready to make the change now.
-
I guess I could just pass in the DiscCount as is already being done. Whatever works for you. Any idea when you can make the change to support the multi-disc result?
I finished designing an algorithm to convert most of the various discogs position number formats that could result from supporting different types of multiple disc and multiple format releases. It wasn't easy, and it won't cover every single case, but I think my design will work for 99.9% of them. If it all works out, the plugin will be able to split the following different types of position values into separate discs and tracks:
A1, A-1, CD1, CD1-1, ALPHA1, LP-A1, 12"-A1, 10'' A, LP A1
I will also be handling mixed media that often comes in box sets such as CD + Vinyl or CD + DVD. In order to do all this I will write code that detects disc or side changes, combines two consecutive sides into one disc (i.e. side A followed by side B tracks both go on one disc), and auto-number the discs and tracks based on order of appearance and not use the actual value in the position field.
Here is an example of how my changes will convert the following sequence of track positions from discogs format into DiscNo-TrackNo format:
Input : A, B1, B2, B3, C1, C2, D, E, CD1, CD2, CD3, CD4, DVD1-1, DVD1-2, DVD2
Output: 1-1, 1-2, 1-3, 1-4, 2-1, 2-2, 2-3, 3-1, 4-1, 4-2, 4-3, 4-4, 5-1, 5-2, 6-1
I think this conversion is the best way to handle it. What do you think? Would it make sense to display the TrackNo, TrackCount, DiscNo, and DiscCount columns in the track match up table? I've often found myself wondering what values the auto tagger found before committing to apply the tags.
-
Any idea when you can make the change to support the multi-disc result?
i will look at it this weekend
-
http://musicbee.niblseed.com/V3_1/MusicBee31_Patched.zip
unzip into the folder MB is installed and replace the existing files
as discussed, if you populate the MetaDataType.TrackNo then mb will use the values for track number and if a "-" is included, it will split the value into a disc and track number.
Track count and disc count will be inferred from the values supplied
You should also supply a single disc number and disc count in the same way as its done now for backwards compatability
mbApiInterface.ApiRevision >= 50 indicates MB has this new functionality if you want to check if the new functionality is supported
edit:
also i recommend a small change to the internet connection code. I will PM you that later or tomorrow
-
I got the latest 3.1 beta, made the connection change you recommended in the PM, and folded in my new code without the backward compatibility check (I'll do that after I get this working.) The disc#, discCount, and track# fields all seem to work. The only field that is not working for me is the trackCount, which is set to '1' for every single track in the box set. It looks like I am sending the correct multi-disc, multi-track format for trackNo field:
{[86, 1-1 1-2 1-3 1-4 1-5 1-6 1-7 1-8 1-9 1-10 1-11 1-12 1-13 1-14 1-15 2-1 2-2 2-3 2-4 2-5 2-6 2-7 2-8 2-9 2-10 2-11 2-12 2-13 2-14 2-15 3-1 3-2 3-3 3-4 3-5 3-6 3-7 3-8 3-9 3-10 3-11 3-12 3-13 3-14 3-15 4-1 4-2 4-3 4-4 4-5 4-6 4-7 4-8 4-9 4-10 4-11 4-12 4-13 4-14 4-15 5-1 6-1 6-2]}
86 is the enum value for MetaDataType.TrackNo, which is the key in this case. The string of dashed pairs are <disc#>-<track#> values for all tracks in this 6 disc box set.