Please test new Picard Windows builds

The link to the “tickets for Picard 2.1” needs a login. Is there a publicly view-able version?

What kind of checks do you need done? Due to the nature of my job I have a number of PCs knocking around I can run installations on. Including a Vista box sitting on the floor behind me that was due to be scrapped.

One initial bit of feedback I’d give is on the Win10 tile. As someone who adjusts the colouring of his own Win10 menu I’d personally prefer the background of the tile to be invisible so I can keep my own start menu colouring. Though that purple is quite nice if it has to be coloured.

2 Likes

Sorry, updated a link to a one that should work. Don’t quite understand why the other view is not public, it’s definitely nicer.

My main concern really is that it must start. But testing some functiinality like scanning, lookup and open in browser would be good as well.

The problem with not defining a color is that Windows then uses that blue by default, which does not really work well with the logo colors.

A post was split to a new topic: New plugin user interface in Picard development version

When you say “uses blue by default” - have you set the Start Menu to be coloured? The colours chosen are pretty good though.

I’m stuffing this on a memory stick and trying on a few computers for you. I assume Vista is as old as you go now.

1 Like

It seems to be running without issues for me on Windows x64 until now.
The ‘solo’ attribute seems to be fixed too, and is now again tied to the instrument, so that’s nice.

1 Like

Feedback from installing on various Windows PCs. (This post will keep getting up dated with other findings as I run on other PCs)

Win10 Pro (x86) PC first.

Missing icon at install time
During install I ticked “Start menu”, “Desktop” and “Taskbar” icons. Only the first two appeared - no icon was added to the taskbar.

Do I assume you are not automatically pinning a Tile to the Start Menu? Just adding to the normal A to Z list of applications.

Start Menu Tile
Funnily enough, when I pinned up the Tile to the Start Menu it fitted this PC almost perfectly as it is a very very similar shard of violet. :smiley: Still think that transparent would be better as it allows more choice for the user.

BUG IN THE INSTALLER
Found my first show stopper of an issue. Why does the installer not warn that this is a 64-bit app? I happened to pick a 32-bit Win10 PC to test on. The installer ran right through to the end, and only when I tried to run the application did I get told it was not compatible.

The “Is this a 64-bit PC?” test should really happen in the installer.

(I think I remember something saying there will be no 32-bit release. So this Win10 PC is now abandoned from this test)

Test of uninstaller
This passed with flying colours. No traces left after uninstallation.

-=-=-=-

Vista Home Premium (x64)

Ahhh… the ever lovely Windows Vista. Everyone’s favourite OS…

Missing icon at install time
This time all three did appear. The Quicklaunch\taskbar icons is present this time.

Launch Application fails - Error Loading Python
Message box appears:
Error loading Python DLL: C:\Program Files\MusicBrainz\Picard\python37.dll
LoadLibrary: A dynamic link library (DLL) initialization routine has failed

Should the Picard installer have installed the relevant Python libraries? I remember this coming up a few months back but the implication there was this should work on Vista x64. (Python 3.7 claims to still work on Vista)

Rebooting made no difference. Let me know what else to check here.

(More tests to follow…)

1 Like

No, that “Task Bar” does not even exist on Windows 10 anymore AFAIK. It’s that area which I think was also called “Quick Launch” on the very left of the task bar, where some fixed icons where placed. With changing the taskbar to a more dock like behavior this no longer exists. I think we should probably remove this from the installer. I added PICARD-1370

I added PICARD-1371

This is exactly the kind of issue I am looking for :slight_smile: Of course all required libraries should be installed, but this indicates an incompatibility of this DLL with your system.

To narrow this down can you please try the following:

  1. Does current Picard 2.0.4 run on this system?
  2. Does the Python 3.6 version from AppVeyor work?
  3. Does the Python 3.5 version from AppVeyor work?

Quick reply to that… no Picard has ever been used on this computer before. Totally fresh install.

1\ I am kinda guessing that the answer to 1 will be “No” as this was brought up in August. I’ll still get hold of the current installer and confirm.

2\ and 3\ You are being way too cryptic. I do not work on the Picard project so don’t know what that page is saying. Give me a better hint of what is needed. How would I swap Picard to use older versions of Python?

The Python site does imply that v3.7 should work on Vista x64. Is there a config file I can tweak to make the change?

And yes - I was expecting these odd machines to cause problems. It is why I picked them. :smiley: No point in doing simple testing. It is the Bastard Testing that brings out the useful stuff. :wink:

Update: I am guessing that by running v2.0.4 it tells us that question 2 and Python v3.6 will also fail.

I have again tried to make sens of the appveyor.com link to a Python 3.5 version but I can’t see where the exe is. Just seems to be the output of a logfile to me.

More on the VISTA x63 test

Uninstall does not remove all icons
The DESKTOP and START MENU icons are left behind. The Quicklink icon is deleted correctly.

Ah… looking again it is just the Start Menu icon that is left behind. If I refresh the desktop with < f5 > the icon goes away. (Yeah - ignore this one. Likely just the old senile PC I am testing with)

Uninstall does not ask to remove settings
May be worth noting that on Win10 I was asked about removing my settings. I was not asked this on Vista. Could this be why the icons got left behind?

All other application files correctly removed. nothing in %PROGRAMFILES% and nothing in %APPDATA% but I assume that is also due to not starting the app.

Install test for v2.0.4
This behaves exactly the same as v2.0.5. Will not start the app and gives similar error as reported above. Only this time it is complaining about the Python36.dll

In both cases I check that the Python36.dll is sitting in the correct folder next to picard.exe

Sorry, I had assumed these links would open the correct tab. If you click on “Artifacts” there should be a link to an installer download. The filename is always the same, but they are built with different Python versions.

Just quickly replying from mobile right now, so I cannot check in detail. But if you need more details I can check this later.

1 Like

Got it. Will just pick the v3.5 version as the failed v2.0.4 install I assume means we covered the Python 3.6 test.

And same result. Same error message but now it complains about Python35.

I am about to disappear for an hour or so. But this Vista PC will be fully available to you in any way you like. From me uploading log files through to you having a direct remote connection to it. It is an ex-customer PC about to be wiped so it can hang around for this debugging.

1 Like

Thanks a lot for the offer, but I think we should take this as the information “doesn’t run on Vista”. Given that Vista is not even listed among the supported configurations for Qt 5.11, is not supported by MS anymore, and the fact that Vista itself, especially in the 64bit version, wasn’t tremendously popular anyway I really don’t want to invest too much of my (or your) time debugging this.

I am currently testing with a fresh install of Win 7, let’s see how this goes :smiley:

3 Likes

I agree with you. So few people will be using Vista now. I’ve migrated a few people onto new PCs in the last month after Firefox abandoned the OS.

Please can the “supported OS” list be updated. If someone is running Vista then should be pointed at Picard v1.4.2 as a solution.

Later in the day I’ll find some more victims to install Picard onto. I have a very messy Win7 here that will probably be next.

2 Likes

I think that implies having a “Supported OS” list first :smiley:

1 Like

Some results from my own testing on Windows 7: The current Picard 2.0.4 and the development version behave the same. They both run on Windows 7, but on a fresh install I first had to install Service Pack 1 and some following “important” updates until it would start. So probably we should just recommend Windows 7 + Service Pack 2 as the minimum to be on the save side.

1 Like

Agree. I’ll refer you to the Microsoft Supported list. Lifecycle FAQ - Windows | Microsoft Learn

They don’t support unpatched Win7 either, but there is no SP2. Win7 SP1 ran out of official mainstream support at the end of 2015. It will be abandoned fully at the end of 2020.

I would suggest write “A fully patched Windows 7 SP1 required”. Then leave it to the user if they want to experiment with missing patches.

2 Likes

Dear ALL,

  • “updating” latest Picart to 2.0.5.dev1 version on W10PRO/64 - Intel Core 2 / 4GB, install himself to Program Files(x86). So, is it the DEV version 64 bit ?
  • Daily functions, Load, Cluster, LookUp, Scan, Save, Remove works well - as in latest version
  • no plugin activated, just changed litlebit the naming convection …
  • still not clear how plugins fuctioning . eg. when they start / run ?
    Really nice app :slight_smile:
    I’m using it for clean up and organize my music data base for use with volumio …

Regards,

2 Likes

Testing feedback

Win10 PC with Picard v1.4.2 already installed. Running either 2.0.4 or 2.0.5dev1 installers. Error in the installation script as it attempts to install into the 32-bit app folder instead of the 64-bit app folder.

Windows does have some rules to follow. If an old install of v1.4.2 is found then do not install the 64-bit app to C:\Progam Files (x86)\

Or look for the (x86) in the file name and install elsewhere.

Yeah, I can see some logic of reinstalling to the same place for those people who do already use alternate install folders. But isn’t that leading to problems anyway? I assume this 64-bit app would not want to mix with those 32-bit files, so trigger the uninstaller of the installed app before installing the fresh one. Wouldn’t that also avoid some of the crashing caused by out of date plugins?

Testing feedback - Positive note

That is a HUGE improvement as to how artwork is handled. I’m a greedy ID-10T who downloads all available art. I don’t embed, just drop loose files.

In v1.4.2 Picard would often choke and stall on large artwork downloads. In v2.0.5dev1 it was comically fast.

Here is an evil one to test with. This includes 288MB of artwork! Heaps of unedited 25MB PNG files! The old v1.4.2 just gave up on this after seeing the first 25MB file. I left it running overnight and nothing… but 2.0.5 worked well.

Testing feedback - Bug Found

In my options I have the option ticked to “Preserve timestamps of tagged files”. I just tagged a group of FLAC files and found that all the time stamps have been changed.

Testing deeper and I find when the files are on the same Win10 PC as Picard then the timestamps are preserved. When the files are on a Win7 PC being accessed over the network via SMB then the file stamps are not preserved.

Yuk - just tested back on v1.4.2 and it turns out that was also knackering time stamps when working over the network. So this bug is not new.

2 Likes