After installing Picard 2.0.2 over a 1.4.2 install, when attempting to launch the program I get a fatal error pop-up:
Error loading Python DLL ‘C:\Program Files (x86)\MusicBrainz Picard\python35.dll’. LoadLibrary: A dynamic link library (DLL) initialization routine failed.
When I re-install 1.4.2 and attempt to launch the program, it does so without issue.
So, I’m left with the question of why the latest version doesn’t launch. My initial thought was that it (likely) has to do with the version of Windows I’m currently running (Vista, 64-bit) but I’m not certain of that.
I assume you are running 64-bit Windows 10 by looking at your folder name for the location of python
-=-=-
It could be one of the plugins causing it. Not all of the 1.4.2 stuff has been migrated yet. And there are also many other reports of hiccups on v2.x (IMHO it is still looking a bit beta release)
Try going into your settings and rename the folder to hide it.
Go into %APPDATA%\Roaming\MusicBrainz folder on your PC and rename it to MusicBanana.
Now try restarting Picard. See what happens.
If it now launches, it tells you that your PC is fine and the problem is in the settings.
(Your can put all your settings back by just deleting that new MusicBrainz folder and renaming MusicBanana to MusicBrainz again)
Next trick - go into your MusicBrainz settings folder and you’ll see a PLUGINS folder. Yep - your plugins.
Either, go through to the help files online and there are now TWO plugins tables. Bit of a faff to compare, but you could go through your plugins and see which are on the supported list for v2.x.x
OR - just move the zip files out one by one. And try running Picard. One of those plugins is probably what is making you crash.
(I notice more plugins are getting updated day by day as the various authors catchup)
64-bit Vista (I did notice a response about the installer not correctly installing to the correct Program Files folder)
Attempting to rename the folder, even after elevating the system privilege when prompted, fails for me. In terms of the installed plug-ins, this is what’s in there (I don’t recall ever having changed it - I don’t find myself making use of them)
Moving them out and then attempting to launch the 2.0.2 version still throws up the same fatal error regarding the python35.dll.
Actually that isn’t that much of a joke for this poor guy. Vista is now on the official abandoned OS list. So it is going to be hit or miss to get many things working. Even Mozilla and Firefox have abandoned support for them. Google and Chrome gave up long ago. (I am having to migrate a few clients off of perfectly good PCs because of the dead-end of Vista)
First suggestion for OP - stick to v1.4.2 of Picard - “If it ain’t broke, don’t fix it”
Alternate options - I am not sure why you are being blocked from editing your own files in %APPDATA% folder. Have you setup a paranoid level of security on there? Or are you trying to edit this while Picard is running?
I notice the main fault is always spitting out errors on the Python code. Maybe you could manually update Python as I doubt the new installer will be testing for Vista due to it being out of support cover.
As you moved those plugins away and still go the crash I doubt they are at fault.
I can’t find any “recommended spec” pages for Picard. I have no idea if it has been tested on Vista. Kinda doubt it to be honest.
I also can’t find which version of Python is required for Picard. Or even which Python’s work on Vista. Documentation for both projects seem to be lacking specs (or I can’t find them on a quick check) The devs can answer that question better than me.
Weird little idea… run the Picard Installer but this time do a right click and “Run As Administrator”. Looking at the python support pages Vista has to be treated different to other WinOS versions.
Confirmed that Python is version 3.5 and built into the Picard Installer. So we’ll ignore the above…
If I get a chance I’ll fire up this old Vista PC I have sitting behind me. Due to be scrapped. Can’t remember if it is 32-bit or 64-bit on there but I can at least test the installer.
Well… I managed to locate the Python version. “At least version 3.5”
So I suggest to download the latest 64-bit Python from the Python site and install it.
When running that install, right click and “Run as Administrator” to giev Python best chance to get on the PC correctly. Then reboot.
One thing of note with your error is the fact it is throwing an error in the 32-bit python when surely a 64-bit Picard should be using 64-bit Python. So it looks like a config error to me.
Hang on… that is even weirder now I look at your error. ‘C:\Program Files (x86)\MusicBrainz Picard\python35.dll’
So that is some how installed in the 32-bit Program Files folder. What can you see if you look in C:\Program Files\ ? Do you have a MusicBrainz folder in there?
I’m not sure how useful that is, since Picard brings Python along with it (as you can guess from the filename of the DLL, Python 3.5). I suspect this is a situation similar to the embedded distribution where some C/C++ is missing.
I have an 64-bit Vista box sitting on the floor here now. Just getting rid of some junk and then I’ll install and test.
I thought they fixed the installation bug? The bug is closed on that link. If it installs wrong during my test I’ll manually move it an update any %PATH% that Python may have set. I can see that causing some confusions…
I’ll test this shortly and put notes up here as to my findings. This is a PC that has never seen Picard or Python so it will be a good comparison to the upgrade the OP attempted.
Test Run on Vista - using installer from today (09/08/2018)
Just ran the installer on a 64-bit Vista OS.
1\ Install path is still wrong - C:\Program Files (x86)\ - so bug PICARD-1292 has not been fixed.
I let the install complete anyway. I then got the same error message as the OP.
Error loading Python DLL ‘C:\Program Files (x86)\MusicBrainz Picard\python35.dll’. LoadLibrary: A dynamic link library (DLL) initialization routine failed.
I removed Picard by the uninstaller. Including all settings. Checked Regedit and %APPDATA% and those folders were clear.
Rebooted and changed path to correct C:\Program Files\ location.
Still get same error.
Any logs you want me to check?
Worth noting that Picard didn’t even get to write an ini file in %APPDATA% folder so I am guessing that it is failing to even start.
Question: Does Python v3.x support Vista?
Would it just be easier to point Vista users at the 32-bit edition? It is an abandoned OS now so may get messy to support when the 32-bit v1.4.2 still works fine on Vista.
It’s looking like that’s the route to go. Up until this point, I often updated what I could because I could never be completely certain a bug fixed in an updated version wouldn’t impact me due to the fact that I’m running XP’s lesser favored stepchild.
Same. Ever since the real reality of support for my OS ceasing perpetually set in (often arising in the form of errors similar to the one this thread’s based around but never exactly like it) I often pay more attention to the supported OS lists to make sure I’m not wasting my time with an unnecessary download and when looking at Picard’s landing page, if it’s there I’d need a microscope to find it.
I did run a check to see if Python was on my PC at all. Running a command prompt to check proved that it wasn’t (not that it needed to be for this) so I buzzed over to Python’s website and downloaded the latest build and installed it hoping it might’ve helped with this issue. Solved absolutely nothing but in terms of whether those builds will run (or even install) on Vista, I didn’t encounter any issue personally so I’d say they’re good despite Python also not having an easily found supported OS list either.
Not trying to edit it while it was running and there’s no additional security beyond what’s default with the OS, unfortunately.
The last thing I did was similar to what you mentioned trying - fully uninstall Picard and attempt a re-install of 2.0.2 into the proper 64-bit installation folder. Same fruitless results.
@TheMonkofDestiny with software like this that is written by a small online team I think the documentation is always the last thing to be updated. It is a boring job and more fun can be had working on the code. Testing is done by us users so limitations take a while to shake out.
Over on another thread ne of the devs confirmed this is being compiled on Win10 and checked on Win7. Clearly the main work is carried out in Linux. So old Vista is going to be low down that list of checking and waits for someone like yourself to give it a go.
My guess with this is that something Vista Specific needs to be initialised in the Python code. It doesn’t look like Picard even get started before tripping over a Python error. On my fresh PC here I get nothing written into the %APPDATA% folder. I would have expected to have seen at least the picard.ini file appear with some defaults in it.
So this may be an easy fix… if a dev wants to point either of us into a log we can check maybe we can feed something back.
Or it may just be easiest to stick to 1.4.2 for Vista and just update the spec for version 2.x to “Win7 and above”.
If you have python installed successfully, another option for testing is to download the Picard source code from GitHub and try running it directly. Note that this will give you some errors initially until you’ve installed all of the dependencies. One nice part about doing this is that it dumps all error messages to the console when run from the command line, so it’s relatively easy to find what’s causing the problem (including which dependency is not installed).
This is how I do my development work for Picard on my Windows 7 machine.
@rdswift the only Python code I have ever hacked around with was part of a KODI plugin. I left the main project side of that to someone else. Don’t have the experience of pulling whole projects and building them. Don’t really have the time for it. (Even now I am actually on hold on the phone waiting for something work related…)
But happy to offer the Vista PC to run any tests that anyone needs.
You’re not actually building the project. Just running from source. Once it’s all downloaded and copied to a directory (with the appropriate subdirectory structure), from the command line you simply change to that directory and enter “python tagger.py” to run it.
Sort of. I wouldn’t necessarily use the desktop, but it should work. The zip file does NOT include python or the required libraries. Those would need to be installed separately. My original note was in response to @TheMonkofDestiny because it was my understanding that they had already installed python as part of their original testing. Running from source would be another way of testing under those conditions.
