Import using only on mp3 tags?

hi, i have a “residual” set of albums that my main matching process (with tuned matching weights on chroma fingerprints) is failing on. But the MP3 files all have tags (eg, available via tinytags) and i’d prefer to have these in my database even if missing all details. is there a recommended path thru beets that can populate beets’ DB correctly with only these bits? i’d imagine first populating a MusicBrainz query to look for matches there. thanks for any suggestions or related work. - Rik

I think what you need is the “as-is” option while importing, or the -A (don’t autotag) CLI option?

Thanks once again Adrian! i find the -A CLI option, but not reference to any other “as-is” option; did you mean to refer to some other route?

i’m also now trying to use fetchart. it is bumping into lots of Unicode mismatches between what the items’ paths have and what the OS thinks exist(: again, (in grody-but-better-than-nothing mode) i’m looking for a way to capture the Error: No such file or directory while moving /tmp/tmp_rkikS.jpg to ... exceptions, to just proceed on the rest, but can’t follow the path from ui._raw-main() thru to FetchArtPlugin.batch_fetch_art() or similar; would you know where this exception is being thrown?

“As-is” is one of the options you get at the interactive prompt when importing an album, not a CLI flag.

About that crash you’re seeing, it’s impossible to say without seeing the full traceback… maybe it would be helpful to fill out the “bug report” template on GitHub issues with complete details?

there’s no traceback; it just emits that error and terminates.

i also hear your nudge towards github issues, and am happy to post things like this there, as it seems your preference? do you want things to start conversations here and have only some got to repo issues, have all discussion go there now, …? i realize you are taking the community pulse on this but i’m happy to follow your lead.

Basically, when something really seems wrong (i.e., might be a bug), using the issue template is often helpful just because it elicits information that’s helpful in debugging what’s going wrong. So it’s not the medium (forum vs. issue) that is as important as the guidance that the bug report template contains.

got it. so how about this case: beet fetchart terminates after the first mismatch between an item’s path, which somewhere is wrangled into the ALBUM’s directory, somehow tripping on a unicode difference with the actual path (ie, as used by the OS), and quits trying to fetch anything else. i’d write a PR to catch this error in a try:, report it, and continue on, but don’t know where to apply this?

i found where to put the error check in beetsplug/fetchart.py and propose the following patch:

@@ -1122,11 +948,15 @@ class FetchArtPlugin(plugins.BeetsPlugin, RequestMixin):
# filesystem. When forcing, however, always go to the Web
# sources.
local_paths = None if force else [album.path]
-
candidate = self.art_for_album(album, local_paths)
if candidate:
-                    self._set_art(album, candidate)
-                    message = ui.colorize('text_success', u'found album art')
+                    try:
+                        self._set_art(album, candidate)
+                        message = ui.colorize('text_success', u'found album art')
+                    except Exception as e:
+                        message = ui.colorize('text_error', str(e))
+                        self._log.info(u'{0}: {1}', album, message)
+                        continue
else:
message = ui.colorize('text_error', u'no art found')
self._log.info(u'{0}: {1}', album, message)

i’d like to make this a pull request, and Adrian suggested i shout out here in discourse how he’d like this handled?

Hello! Generally speaking, a good way to send proposed changes is though GitHub pull requests. The GitHub docs have good guides about this, but I’m interested if other people have good ideas for how to get started with PRs.

However, this particular change seems like it might be a little too broad… it’s capturing every exception, which could suppress even important coding mistakes that we would really, really want to crash on. It would be super useful to see the full details of what this crash looks like… the issue template lists all the details we usually find useful (and again, these complete details are useful regardless of the medium: an actual issue or just a forum post).