Some albums consistently get "processing: process cover: maybe fetch better cover: copy to tmp: context canceled"

[antifuchs]

I'm trying to import a particular album and wrtag and wrtagweb both are struggling with it: When importing it with the web service, the job that has the album checked out never terminates (the job keep showing up as "pending" in the list), and I have to pkill -9 wrtagweb to stop the service. On the CLI, I get this error after 3 seconds of run time:

time=2026-01-21T18:38:41.980-05:00 level=ERROR msg=running command=move err="processing: process cover: maybe fetch better cover: copy to tmp: context canceled"

It looks like I can't turn off importing that cover (via #118), so I'll manually download it and set that on the tracks to allow the import to continue, but this seems like an issue.

The cover that fails for me is https://dn710607.ca.archive.org/0/items/mbid-a4702c2a-3b5e-4b8f-84bd-ccb86074bc1b/mbid-a4702c2a-3b5e-4b8f-84bd-ccb86074bc1b-9518523492.jpg, but I think I've seen this on other albums too.

[antifuchs]

OK, update to this: Despite having set that cover with metadata image-write /tmp/ell.jpg -- path/to/album the move process attempts to download a new album, and fails to do so. I think it shouldn't do that? wrtag -config says cover-upgrade is false.

[antifuchs]

Oooooh, so reading through the code, I get it now: The cover handling code requires a (something).{jpg,png,...} file in the album directory, otherwise it'll download one. Think this needs mentioning in the docs, but it should also be possible to speed up that entire process by extracting a candidate cover from the tracks!

[sentriz]

good point, wrtag should consider embedded art when finding a cover. i created a ticket

that said the 3sec then context cancelled is puzzling

[antifuchs]

It's truly puzzling! Could it be something other than a timeout on the HTTP transfer itself? I notice that the context gets threaded through several other places too, so maybe it's cancelled on something that happens parallel? -log-level DEBUG didn't give me much to go on either.

[sentriz]

@antifuchs hm yes it could indeed be. would you mind posting your wrtag -config? thanks!

[antifuchs]

It's this (the subproc addon just chmods any files in the release dir that didn't catch the permission adjustment from #204):

:;    wrtag -config
addon            lyrics (lrclib), replaygain (force: false, true peak: false), subproc ("/nix/store/nqlly5fprpjw010r2qhrdzkp8hq893k3-wrtag-fix-perms/bin/wrtag-fix-perms" "<directory>")
caa-base-url     https://coverartarchive.org/
caa-rate-limit
config           true
config-path      /nix/store/527gzrwi22qs7n08pz8vhxw9nkxc1cp5-wrtag.conf
cover-upgrade    false
diff-weight      media format: 0.50, catalogue num: 1.20
keep-file        origin.yaml, log.cue
log-level        INFO
mb-base-url      https://musicbrainz.org/ws/2/
mb-rate-limit    1s
notification-uri
path-format      /data/Music/Library/...
research-link
tag-config
version          false