slow tagging

[VGER]

Hi,

I've mentioned this problem earlier (no response so far), but before I thought it was a peculiarity about my hardware setup (images on network drive.) Now I'm not so sure anymore:

When going through a directory in either "contact sheet" or "preview" mode, going back and forth between images is reasonably (within the expectation for my hardware) fast. However, tagging is not.

When I use "t" to tag a photo, PM freezes for a time. The time is less than a second, but it totally breaks workflow because you always "wait for PM" - did my keystroke take? Do I need to press again (which unfortunatly un-tags the image again, which is the worst possible scenario?)

When configured to "advance on tag", there is a notable difference between "advance" (arrow key) and "tag with advance" ("t" key). This is most irritating.

This behaviour is not only notable on my desktop, but also on my laptop (older dual-core with Windows 7 and SSD.) Here the images are on the local SSD and there shouldn't be any delay, even if a XMP has to be written.

My PM version is v5.0 build 15821.

Is this normal behaviour?

Regards

[Kirk Baker]

I've mentioned this problem earlier (no response so far), but before I thought it was a peculiarity about my hardware setup (images on network drive.) Now I'm not so sure anymore:

I believe you made a feature request earlier.  I often don't reply to feature requests unless I need some sort of clarification.

When going through a directory in either "contact sheet" or "preview" mode, going back and forth between images is reasonably (within the expectation for my hardware) fast. However, tagging is not.

When I use "t" to tag a photo, PM freezes for a time. The time is less than a second, but it totally breaks workflow because you always "wait for PM" - did my keystroke take? Do I need to press again (which unfortunatly un-tags the image again, which is the worst possible scenario?)

When configured to "advance on tag", there is a notable difference between "advance" (arrow key) and "tag with advance" ("t" key). This is most irritating.

This behaviour is not only notable on my desktop, but also on my laptop (older dual-core with Windows 7 and SSD.) Here the images are on the local SSD and there shouldn't be any delay, even if a XMP has to be written.

My PM version is v5.0 build 15821.

Is this normal behaviour?

Quite possibly, yes.  What kind of files are you tagging?  Have they had metadata applied to them prior to your tag being set?  If you un-tag the image that tagged slowly, does it un-tag quickly?

Can you post your IPTC/XMP settings here?  Use the 'Attachments and other options' link when you're composing your reply to this message and there you'll be able to upload your JPEG format screenshot.

Thanks,

-Kirk

[VGER]

I believe you made a feature request earlier.  I often don't reply to feature requests unless I need some sort of clarification.

Why, you do have some memory! :-)

Yes, that was it. Back then I thought the problem was the network folder and the inherent latency, thus my suggestion for an additional caching mechanism. Now I feel the issue might be slightly different.

What kind of files are you tagging?

Raws from a Canon DSLR (*.cr2). No corresponding JPEGs.

Have they had metadata applied to them prior to your tag being set?

No, they are straight out-of-camera, ingested from the card, and no import-handling has been applied.

If you un-tag the image that tagged slowly, does it un-tag quickly?

No, usually not. Repeated tag/untag is just as slow.

But if I leave the image just sitting there (like now while writing this entry on my desktop with my laptop next to me for tryouts) at one point tagging/untagging suddenly becomes instantanious. It's like tagging a cached image is different from tagging an uncached one.

Can you post your IPTC/XMP settings here?

Sure, attached.

Regards

[attachment deleted by admin]

[Kirk Baker]

OK, your settings look fine and you're using an XMP sidecar workflow.  Updating a lone XMP sidecar file should be very fast.  Could you please upload PM's log file?  Go to the Help menu and choose "Reveal Support Data..." and then attach the file that is produced (you'll see the zip file selected in a Windows Explorer window).

Thanks,

-Kirk

[VGER]

Could you please upload PM's log file?  Go to the Help menu and choose "Reveal Support Data..." and then attach the file that is produced (you'll see the zip file selected in a Windows Explorer window).

Can I send you the file some other way? I feel uncomfortable attaching it to a public post, and apparently I can't attach it to a PM.

Regards

[Kirk Baker]

I got your log.  For some reason the cache cannot create files when it needs to create them.  This is likely causing your delay.  Please empty your Disk Cache (Preferences->Caching) and check the permissions of the folders in this path:

C:\Users\[removed]\AppData\Roaming\Camera Bits, Inc\Photo Mechanic\cache

Or you can set a new path for your cache at a location more suitable (Preferences->Caching)

-Kirk

[VGER]

There is indeed something fishy here:

After "clear cache", the folder /cache wasn't empty at all. Under the two top level entries (preview and thumb) there were a lot of subdirectories. What's curious is that their security ACL only shows a single user, who is granted no permissions, and who is certainly not the one running PM.

Can I delete the whole folder /cache and have it created anew, or do I have to "relocate" the cache directory from within PM first?

[Kirk Baker]

There is indeed something fishy here:

After "clear cache", the folder /cache wasn't empty at all. Under the two top level entries (preview and thumb) there were a lot of subdirectories. What's curious is that their security ACL only shows a single user, who is granted no permissions, and who is certainly not the one running PM.

Can I delete the whole folder /cache and have it created anew, or do I have to "relocate" the cache directory from within PM first?

You should be able to delete the cache folder entirely and PM will attempt to re-create its cache folders.

-Kirk

[VGER]

I don't understand this:

1.) I deleted the folder /cache. On the next start, PM was very fast, even at startup, and there was no delay on tagging.

2.) The /cache directory and its subfolders were recreated. But they still are created unter a totally different username. They user that is the only one who has privileges on those folders hasn't even logged into the machine once in the machine's lifetime. It is a domain user that does not even have interactive-login privileges.

Can you make anything from this?


Edit:

I specified a different path in PM's cache dialog. The new cache is created in the desired location, but again for the different user. My user doesn't even have privileges to access the cache folders, I have to edit the ACLs each time I want to delete the folder tree.


Edit 2:

The problems start with the directories "preview" and "thumb". Above this level the permissions are correct, below (and these two themselves) they are not. Which is curious in itself, since the directory "cache" is also auto-created by PM. Why should the two be different?


Edit 3:

I checked the directories on my desktop: Exact same story, same (incorrect) user permissions starting at the same directory level.

[Kirk Baker]

Photo Mechanic uses the Windows function CreateDirectory() to create the directories for the cache folders.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363855%28v=vs.85%29.aspx

PM passes NULL for the security descriptor which has the following effect:

If lpSecurityAttributes is NULL, the directory gets a default security descriptor. The ACLs in the default security descriptor for a directory are inherited from its parent directory.

So the directories that are created should have the same ACLs as the parent of the "cache" folder.

I don't know why you'd be getting the behavior you're seeing given the description of the function provided by the OS.

-Kirk

[VGER]

Photo Mechanic uses the Windows function CreateDirectory() to create the directories for the cache folders.[...]
PM passes NULL for the security descriptor which has the following effect:

In the comments below this exception was noted:

Note: CreateDirectory and CreateDirectoryEx will bypass the security of the parent folder if SeRestorePrivilege is enabled.

Does this mean anything to you?

So the directories that are created should have the same ACLs as the parent of the "cache" folder.

Well, the directories "preview" and "thumb" do. The directories below them, e.g. "00", "0a" and so on do not.

Are the directories "preview"/"thumb" created explicitly (with a separate call) or implicitly (by creating the first directory below them?) I read somewhere that there might be problems if you created "intermediate" directories in the implicit way (e.g. creating "\first\second" instead of create "first", then create "first\second".) Maybe the "second" directory doesn't get any inheritance because its parent "first" doesn't exist prior to the create instruction.

Next thing for me to try is to let PM create the directory tree, then modify all permissions of the whole tree, and look out how new subfolders are created thereafter.

Regards

[Hayo Baan]

Hmm, interesting issue you have . What happens if you create a directory yourself in one of those places? Try it both from the explorer and the command line.

Also, check the acls of the application itself. Who is the owner/creator of that?

[VGER]

What happens if you create a directory yourself in one of those places? Try it both from the explorer and the command line.

All manually created files and directories are fine (do inherit parent ACL.)

Also, check the acls of the application itself. Who is the owner/creator of that?

That I already did: ProcessMonitor (Sysinternals tool) shows that PM is running unter the correct user (my "work" user.)

Next one:

Go to folder "cache", right-click, settings, security and so on, tag "replace ACL of lower objects" (something like that), hit OK. Now all dirs, e.g. "cache/preview/00" have the "normal" ACL.

Start PM, quit PM (do nothing else in PM.)

Now all dirs "cache/preview/*", among them the said "cache/preview/00", have the "wrong" ACL.


Edit:

Even better: The testdir that I created before as "cache/preview/test.dir" also suddenly has the "wrong" permissions set after PM executed once.


Regards

[Hayo Baan]

Hmm, weird 

No idea what could be going on here. Afaik, no one else has reported this problem so it must be something specific on your system. Have you already tried reinstalling pm? Also what happens if you remove or rename that other user?

[VGER]

Hmm, weird 

Yes, I do believe this is one of the more interesting ones! :-)

No idea what could be going on here. Afaik, no one else has reported this problem so it must be something specific on your system.

The machine - I don't think so, because it behaves exactly the same on two machines.

The system - well. I'm in a domain environment with a specific userset, group policy and so on, which of course replicates to each machine. But I can't even imagine a setting that would produce these effects on the clients... And, I've never seen anything like it before either, and I'm sure another program would have shown similar behaviour if it was the system's problem.

Have you already tried reinstalling pm?

Well, sort of: On the first machine (desktop) I had used a trial version of PM before. It expired, was uninstalled and hadn't been used since until I installed a current version of PM again and entered the license. On the second machine (laptop) PM was a fresh install.

Also what happens if you remove or rename that other user?

I can't do that. This user has multiple purposes (even if not necessarily on that machine) and I can't just change it.

Regards