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.
Just to confirm - all my tests are Windows to Windows. Tested the same with Win10 to Win7 and Win7 to Win7. All patched, legal, Pro editions. Files sitting on a simple Win7 Pro PC shared over SMB Workgroup using username\password control.
I noticed you said your tests are with “windows guests”. In the above scenarios the Desktop users have login to the PC with a username and password. Then a DIFFERENT username and password is used when connecting the the SMB share via the network.
Funny to see the timing issue mentioned. Doesn’t surprise me as I’ve been working with SMB since the Windows for Workgroup days and it has always been a bit of a loonatic.
Happy to test for anything specific as\when required.
(Quick check with MP3TAG and that behaves itself and timestamps stay as expected)
Not as if this is massively urgent as no one noticed before
True. SMB issues are difficult, because you have so many variations with different protocol versions and also the alternative Samba implementation. I kind of had hoped this issue is related to rather old systems. But since this is easily reproducible between Windows 10 systems that’s unfortunately not the case.
Hello @IvanDobsky. I’m still running Picard 1.4.2 on my Win 7’s and 10 machines. Both 64’s. Should I jump right in to v2.0.5dev1? Or should I go 2.0.4 first. I have read the several issues in this and other posts. I guess my additional questions are, do I have to delete 1.4.2 or will 2.0.5 overwrite everything and keep all my current settings and are there any other tips for this upgrade? Thanks!
I’d hold off for a couple of days and then go with the new 2.1 beta version that should be released this week. LOTS of fixes and some new functionality. @outsidecontext and @Zas have been busy!
I really don’t know. There was some discussion about possibly being able to specify the location of the configuration files / plugins directory on the command line when starting Picard, but I don’t know if that made it into this version or not.
EDIT - It looks like you can specify a different configuration file on the command line, but not sure about plugin location.
@Llama_lover as a personal opinion I am still running both versions on different PCs. Not seen any problems, and the speed at downloading images is a huge improvement. I’m waiting for that version 2.1 and then will then swap them all over.
I can’t remember what I did when I upgraded. Probably just took a copy of the settings “in case” and attempted to install on top. Though that leads to problems as you then get the 64-bit version installed in the 32-bit folder of C:\Program Files (x86). So probably better to uninstall the old one yourself first.
Note: I am not a big plugin user. So there may be some need to move them from the old 32-bit folder to the new folder. Now I think about it I may have had to re-select these due to my messing around with the installs.
Yes, 1.4.2 and 2.x.x aren’t totally compatible, mainly due to plugins (python3) and some configuration file changes.
If you want to test 2.1.0dev2, do a backup of your 1.4.2 config directory first.
That said, everyone is encouraged to upgrade to 2.x, support for 1.4.2 will be dropped very fast as we lack of human resources to maintain Python2 branch.
Adventurers can already give 2.1.0dev2 a try, see blog post.
@Zas nice little update there. v2.1.0.dev2 is comically fast compared with the old v1.4.2. All round snappier in operation. Especially on artwork. I like the clearer icons in the plugin section.
Only briefly kicked it around on a PC which had v2.0 on it. Seemed to install on top okay. Kicking some tagging around now.
Are you going to add the download link to that blog post? Or is it just for the detectives among us to find it
Looking at the plugins panel, I still find it very confusing. (looking at it from the standpoint of a novice)
Under the ‘Actions’ column, you would expect buttons/icons that perform an action.
But currently it is a strange mix between indicators and action buttons.
The green arrow and the ‘trash can’ perform a rather clear action.
But the grey checkbox is an indicator that is supposed to indicate that the plugin is active, but it is also an action button that disables the plugin.
When the plugin is disabled, it is indicated by a red cross, which in my opinion advertises that when pressing it, it will delete the plugin.
Who would suspect that a red delete icon activates something?
This has been discussed earlier including some specific proposals, so perhaps it is in the works, but I thought to bring it up again while there still is a great momentum in development.
edit:
And I notice that the ‘Preferred release types’ sliders behave rather erratic on my system. It’s almost impossible to drag them to a required value.
When you encounter sliders in a program, you expect them to slide.
But nothing slides here.
When you click and drag the big white slider button nothing happens at all.
(except from sometimes seeing the value changing with a value of 5)
So why the button?
Now I learned that you are supposed to probably just click on any area of the slider except on the button.
That’s not what you would expect.
And when you do click on a location distant from the button, it indeed seems to work, but you often see some overshoot happening before the value is set.
So all-in-all it’s an implementation of sliders I am not encountering very often.
Maybe erratic is the wrong term after you have learned and understood what you are supposed to do, but the looks do not match the inners.
I’m on Windows b.t.w., perhaps it’s different on other platforms?
I’m running windows 10 with latest MB-dev app. When I slide to the right, it increases the percent. Note: I can’t click the “box” and slide it. I have to just click the line where I want the box to move to.
