Service won't start when seriesMap uses umlauts

[Christoph21x]

Dear Chris, dear All

Using seriesMapping I found a minor issue (but may be tricky to find it): If you use a seriesMap with an umlaut, it:

• won't process it and launch an error (let's say: kind of "correct", but not "good")
• if you end the service or restart it, the service won't start and launches an error message "access denied"

I think I tried it with that one:

• seriesMap schedulesDirectName="regex=Der Trödeltrupp*" tvdbComName="" ignore="true"

What I didn't try, was, how it would behave in a NON-regex expression like

• seriesMap schedulesDirectName="Der Trödeltrupp" tvdbComName="" ignore="true"

Greetz - Chris

[Malyngo]

Can you check if the config file is saved as UTF-8? If I am not mistaken, this should not really be a problem to have umlauts in a regex.

(When using notepad/editor on Windows, you can check this by using "Save as" and then left of the save button there is a dropbox "encoding". This should be UTF-8, not ANSI)

[Christoph21x]

Correct: format is ANSI. Re-Checked it with the following results:

1. ANSI: umlaut in a seriesMap leads to the above described error
2. UTF-8: error doesn't occur. Not yet checked, if the expressions really works. Currently I have only "ignore entries" with umlauts. I'll search for a fitting entry (series) and will launch test schedule after adding the mapping.

I'll be back with information. In the meantime - how could we avoid this?

Greetz & (again) thanks, Malyngo - Chris

[Christoph21x]

Ok, managed to check it with a trick:

• had to find a series with an umlaut which is not "as is" in TheTVDB.
• which has either an episode name or s/e numbering
• Workaround: took one with an umlaut
• mapped it to another series by id to check if the map really works (and that it wouldn't just be a "hit by default")

With UTF-8: (seriesMap schedulesDirectName="regex=Köln 5.*" tvdbComName="id=254785") This maps "Köln 50667" to Lindenstrasse :D (needed a series with at least 540 entries in TheTVDB)

Result: it works without any issue - all entries of Köln 50667 are mapped to the (absolute numbered) Lindenstrasse equivalents.

So: this is really just a file encoding issue.

Greetz - Chris