Providing multiple auto-tag results

Post a reply

:D :) :( :o :-? 8) :lol: :x :P :oops: :cry: :evil: :roll: :wink:

BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON

Topic review

Expand view Topic review: Providing multiple auto-tag results

Re: Providing multiple auto-tag results

by PetrCBR » Sun Mar 07, 2021 4:08 pm

This method should download complete data for the specified lookup. For example from any complex search i know just album name and this method should download remaining data like Album Artist, date etc. (or actors, description, director etc. for series). If you don't need to download any additional data (you have all you want, but in most cases for performance reason you do not download complete info about every track lookup), you don't need to define this method.

Re: Providing multiple auto-tag results

by TIV73 » Fri Feb 26, 2021 3:46 pm

Awesome, I appreciate it!

One more thing - how does getDetailAsync work? From the documentation and samples I understand that it should implemented on each located track by the tagger so the framework can then call it to get all information about that track, but what should the method specifically do?

I mean, should it return a json object with the track details, or modify the track object that gets passed as parameter or call applyToTrack or something?

Re: Providing multiple auto-tag results

by PetrCBR » Thu Feb 25, 2021 6:21 am

Hi there.

It's not possible now to call getDetailsAsync for whole album. Adding to my todo.

Providing multiple auto-tag results

by TIV73 » Thu Feb 25, 2021 4:52 am

Hey there,
I'm working on a auto-tag plugin for vgmdb. Everything is pretty much working as intended, but I'm stumped on how to include the functionality to populate the album dropdown with additional results if more than one were found (and subsequently act on it if the user selects one).

From the autotag framework and musicbrainz plugin I figured out that the general idea is to get all search results for a given track when doing the initial lookup and add them to the searchmanager via addTrackLookup. The framework will then automatically populate the dropdown from these results via getTrackLookups.
When the user selects a different album, the framework calls getDetailsAync for the respective lookup on each individual track which should return the needed details.

The issue that I'm having is that lookups per track are not possible with the vgmdb API (or at least not feasible without risking a massive amount of api calls). It is only possible to query for albums based on name, id, etc., and then request details for album objects which contains all data data for the album, down to the track details.

My approach (which works fine if I only try to provide a single search result) is to
- get album details for each search batch
- query the api for a list of matching albums
- try to divinate the best possible search result by comparing each search result to the current album
- request album details for the best match
- parse track details from the album object and match these located tracks to the local lookup tracks
- call applyToTracks with the finished array of tracks and located tracks

This probably sounds like it's somewhat imprecise and hit and miss, but in practice the process is reasonably reliable since the scope of the site is much more narrow compared to bigger sites like musicbrainz, so you are likely to get the correct search result from just album details. The big caveat is that auto-tagging only works for albums, lookups for individual tracks are not possible.

And therein lies the issue to implement multiple search results. Since the album selection is populated from individual track results, the tagger needs to provide a tracklist upfront, which I cannot do without either requesting details for each found search result or trying to sidestep the entire workflow by providing the search manager with dummy tracks that only contain the album name.
The former risks getting the user banned by generating a huge amount of api calls if the search term is too broad, and the latter is prone to fall apart sooner or later because it's impossible to know if actual data exists for the generated dummy tracks.

So, is there a way to populate the album dropdown without having to provide track details upfront and then have the framework somehow request details on album level from the tagger instead of calling the getdetails method on each individual track?