regosen / get_cover_art

Batch cover art downloader and embedder for audio files
MIT License
69 stars 8 forks source link

Handling of Request limit exceeded condition and Various Artists albums/compilations #27

Closed audiomuze closed 2 years ago

audiomuze commented 2 years ago

I unleashed get_cover_art on a folder containing 1707 folders, each folder representing an album. It ran as expected and hit the occasional WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds... following which it would resume and continue where it left off. At some point it hit a folder containing a compilation/various artists album with 48 tracks.

At that point I got many hundreds of sequential WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds... messages with no further cover art being downloaded.

Counting the number of instances of xfolder.jpg present in the tree after I'd terminated get_cover_art it shows that 998 folders had cover art added, meaning in all likelihood some number of over 1000 folders were processed.

Looking at the output from --verbose ... 100's of lines of:

WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...
WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...
WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...
WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...
WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...
WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...
WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...
WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...
WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...
WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...
WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...
WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...
WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...
WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...
WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...
WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...
WARNING: Request limit exceeded from itunes.apple.com, trying again in 3.0 seconds...

I'm not sure whethe it was the 48 track folder or the fact that itunes.apple.com will have been polled many (possibly thousands of times over by this juncture), but my guess is itunes.apple.com had decided I'd had enough and it wasn't dealing with traffic originating from my IP address anymore. I get that the timeout happened, and I get why, but I have some questions:

Questions:

regosen commented 2 years ago
  1. yes, that is the case (unless you use --force)
  2. In a way, yes. no-skip flushes the temp file that marked artwork you had already failed to find before. force ignores that temp file completely.
  3. You might be onto something here. If a folder contains songs with multiple artwork but they're all using the same filename then not only will the same xfolder.jpg file get overwritten multiple times, but if a query fails then it will skip the rest of that folder regardless of metadata. Honestly, if you have files with different album metadata in the same folder, then I would avoid using --art-dest-inline and such.
audiomuze commented 2 years ago

Thanks, I'll need to look carefully at how I call get_cover_art. As I don't embed cover art and don't have files with different album metadata in the same folder my needs appear pretty simple - trawl my entire collection (each folder being a discrete album) and pull the highest resolution cover if it doesn't already exist i.e. if xfolder.jpg is absent,

regosen commented 2 years ago

Update: I just found and fixed a possible bug with --art-dest-inline, just published the fix as 1.6.1. Let me know if that helps!

audiomuze commented 2 years ago

Seems to me to be doing what's intended.

regosen commented 2 years ago

That's great to hear! Thanks again for reporting this in the first place, closing ticket.