Startup failure.

[e-setup]

When I startup makehuman from a clean installation, it works fine. But after the first run, means there're files generated by MH in a folder name "v1py3" in my document folder, it starts to fail, generating the follow error log. I'm using MH1.2 pre-release in windows 10 home, GBK encoding.

error: 'gbk' codec can't decode byte 0xa2 in position 1095: illegal multibyte sequence Traceback (most recent call last): File "makehuman.py", line 582, in main init_logging() File "makehuman.py", line 198, in init_logging import log File "./lib\log.py", line 49, in from core import G File "./lib\core.py", line 80, in G = Globals() File "./lib\core.py", line 58, in init self._preStartupConfigScan() File "./lib\core.py", line 67, in _preStartupConfigScan data = json.load(f) File "D:\obj\windows-release\37amd64_Release\msi_python\zip_amd64__init__.py", line 293, in load UnicodeDecodeError: 'gbk' codec can't decode byte 0xa2 in position 1095: illegal multibyte sequence

[Aranuvir]

I'm not sure but this could be really a problem we have to address. From the Python 3.8.2 documentation:

In text mode, if encoding is not specified the encoding used is platform dependent: locale.getpreferredencoding(False) is called to get the current locale encoding.

I thought it would default to utf-8 in the case encoding is not specified, or maybe there was a change in that behavior. We should consider to force encoding=utf-8 to all open() calls. Perhaps it fixes the issue. Setting the priority to urgent atm.

[Aranuvir]

I've created a a new branch _feature_fix_io_encoding, addressing the encoding problem and fixing a bunch of other problems. The plug-ins must be checked one by one ...

[e-setup]

I've done some test, problem solved.

[Aranuvir]

Thank you for your feedback. Could you give us some further information, what fixed your problem? It would be quite helpful for the project.

[e-setup]

Thank you for your feedback. Could you give us some further information, what fixed your problem? It would be quite helpful for the project.

I'd love to, but since I pull the newest code from the branch that you marked fixed, the problem I encountered before never show up again, I don't know what other information I can gather. I can post the startup log if it helps.

[Aranuvir]

Is it possible you have edited the settings file and (accidentally) saved it with an encoding other than utf-8? At least I was able to create this condition an make MakeHuman fail. My fix cannot prevent this problem because originally the application reads and writes all files on its own, assuming everything is utf-8 encoded.

A solution to the problem would be writing our own input and output functions (which was once suggest by Rob years ago). There is a module called chardet (https://pypi.org/project/chardet/), which is not a core python module but at least a main Debian package on Ubuntu (python3-chardet). This module can guess the encoding from a raw input.

I'll reopen the issue. That's probably something that merits a discussion. Though there is no quick solution and currently we can only document the problem and tell users to make sure that files that are edited outside MakeHuman are saved as utf-8 encoded.

[rwbaer]

Has the "fix exists" code long since been rolled into master, or if not, should it be? Just noticing that this has an "urgent tag" and yet it is still open.

[rwbaer]

Didn't mean to close, just to comment.

[Aranuvir]

It is/was open because the situation is still not save and I had in mind to replace the read functions. As long as we write and read the data only from inside MakeHuman with a balanced "encoding='utf-8'" everything will be fine. But as soon as you forget the encoding or data is edited outside MakeHuman without ensuring the usage of utf-8 the application will crash. (See also my "internal" post 2020-12-21). We can leave it closed, it was just a reminder.