Error parsing config file when using parsePattern on Windows about autotag

[jamerst]

Are you setting the value of parsePattern manually or using the --set-default option?

If you're doing it manually any backslashes in the regex will have to be escaped as double backslashes, otherwise the JSON isn't valid.

In my testing the --set-default option automatically escapes the backslashes.

[livinggreener]

I was setting parsePattern manually within conf.json using a text editor. I'd escaped the backslashes that repent the Windows directory delimiters but not any that need to be interpreted as RegEx special characters. For the directory structure of:
"\Series-name\Season #\Episode #.mkv"
I was using the pattern:
".*\(?.+)\Season (?\d+)\Episode (?\d+)"

I tried --set-default to see how it wrote my above pattern to the JSON and see now that even the special character backslash needs to be escaped. So, \d must instead be \\d. However, I was surprised to see that any Windows directory delimiters need to be triple-escaped. I was theorizing I might see them be double escaped based on your comment, but not triple escaped. So, \\ must instead be written \\\\. I was also even more surprised to see that a number of other characters were rewritten into their C/C++/Java Unicode versions:
< becomes \u003C
> ... \u003E
+ ... \u002B
So, this is the full pattern that was written to the JSON by using --set-default and --pattern .*\\(?<SeriesName>.+)\\Season (?<Season>\d+)\\Episode (?<Episode>\d+) at the command line:
.*\\\\(?\u003CSeriesName\u003E.\u002B)\\\\Season (?\u003CSeason\u003E\\d\u002B)\\\\Episode (?\u003CEpisode\u003E\\d\u002B)

Now the RegEx pattern within the JSON works without error. It seems the best way to edit the JSON parsePattern field - at least on a Windows machine - is via CLI with --pattern and --set-default rather than manually with a text editor.

[jamerst]

The angle brackets also being escaped/encoded has been fixed in v3.1.2. There's a "feature" in System.Text.Json that escapes some characters to prevent XSS attacks by default.

Obviously that feature is useless in this application, so it's now disabled.