Comments: ** Comment from web user: oldspammer **
The original poster's message--re-read it. It said that he wanted specific actions be taken on a per show basis. Certain actions were for a specific show, while other actions were for other shows.
"What this is" is a preference to save a person's favorite show series, while for other "less liked" shows to discard them after permitting a certain period of time to watch shows that were not very favored that would rather be erased to free up disk space to record more favored shows. Ideally there would be a Microsoft Windows Explorer shell file property that would track how much of a show had already been watched via all media player programs so that file viewing could be resumed (on a per family member basis) and so that once all interested family members had viewed the entire show, the show would then have other actions taken against it--but Microsoft does not have this shell extension property yet (to my knowledge).
The question then becomes how to distinguish between one show's recordings and another and what specific actions to be taken once the show name is determined. To determine which show needs what actions taken, you use regex pattern matching to trigger a rule or action be taken--hence the long listing of the configuration file to specify each of these various actions on a per show name basis--recycle bin the file, recycle bin the folder, rename the file according to date time rules, move the file, move the folder, archive the file or folder, or other options that could be added in future that may be desired by a given user.
The regex config.txt file that I showed would ideally be made slightly more sophisticated by using an XML database to reduce, a little bit, any redundant fields--in this case I have designed a flat text file that has a repeated, but almost always unused field of the target file folder, that should be there only for one or two of the actions to be taken, but for the other many actions is unnecessary. However, to the user's benefit, a flat text database file is easier to create and maintain than an XML database would be. Also the processing of the flat text file is fairly simple for the programmer to use versus an XML database that needs a parser / scanner functional apparatus be used as well as a sophisticated in-memory object storage mechanism, etc--so, hence the simple text configuration file has good benefits for an initial try at this processing.