[bug] Smart Bin using "matches any exact" isn't exact

I have a smart bin filter designed to sort footage by scene, with relevant footage tagged by scene number in a comma-separated list in the comments field. For example, a clip may be commented "2, 12, 21, 22" if it's relevant to those scene numbers.

Each scene then gets its own smart bin, which filters the comment field for the scene number using "matches any exact". This works reasonably well, except for single-digit scenes.

For example, my smart bin for scene 2 (which 'matches any exact' any clips with "2" in the comment field), returns clips that match scene 2 (as desired), but also clips that match scene 12 and scene 22 (not desired). It does *not* return clips that match scene 21, so it's not just finding any instance of "2". It seems to find any instance of "2" that is at the end of an item.

Is this a bug?
Or am I misunderstanding how "matches any exact" works? My assumption is that it's supposed to match any words that *exactly* match the value in the filter field, delimited by spaces (and perhaps commas). But that assumption doesn't appear to be correct.

I can filter out the unwanted scenes by adding a "matches none" condition for "12,22,32..."., but this has the unwanted side effect of excluding clips that are intended to appear in *both* scenes. For example, a clip that is commented "2, 12, 21, 22" will *not* show up in my smart bin for scene 2 because the exclude condition prevents it from appearing even though "2" is an exact match.

What I really want is for "matches any exact" to do what I expect it to do, which is to correctly match "2", but not "12" or "22".

Is there some combination of conditions I can use that will generate this result? Or do I have the right combination of filters but the filters aren't working correctly. In other words: Is this a bug?

PS: What is the difference between "contains" and "matches any"? I can't for the life of me figure out how those are distinct options, and they appear to return identical results.

PPS: How do I filter for a literal comma? In other words, how do I "match any" comment that contains "2," if the comma in the search term is interpreted as a delimiter? Is there an escape character?

I've never used 'matches any exact' Devon, so I've no experience of how it works. My usual approach is to use 'contains' and ensure that whatever I may be looking for can be identified by a unique string... so for your example "2, 12, 21, 22" my clip would be instead be commented ", 2, 12, 21, 22," (ie list begins and ends with commas), I could then search for 'contains' ', 2,' or ', 12,' or ', 22,' etc and be assured that my filter will only show those explicit occurrences.

I was toying with a similar hack. Thanks for identifying a format that actually works! I'll probably use that for the time being.

That said, if anyone else can chime in on making "matches any exact" work better, the hack has the disadvantage of being error-prone, especially in multi-user scenarios ... I can remember to use a hacked string that starts with ", " and ends with a trailing comma, but it's a bit much to expect new users to my project to just know this. I could really use a system where I just need to tell them to add the scene number to the comments field in a straightforward way and know that it will work without any formatting gotchas.

Again, not answering your question (and I hope someone does) but an obvious alternative to your dilemma would be to add the scene identifier as Keyword, rather than a Comment, then you can search by Keyword and all ought to be well for both you and those others in the team.

Yep, I thought about that as well. The disadvantage is mostly that I'm using keywords for other things, and don't want to clutter it with scene IDs (since the display box for keywords is pretty small). This may be the best option though.

We always use leading zeros for scene & shot numbering to avoid this issue.

Also a great idea. Can I assume from this that, generally speaking, "matches any exact" is not working as expected, and we are all using workarounds to deal with that? Can we officially tag this a bug?

I don't think we have any way to officially tag something as a bug.
We report things here and BMD decides what to put in their bug system and how to tag it.

Sorry, I didn't mean that kind of official ... what I meant was, nobody has stepped up to tell me that the feature is working "as intended", and several people have posted that they use workarounds. So, I think we can decide "officially" that we are looking at a bug, not a feature that we are misusing.

Totally agree.


Sent from my iPhone using Tapatalk

Works as I would expect when not using leading zeros.
If you don't wish to use leading zeros, you should use the "is" option, not "matches any exact" option.

Keep in mind that the search options are for ANY text, not just numbers. If you experiment you will see how the options work.

Can you explain the difference between contains and matches exact?


Sent from my iPhone using Tapatalk

Matches Exact is an exact match of the input string to any instance of the of that input string found in the same character location. In this case the filtered result finds any instance of the number 2 in the last position in the Scene field. e.g. 2, 12, 32, 172 etc

Contains will return any instance of the number 2 found in ANY character location. In this case the filtered result finds any instance of the number 2 in ANY position in the Scene field. e.g. 2, 12, 21, 273 etc

I'd think these would be documented in the manual but a search on "matches any exact" gives 0 hits. Likewise reading the doc on Smart Bins doesn't talk about the available predicates and how they work.

If Peter's description is correct, it sounds like "matches any exact" is delimiter-aware. Are commas the only delimiters?

Why the choice to have "matches any exact" for 2 match both ,2, and ,22,? That doesn't sound like exact to me. It sounds more like an "ends with" for list items.

You are guessing.

I tested all options. There are no delimiters in the metadata searches as ALL characters including spaces and commas are considered active metadata values. It's too complicated to explain. That option is primarily designed for clip name searches where one needs to filter by character strings due to the camera clip filename structure.

As I said earlier, it's been standard practice in the media industry to use leading zeros for many filename structures, reel numbers and just about anything else due to the way computers and software deal with character positions when sorting lists. It has plagued editors in nearly every editing application. Even back in the days of CMX tape editing all numerical entries needed leading zeros.

There is no bug, just misunderstanding of the options and what they are designed to do.
Matches Exact is the wrong choice for the OP's use case.

We are all guessing, since, as noted, the official documentation doesn't document this option.

"Is" is clearly not the correct choice here; that only works if the field I am searching contains *only* the scene I was looking for and no others (because it matches the whole string). I've tested this; it doesn't work.

And, "Matches any exact" *does* appear to use delimiters of some sort, since it will correctly match individual items in a comma (or space) separated list; the problem is that it is slightly too inclusive, and the rules for inclusion aren't clear. (Side note — the automated "Scene" smart bins *definitely* interpret commas as delimiters, since they have erroneously split up some of my scene names that include the string "1,000" and other scenes with commas, so the functionality to identify comma-separated lists definitely exists in Resolve).

Saying "It's too complicated to explain" just tells me *you* don't understand the logic. That's fine — I don't either. But that doesn't make it beyond explanation. It's a computer, it *only* works with logic, and that logic is possible to explain. We just don't know what that logic is.

Leading zeroes will probably work, but it suffers the same user-friendliness issue that all the other hacks do: It's error prone and non-intuitive for inexperienced users. I don't buy that there's no way to solve this because "that's how computers work". I've been dealing with computer code for a long time. I could write regex that would search by scene number without leading zeroes in a few minutes, and "matches any exact" could very well be implemented as a regex under the hood. The problem is that their logic is wrong (or, at the very least, undocumented), not that there is some magical "that's how computers work" limitation.

I never guess, I TEST. I DO understand it and use it when necessary. Good luck with your guessing.

I never guess, I TEST. I DO understand it and use it when necessary. Good luck with your guessing.

You'll notice that most of my posts included the direct results of tests. What we are guessing about, since it's not documented, is what the *intended* functionality is. In other words, we have no way of knowing if "matches any exact" is working as intended, or if there is a bug in its implementation. I would lean towards 'bug', given the lack of exactness in the matching that I demonstrated, through testing, in my earlier posts. Without documentation, all I can say for certain is that it doesn't work as *I* expect it to.

It's just simple computer logic. Nothing very difficult to understand, which is probably why there is no detailed explanation in the documentation.

From my testing the "matches any" and "matches any exact" options accept a list of comma-separated values, that's consistent with a standard programming paradigm that "any" means you match any in the provided list.

This means the comma won't be included in the search (this only applies to these two options). Usually you would be able to override that by escaping the comma but it's not clear if Resolve supports that, I don't think so. One option would be to use a semicolon in the metadata instead. Also, don't put spaces in the list unless you want to match on spaces.

I do think there is an unexpected behavior however, where "matches any exact" seems to match only from the end of the target field. Maybe it has a specific use case for matching frame numbers in image sequence filenames or something.

If they are using the Qt framework RegExp classes for these features, there might be issues since Resolve upgraded from Qt 5.4 to 5.15 a while back and that would include some breaking changes they might have had to address.