anyone else having V5 downloader problems too?

[fbungarz]

Maybe I am the only one, but I am sorry to say, since upgrading to version 5 using the downloader has been a pain

It downloads the images, renames them, but then almost regularly stalls when it gets to the stage of building thumbs and synchronizing images.
The only workaround is: kill the application, restart and then build thumbs manually, apply metadata that the downloader did not apply and synchronise - all manually

Also, with the renaming rule that I am using, the mirror to archive option basically does NOT work.
Even though I have "Apply Mirroring" set to use the file name of the downloaded file that does NOT happen. Instead the original file name straight from the camera is being used. This never worked in Version 4, it still doesn't work in version 5.

Finally: I generally keep three versions, the original JPG+NEF pairs plus a DNG. I wish it was possible to configure the downloader to create the DNG automatically without discarding the NEF. That used to work well way back in IDimager. I never got it to work in Photo Supreme. It is not a huge deal. After downloading the images, I filter the NEFs and call the DNG converter from within PSu, create the DNGs and then use verify folder for files to have PSU detect and version the files. This worked well in PSU 4. Now, in version 5 the DNGs are added to the catalog, but version detection no longer works flawless as part of the "verify routine" only some versions are detected. And, even if I subsequently run version detection on the files again the custom placeholder file mask for the NEF files no longer assigns the placeholder to these files. Only the custom file mask for the DNG placeholders is recognized.

This all worked without those glitches in version 4. No it no longer does. I could file this in Mantis, but I got the feeling these issues are all related. And filing them separately most likely won't help to get them resolved.

Incidentally: I was first very impressed how quickly the downloader now runs, but it now seems that to gain speed some of the nnecessary routines were sacrificed and now no longer work. I have seen people complaining here on the forum that the downloader takes too long. I'd rather wait a little longer and have it work well than not being able to rely on it doing the things I want.

Sorry for the rant. I do love Photo Supreme, but this was working really well in version 4 and it is very frustrating to see that it no longer does.

[Username]

I'm not really seeing this.
I emptied a couple of cards the other day and it felt as it usually do.
I copy two cards, one holding NEF and the other jpegs with PSU onto SMB mounted volume and then do the ordinary post processing ie version detection etc.
I don't use any DNGs in my workflow.
And I'm running PSU with postgres 12 on macOS 10.15.
Perhaps there's some differences between our systems here?

[Hert]

Incidentally: I was first very impressed how quickly the downloader now runs, but it now seems that to gain speed some of the nnecessary routines were sacrificed and now no longer work.

First of all, no compromises or sacrifices are made whatsoever for the gained performance. All performance increases are the result of applying smart and advanced techniques and optimize things to the bone. But of course, to do so it may have been that a bug snug in.

I did find the issue with mirror file name holding the original file name, even if the downloader is configured to hold the downloaded file name. That will is fixed for the next build.

I can not get the downloaded to stall here. You mentioned using the DNG conversion in the downloader. That is a script and maybe that is what is very slow. I'm not the author of that script and never use or test it either. My first suggestion is to remove the script from the downloader. You mention it isn't working, but then again you killed it, while it may have been working. A tip: if you think PSU is stalled then always check if there's processor usage to verify that. Don't rely on Windows' poor ghosting implementation, telling you that an application is stalled, even when it is working hard and the user just has to wait.
But the fact that you get the Windows ghosting screen, also makes me expect that that is due to that script.

[fbungarz]

Thanks for the quick reply.

I did find the issue with mirror file name holding the original file name, even if the downloader is configured to hold the downloaded file name. That will is fixed for the next build.

Great! Looking forward to that.

I can not get the downloaded to stall here. You mentioned using the DNG conversion in the downloader. That is a script and maybe that is what is very slow.

I am actually no longer using the DNG converter as part of the downloader. It did not keep the original file. So, instead I now download everything first, then filter the NEFs and convert them to DNGs, verify the folder.

If nobody else has these issues of the downloader stalling, I now wonder if this might be caused by not having compacted the thumbnail database for too long. I will have to move it off to a different drive, compact it there and see if this then works better...

[blinkit0]

Frank,

I am actually no longer using the DNG converter as part of the downloader.

What exactly is your workflow to convert to DNG if you are not using the Converter script?

I still use the script as part of the download, I mirror my CR2 files to a separate directory in. NAS, after files are downloaded and converted to DNG.

Juan

[fbungarz]

I simply select the NEFs after downloading, start the DNG convewrter from withing PSU, get all converted and then use the file detect to detect and version the files, thus keeping all three: JPG+NEF+DNG. The DNG converter script deletes the original NEF. I want to keep it.