In Smart Collections, the rule "Capture Date is in the last n hours" doesn't work. It appears to behave as "Capture Date is today". Here's a screenshot:
Benjamin Warde • Adobe Employee, Dec 11, 2012Dec 11, 2012
Hi John,
What, you don't remember exactly what you were doing a year ago? Sheesh. 😉 Thanks for your comment. Given that this appears to be a little-used feature with an available substitute, I think we'll probably remove the misbehaving feature, rather than invest the time to work through the performance implications of continuously-updating search criteria.
I tried to to go into the details of this: The "is in the last n hours" rule seems to work as follows: The specified number of hours are subtracted from the current date and time. The resulting date (without time) A is compared to the capture date (again, without time) B of the photos and if B is greater than or equal to A, the photo appears in the smart collection.
I guess it's a simple programming error: The final comparison is done using dates without time (as it is done for the "is in the last n days/weeks/etc" rules), whereas it should have been compared as date plus time (possibly with 1-hour-"granularity" *)) for this particular rule.
*) with granularity I mean the following: If the current time is 16:20, the rule "is in the last 1 hours" shows photos captured from 15:00...16:20 and the rule "is in the last 2 hours" shows photos captured from 14:00...16:20 - same logic as in the "last n days" rule. It's purely a matter of taste whether this granularity or a comparison exact to the second is used.
I have reproduced this problem, and have entered the issue in our bug database. Interestingly, the behavior is different on Mac and Win (wrong on both though :-)).
Ben, I don't want to waste your precious time, but I'm very puzzled to repeatedly hear about different behaviour between the Mac and Win versions.
By now, I've seen many examples where code that could be shared between the Mac and Win versions because it is sufficiently detached from both hardware and OS, is not shared.
We often hear that the LR team is small, so why is shareable code not shared? It also questions the choice of a portable programming environment (Lua), does it not?
Sorry for this off-topic question, but I'm really curious about the reason behind the many differences in Mac vs Win code.
In the case of this particular bug, I was actually mistaken, as I realized shortly after writing my previous post. The behavior is the same on Mac and Win. Certainly there are sometimes bugs that occur just on one platform and not on the other, but not being an engineer, I'm not in a good position to speak to the extent of code sharing, or the pros and cons of Lua. :-)
Hi John, you still out there? An engineer has looked at this bug and has made the following comment:
"I advocate removing this criteria altogether. In my opinion, this feature is useless unless we retrofit search code to consistently autoupdate. Not sure if that's worth the effort since sort by date descending is a work around."
I'm inclined to agree, but I wanted to see what you thought. Is there a specific workflow you have in mind that wouldn't be satisfied by a workaround such as a "last day" smart collection, sorted by capture time descending?
I can't remember the details of what I was trying to do when I tripped over that. The suggested workaround would probably be adequate for what I do.
Perhaps in a tethered workflow, the photographer would want to have a smart collection showing the last 2 hours, to isolate exactly the photos in the most recent tethered session?
What, you don't remember exactly what you were doing a year ago? Sheesh. 😉 Thanks for your comment. Given that this appears to be a little-used feature with an available substitute, I think we'll probably remove the misbehaving feature, rather than invest the time to work through the performance implications of continuously-updating search criteria.