I know I could change the path name to a safe character set ("Bielsko-Biala") but would like to avoid it.
The same error is when non-standard chars are in -c or -S option value.
You may use non-standard characters in paths/projects (that is DCP-o-matic's responsibility) , but not in any files or names within the DCP. They need to be constrained to a very limited character set. I have seen servers crash hard (system software needed to be reinstalled) with non-standard chars in DCP files/file names.
Last edited by Carsten on Wed May 11, 2022 11:07 am, edited 1 time in total.
I think it's a good idea to constrain everything a server get's to see I have seen weird things when non-standard chars had been used on ingest material. And while we have control about what DCP-o-matic writes, we have no control at all about server software.
Judging by experience, servers and media blocks may be gravely affected.
I haven't been witness of software needed to be reinstalled, but I have been witness of media block (IMB to be precise) needing to reboot the projector (IMBs power supply) twice, and the server being incapacitated due to disconnection to the media block. An "i" with an acute accent (í) being the culprit.
So, from then on, I dot all the "i"s and I only horizontally cross all the "t"s...
Now, for a KDM, if the problem is just on the filename, I would rename it before. But why should one have to check? Isn't better safe than sorry?
Good points Carsten and Ioannis - thanks. I'll leave the code in to reduce KDM filenames to a very small set of ASCII characters.
@jakub.krolikowski the next version 2.16.11 should fix the transliteration of filenames so that białystok biała becomes bialystok biala instead of biaBystok_biaBa.
I have seen weird things when non-standard chars had been used on ingest material. And while we have control about what DCP-o-matic writes, we have no control at all about server software.