Display subfolders not included in the DB

[Mike]

I suggest an optional display "Toggle on/off" of subfolders that are not in the database. I only mean subfolders of included parent folders. We would be able to identify faster and more precisely whether there is a need for extra action or not. A subfolder would have no chance of being "lost" unnoticed.

Files of already included Folders and Subfolders are regularly updated if changes occur or new files are added.

This is not the same for not yet includes subfolders we deliberately/accidentally/automatically add from the outside. They kind of dont't exist. This is similar for excluded subfolder. We cannot see such folder in our tree, so they can be forgotten unintentionally.

For better control I suggest that the database keeps track of such subfolders and shows them when needed - not identical but similar to offline objects.The difference would be that iMatch would not check the non-database subfolders for additional content and would not save any details, only the folder name would be indexed.

In this way, potentials or necessities would not escape us.

[Mario]

I suggest an optional display "Toggle on/off" of subfolders that are not in the database.

IMatch has no information about folders not in the database and does not need it.

It is generally not a good idea to not manage folders recursively.
Don't mix managed and unmanaged assets  in the same folder hierarchy.
If you don't want to manage certain folders in your DAM, I recommend to move them into a separate folder hierarchy.

With the exception of the rare folder that needs to be excluded because it only contains meaningless settings and config data (one or two RAW processors insist insist on filling the file system with extra folders). That's what the exclusion option under Edit > Preferences > Indexing is designed for. For this rare use-case.

[Mike]

Don't mix managed and unmanaged assets  in the same folder hierarchy.

For technical reasons unrelated to iMatch, this proved to be a viable, time-saving, if not ideal, solution. But I'll try it differently, which has to be a compromise too... that's life ;-)