It sounds like there could be 2 kinds of “duplicate/history removal” going on.
- The file is in the history DB/log (i.e. same name from the recording DVR) and so it is skipped before processing further.
- The file is initially processed as far as resolving what the destination filename would be, and if that file is already there, the file will be skipped before processing further (or maybe after processing, I’m not sure on that detail - I hope MCEBuddy determines it can skip the file before doing the work of processing the file).
Scenario #1 depends on the input file having the same name as a previous recording (i.e. per history rules).
Scenario #2 depends on the output file having the same name as a previously processed recording (i.e. per destination filenaming rules).
For example, when I set my HDHR to “record everything” (i.e. the whole series - it’s not (yet?) as smart as to use the “new” flag in the guide data like my Tivo is), the tuner puts the start-time HHMM and end-time HHMM in the filename. In addtion to the channel it was recorded on, so each broadcast will end up in a separate file, regardless if the guide data indicates any episode information or other metadata.
Notably, almost all the shows on PBS sub-channels (CreateTV, I’m looking at you) have no episode information or even show IDs, so they always end up as one-offs in my “Specials” destination instead of into a TV series destination (with seasons and episodes). Whether they are different episodes or simply rebroadcasts of the same episode at a different time.
This is because for my “Specials” job profiles I have to include that “start time” in the output filename so that I can tell there are potentially mutliple episodes and duplicate episodes. Otherwise, if they all resolve to an output filename of “Showname-SE-RecordDate”, the first one processed will block the others and they’ll get removed from the job queue as a duplicate output file under Scenario #2.
For TV Shows, I don’t want that to happen, and I do want a “first recording wins” kind of processing. So my output filename for TV series (i.e. have an episode # in the metadata) only includes the “FirstAirDate”, and not the “RecordDate”.
Sports events are typically live, and only relevant to the date of the event, so their filename renaming rule has the “RecordDate” not the “FirstAirDate” since some guide data has the “FirstAirDate” set to the date the entire sports show started, e.g. Monday Night Football (not that that is accurate, I just use it as an example to recognize). Also, in a game series show, they don’t always setup the metadata of the Game # in the series as an “episode #”, e.g. Game 3 of the “World Series 2022” show might show up as “World Series 2022 Game 3” in the show title (making recording the whole series just a cluster fart in the DVR) or as Episode 3 in the “World Series 2022” show. Always including the “RecordDate” in the filename for Sports shows solves that problem, no matter what the guide data / metadata says.
I hope that helps understand what MCEBuddy might be doing in your case. You can also search the forums for my posts with my file renaming rules that send each type of show (TV, Movie, Sports, and “Other/everything else”) to different places and have different output filename rules that play nice with my Plex setup.
The problem shows are the PBS shows that end up in my Specials folder and I have to manually de-dupe them and move them to where they go in the proper TV Show and rename them to the proper season and episode. I usually keep the record time as a suffix and then de-dupe keeping the best one MCEBuddy processed.
