New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
on Windows fetchart gives errors verifying size even though ImageMagick is installed #1721
Comments
Thanks for reporting. Can you please expand with a little more detail about what you were expecting to happen and what isn't working? Configuration details and system setup information would also be helpful. |
I should have mentioned: a verbose log would also help give a glimpse at what's going on. |
+1, Pillow is also installed. Will provide config/system/verbose details later :) |
System: Windows 10 Education Version "1511" Portion from
ImageMagick:
Pip:
If further information is needed, I'm happy to provide :) |
Thanks, @Schweinepriester! I just pushed an update that should log more descriptive exceptions when things go wrong. Could you try again and see what the log gives you this time? |
Yes! :)
Seems to be something wrong with the logging? Just guessing :) |
Oh no; that was totally my fault—I messed up the changes to the logging. Can I ask you to run this one more time? |
Sure thing :)
|
OK! We're getting closer. Can you try running the command that errored out to see if it gives you any more details?
or, because that temporary file is likely to be gone already, point it toward some other image for testing. There's a chance that ImageMagick doesn't support the |
I canceled the first three because nothing was happening - with Links i found while searching for
Two options came to my mind:
I believe at least the second wouldn't cause trouble on other OSs, since its temp anyway? Are there other options? :) |
Thanks for trying this out! Actually, the quoting thing shouldn't be a problem for the way we're executing the command... since we're bypassing the shell's parser and passing the entire path as a unit, we shouldn't need to worry about escaping. So this command that you ran:
is probably the closest to what beets is actually doing. And it worked! So I'm a bit mystified about what's going wrong. I should have access to a Windows box pretty soon. I'll see if I can reproduce this and dig a little deeper. Thanks again for your cooperation! |
Alright! I'm happy (and selfish) to help :) B-) If I can assist further, just let me know. |
Well, depressingly, I wasn't able to reproduce this. On my Windows 10 machine, ImageMagick 6.9.2-6 installed from Chocolatey worked totally fine to measure the size of images. 😢 So I'm still not sure what's going wrong with the invocation on your setup. I can continue to ponder what additional logging we can try to figure out what's different between beets running that |
That could be the difference, because I installed it directly from http://imagemagick.org, maybe something gets configured differently - will check tomorrow evening (roughly 20h from now). Maybe @dprus can comment in the meantime? |
Another thought: Powershell vs. cmd? But of course as you said:
|
Yeah, I agree it probably shouldn't matter—but for whatever it's worth, I was using PowerShell. I've pushed one last shot. This time, the machinery should print the actual output from ImageMagick in the debug log. Maybe that will offer a clue! |
Here we go :)
That path ``C:\Program Files\ImageMagick-6.9.2-Q16\modules\coders\IM_MOD_RL_\?\C_.dll' Just in case it could help: (Right now sadly no time to test with IM from Chocolatey, but will do that soon if needed) |
Thanks again! On further inspection, I'm guessing that crazy DLL path is actually a red herring. If I give it a path in that format that actually exists:
I get a size just fine. But if I just make the path point to a file that doesn't exist:
it says:
just like your output! So I think that's the problem: the file actually doesn't exist. But now I'm stumped again, because the fetchart logs seem to show the file being successfully downloaded. Maybe some Windows service is being overzealous about deleting files in that temporary directory? |
Had to look up red herring :D Well, i guess what you are observing is correct behavior, but I checked if But now I recorded a GIF which shows two errors
After recording the GIF I checked additionally the first issue with just a space (renamed the file first of course):
I still hope/think the first issue can be fixed by surrounding the path with Will try now to find a solution for the second one and what happens with IM from Chocolatey :) Maybe I should just use beets inside Cygwin, to avoid those crazy windows-paths :D |
Does work :) From: https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx => https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath (and some trial and error :P) But it doesnt work with
But maybe that doesn't matter for the context of beets? |
To complete my wall of text with logs from IM from choco:
and on the same drive (C:)
TL;DRSo there we have it, a |
Wow! Thanks for all this extra investigation. It's truly strange that the problem indeed seems to be crossing filesystem boundaries—I'll need to do some more reading to understand what's going on. Especially puzzling is this bit from the MSDN docs:
So that prefix is special-purpose for device-related APIs. It doesn't intuitively sound like something ImageMagick would support, but apparently it does! Mysterious! |
OK, I've pushed a (temporary? possible?) fix by just disabling that Windows ?\ prefix for ImageMagick calls. The hypothesis is that IM just gets confused by them. Can you check whether this makes things work on your system? The cost, of course, is that we may lose support for long paths. I'm crossing my fingers, though, that IM has built-in, special support for long paths and we just don't need the prefix when dealing with it. |
Sorry for the late response, had to write my thesis :P Just checked with the new shiny 1.3.16, seems to be working:
Lets assume it works, will monitor in the future with long path etc. :) |
Woohoo! |
I found this while searching for my own error (which I will be filing separately), but on Cygwin Python at least you need to escape. I have been struggling with the acoustid plugin on Cygwin, and the first error I got was a "file not found" error trying to run ffmpeg. Making sure that the filename is in quotes in the args array passed into popen made that go away. I still have another problem, but Cygwin Python has some quirks (like trying to kill a process, the pid has to be obtained a different way). |
Just before running "beet import..." I type "convert" in the same Shell and verify that it is ImageMagick (i.e. it's in the path, etc.).
However fetchart still says: 'fetchart: could not verify size of image: please see documentation for dependencies. The configuration options
minwidth
andenforce_ratio
may be violated.'The text was updated successfully, but these errors were encountered: