Handling of Request limit exceeded condition and Various Artists albums/compilations
audiomuze opened this issue · comments
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:
- from prior conversatons it would seem that get_cover_art only polls itunes.apple.com once if it finds the cover art associated with a track if other files in the same folder have the same album. Is this the case, or does itunes.apple.com get polled for every track in a folder, and only the download is avoided if the cover art had been downloaded previously for another file in the same folder?
- does
--no-skipget overriden by--force? - if I run
get_cover_art --no-embed --art-dest-inline --art-size 9999 --art-dest-filename xfolder.jpg --verbosei.e. without--forcedoes that mean get_cover_art will skip over any folders already containingxfolder.jpgor is it using another method/stored list to figure out what's been previously processed?
- yes, that is the case (unless you use
--force) - In a way, yes.
no-skipflushes the temp file that marked artwork you had already failed to find before.forceignores that temp file completely. - 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.jpgfile 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-inlineand such.
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,
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!
Seems to me to be doing what's intended.
That's great to hear! Thanks again for reporting this in the first place, closing ticket.