In August 2014, the Plex team changed VideoFiles.CleanNames to remove '264' from filenames. The Plex team considers 264 in a filename a format designator for x264 or H264.
Based on a BABS user's request for support, I tracked this down and reported the problem on GitHub. The list of formats includes specific entries for x264 and H264 formats. Apparently, some users have files named such that 264 is a format designator--I've never seen a case like this, so don't know if it's a bare 264 or something like 'h 264'. The Plex team's position is that the change does not break the official scanner, so they will not revert the change.
This change breaks any third-party scanner that expects VideoFiles.CleanNames to leave 264 in the name for any purpose. This is a likely issue for scanners that support absolute names. It may affect other scanners as well.
This issue creates one action item and one significant implication for third-party scanner developers.
Action: Fixing VideoFiles.CleanName
To resolve this for BABS, I copied the latest VideoFiles.py from GitHub and removed strings from the format list that I think are too aggressive--specifically stand-alone h and 264. BABS includes a regex that reliably detects variations of x264 and H264 and strips them if needed.
I also added a function (zzzCheckVersion()) that returns "BABS_VFAllow264" so I could be sure BABS is using the right module. I named the file BABS_VFAllow264.py, added it to the BABS package, and replace BABS's import VideoFiles call with import BABS_VFAllow264 as VideoFiles.
Feel free to borrow this file from BABS if you need to address this issue. I do not plan to update it with newer versions of VideoFiles.py unless Plex makes a breaking change to Plex Media Server that requires it--which will probably require substantial rewrites for all third-party scanner developers. If you borrow this file and package it with your scanner, please rename it prefixed with your scanner name so you do not break other third-party scanners users may have installed. Be sure to update the zzzCheckVersion() with your version's name.
I also added a log message in BABS that reports a BABS version number (hardcoded) and the result of the version function at the beginning of the scan. This means the scanner will fail if the function does not exist. I'd rather get a loud scanner failure in a small log file with a message that makes the problem obvious (couldn't find the test function) than a single episode failure buried in a large log file that conceals the real issue. This failure appears in the Plex scanner log, not the BABS log, so request both the Plex log and your scanner's log when users report issues.
Implication: Letter vs. Intent
The implication is that scanner developers should not trust the letter of the regexes in the official scanner code and should be cautious about using Plex code from the standard Plex modules.
At the time I wrote BABS (Plex 0.9 era), I used the official scanner's just_episode_regexes for absolute episode number detection. These regexes allow 3-digit episode numbers. The regex for the ".602." example prevented them from running for 3-digit numbers, but removing that regex fixed the problem. See the latest BABS documentation for a more detailed discussion of why I think this regex is a problem for more than absolute numbering (short version: Galaxy Express 999, Magic Kaito 1412, The 4400, and hundreds of other series with 3 or 4-digit numbers in the series name).
In October 2015, the official scanner includes the same 3-digit just_episode_regexes, but the change to VideoFiles.CleanNames and Plex's response make it clear--the regexes may allow 3-digit episode numbers, but the Plex team really means only 2-digits, except the Ep123 pattern. Note that, after removing the .602. regex described above, I found the Ep123 pattern is too aggressive. It identifies "Galaxy Express 999 ep01" as episode 999 and should have similar problems with "Figure 17 Ep01" (e 17) because it doesn't require a separator before the "e". See the BABS documentation for more detail and how I resolved this issue.
I've only forked VideoFiles.py, but in the near future, I may fork other Plex modules BABS uses to avoid another breaking change when Plex decides to change something in the standard modules. I need to determine which other modules might cause breaking changes in BABS. Other developers may wish to act with similar caution. If you do so, I suggest using the rename with prefix, version reporting function, and import as approach described above. It's simple, works, and allows users to have multiple third-party scanners if needed.