P: Issue in text filter Caption Ends With

Kirby, this bug was first reported over five years ago and acknowledged by Adobe two years ago.  Let's hope the recent refiling of the bug report spurs a fix!

In the merged thread, Rikk Flohr, Company Admin, wrote:

I am able to duplicate this behavior. A bug is filed. 

In the merged thread, kirbykrieger wrote:

*kirbykrieger MemberThis bug remains in Lightroom CC 2015.9.

Please see thread I started on Lightroomforums.net.  Confirmed by two top users.

The Smart Collection Rule:

{Keywords}{ends with}{string}

fails to match Photos with keywords that end with "xstring" where "x" is the same letter as the first letter in "string".

I am emigrating large databases from Aperture to Lightroom (happily, until this tripped me) that use sets of Smart Collections based on sets of keywords that carry one of a small often-used group of suffixes and prefixes.  This bug breaks my system.  Other than reporting it here, is there anything I can do to help resolve it?

(I have edited dozens of Smart Collections to use "tring" instead of "string" where the first letter of "string" follows an identical letter.  This short-term solution works for now, but it introduces an inconsistency that will cause bigger problems down the road, and is cumbersome to implement.)

In Lightroom 5.2 64-bit when I set up smart collections based on "Keyword ends with" I notice that some pictures are not being selected where the keyword has a double letter, e.g. "East Sutton" is not matched when I select "Keyword ends with 'ton'" whereas it is found if I change the keyword to "East Suton". A possible bug or a misunderstanding on my part?

This bug still exists in LR 6.0.1 / OS X 10.10.3.

Thanks John. Not comprehensive, like AnyFilter, but may do for some cases...

That's very simple!

TextMeta offers a solution for searching a limited subset of metadata with spaces (e.g. file name, folder path, title, caption, ...) by replacing spaces with something else (in a shadow-copy available as custom metadata). Such massaged metadata is available for library filters and/or smart collections.

For example, if you specify spaces to be replaced by underscore, then

'THE END' would be stored as 'THE_END', which even by Lightroom native handling, starts with 'THE' and ends with 'END'.

To be clear: Lr divides metadata up into words (with space as delimiter) *BEFORE* testing for matches. It then tests each word independently of the rest.

So 'THE END' starts with 'END' and ends with 'THE'.

Note: due to bug, the aformentioned can not be found at all when using "contains words" (see "big mallard ducks" bug).

This is one of my pet peeves in Lightroom:

Spaces are allowed *as data* but are treated *as separator*.

It's just wrong...

In the mean time, consider using AnyFilter
(or SpaceUrchin, if you're weird, like me)
if you need to search for metadata with spaces in it.

Rob

To be clear: Lr divides metadata up into words (with space as delimiter) *BEFORE* testing for matches. It then tests each word independently of the rest.

So 'THE END' starts with 'END' and ends with 'THE'.

Note: due to bug, the aformentioned can not be found at all when using "contains words" (see "big mallard ducks" bug).

This is one of my pet peeves in Lightroom:

Spaces are allowed *as data* but are treated *as separator*.

It's just wrong...

In the mean time, consider using AnyFilter
(or SpaceUrchin, if you're weird, like me)
if you need to search for metadata with spaces in it.

Rob