Maybe, it's not bug, then I cann't understand the concept.
Filtering found matches in any field, except %_path%. Also the * HAS {string} doesn't search the %_path% field. Filtering directories or drives the expressly %_path% HAS {string} have to be used.
Ok, I tryed a lot of placeholder. The above case is present at the path relative placeholders, that are: %_path%, %_folderpath%, %_directory%, %_parent_directory%. That means, we could think, it's conceptual, these fields have to be expressly named to filtering, otherwise not checked. But %_filename_ext% and %_filename% are checked, even if not shown. From my viewpoint this is not coherent (even if don't regard as bug).
Yes, it only filters tag fields and the filename.
What is the benefit of handling the parts in filename two different ways? What the meaning of, what for the *, if used the same way, if omited? May the * mean any field, if some of them excluded?
Moreover, what deliberation is over that, to filter not shown fields, even if them contents simply technical? e.g. some iTune-relative ID code-like strings, what are totaly meaningless for human reading.
How to decide if a field is technical or not (by the developers), and filtered or not, and must or not to specify expressly? e.g. duration, bitrate, ID version vs. iTune-codes, ISRC, and hence, filename vs. path.
OK, this is not bug. But also not useful...
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.