There is nothing standard about the list view controls at all. They're implemented using Peter's rather excellent libPPUI library bundled with the fb2k SDK.

You can see how some columns are auto-sizing and some aren't here...

https://github.com/kbuffington/foo_musicbrainz/blob/d91a77ef3d1f7a05dfe6c30a19d77007683fd03b/src/dialog_tagger.h#L119L125

You can change it if you want to.

• Added caching to requests. This required adding a Least Recently Used cache to the program, and then checking for the request in the cache before making a request to MB for the resource. The cache will hold 100 entries (might be too much?) and get marked stale after 60 minutes. This also necessitated redoing the method for delaying entries. Now we only sleep enough so that the next request will always happen 1000ms after the previous one, regardless of what made that request.
  
• Shrunk release date and media type columns
• Added initquit to abort threadpool on program exit

FreeDB will not find anything unless you supply a substitute FreeDB server, since the official service was taken down on March 31st.

Hello, I hope this is the right place.

- is it possible to re-route the MusicBrainz tags to custom metadata fields ?  (I'd want MusicBrainz (Track) ID / MusicBrainz Release ID / MusicBrainz Artist, plus a few others most likely - but only ever to their own custom frames... never the standard ID3/Vorbis Frames, which seems to be the un-editable default atm in foo_musicbrainz ?)
- and additionally, but this is probably beyond the scope - also add AcoustID & AcousticBrainz ID plus some of the AcousticBrainz  data...?

But it will overwrite Album, Album Artist, Song, Date (and maybe genre)

Quote from: JohnBuckWLD on 2020-05-22 15:27:29

But it will overwrite Album, Album Artist, Song, Date (and maybe genre)

Thanks for the info!
Unfortunately each of the above is a no-go...

Question for @MordredKLB I'd guess:
Is this - making the fetched MusicBrainz  (& potentially AcoutsticBrainz) data map-able to custom ID3 & Vorbis fields/tags - planned already by chance or potentially an option for the long run

I have no plans to add AcousticBrainz support. That's a completely separate backend/API and seems out of scope to this component.

Can I ask what the reason is you want to adjust those property names? It definitely adds some complexity to the component, but I'm struggling to see why you're fine getting MUSICBRAINZ_ALBUMID, but you just want it stored in CUSTOM_ALBUMID.

My reason being that I have a tag nomenclature & tool set I am fairly happy with, and which is Discogs based.
What I would be interested in is some of the MusicBrainz data... to give 2 different use case examples:

MUSICBRAINZ_ALBUMID, as it is a unique/proprietary tag name, I have no problem with and could use it right away... as for what - in MusicBee one can dynamically string together URLs based on Discogs and similarly, with Musicbrainz data too, and display them within the UI as a direct link to Discogs/MusicBrainz/Wikipedia/LastFM pages for the playing song. For this the existing ID tags would be interesting, and to evaluate the AcousticBrainz relation, which uses the same ID as MusicBrainz for their URLs (and API as well I would assume).

More problematic - and the reason I would not be able to use foo_musicbrainz as is unfortunately:
I would also like to use some of the default field info - like Artist, Release Date, Genre, Tags etc - but as these are only writeable to default fields (which are and will need to stay discogs data populated for me), I would need/want to re-route these to custom fields - i.e. "MUSICBRAINZ_GENRE" (or whatever name I decide on),  "MUSICBRAINZ_ALBUM", etc.

Hope that makes sense - not sure if this is a recurring request (for the more music geeky users) though, as most probably stay with whatever tagging system they decided on at some point.

Chur.
c.

ps. another question as well - is there a list for all tags/fields/data that foo_musicbrainz is currently capable of retrieving & writing ? One thing I would love to grab from MusicBrainz is Track-relative instrument credits (where available), but from what I've seen so far, these are not accessible, correct ?

It's great that this has been updated! It's so much better than the old component now that it doesn't throw out lots of errors, import tags with weird hyphen and apostrophe characters, and actually finds stuff consistently.

One idea I do have, which would be cool: Could the tagger window have an autofill dropdown when editing the track artist field, based on the artists in your foobar2000 library? This works in the foobar2000 default properties window and it'd be great to have the option to do this, it'd make tagging tweaks in the MusicBrainz Tagger window a lot easier.