# \[2.03.14\]\[Windows zh-CN\] Live Update corrupts Chinese asset and project paths when creating compressed hotswap FSBs **URL:** \ **Category:** FMOD Studio\ **Tags:** unity\ **Created:** [July 14, 2026, 1:10pm UTC](https://qa.fmod.com/t/2-03-14-windows-zh-cn-live-update-corrupts-chinese-asset-and-project-paths-when-creating-compressed-hotswap-fsbs/24396 "2026-07-14T13:10:29Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![mksadk](https://avatars.discourse-cdn.com/v4/letter/m/ecc23a/32.png) [@mksadk](https://qa.fmod.com/u/mksadk)\ **Post date:** [July 14, 2026, 1:10pm UTC](https://qa.fmod.com/t/2-03-14-windows-zh-cn-live-update-corrupts-chinese-asset-and-project-paths-when-creating-compressed-hotswap-fsbs/24396/1 "2026-07-14T13:10:29Z")
[Generated by Codex, GPT 5.6 Sol] Hello FMOD team, I believe I have found a deterministic text-encoding regression in FMOD Studio 2.03’s compressed-asset Live Update path on Windows. When either the FMOD project path or a newly imported audio asset name contains Chinese characters, Live Update successfully synchronizes event structure, volume, pitch, and hotswap banks, but the newly added audio asset cannot be played. ## Environment - FMOD Studio: 2.03.14, build 164239 - FMOD for Unity integration: 2.03.14 - FMOD runtime: 2.03.14 - Unity: 2022.3.42f1c1 - Windows 11 Pro x64: 10.0.26200 - Windows system locale: zh-CN - Windows ANSI/OEM code page: 936 - Connected FMOD platform: Desktop - The FMOD project was originally created with 2.02 and later upgraded to 2.03. - We did not encounter this behavior with the previous 2.02 workflow. The issue is reproducible locally. ## Reproduction A: Chinese audio asset name 1. Place the FMOD project under an ASCII-only path, for example: 2. Start the Unity project and connect FMOD Studio through Live Update. 3. Import an audio file from the Windows desktop named: 4. Add it to an event while Live Update is connected. 5. Trigger the event in the connected game. ## Expected result The new audio asset should be synchronized through Live Update and played by the connected game. ## Actual result The import itself succeeds: - The file under the FMOD project’s `Assets` directory retains the correct Chinese name. - The saved and unsaved `AudioFile` metadata XML contains the correct UTF-8 value: ```xml 中文名称测试素材2.wav ``` However, when FMOD creates the compressed hotswap FSB, the filename becomes corrupted. Intended cache filename: ```plaintext Desktop中文名称测试素材2.fsb ``` Actual filename created on NTFS: ```plaintext Desktop�������Ʋ����ز�2.fsb ``` No file with the intended Chinese name is created. Approximately 32 seconds later, `ProfileRemoteFile` attempts to open the correctly named path and fails with error code 18: ```plaintext [Runtime] fmod_profile_remotefile.cpp(371), ProfileRemoteFile::fileOpenProcess(): File 'D://Music/FMOD Project/.cache/fsbcache/Desktop中文名称测试素材2.fsb' could not be opened for remote access (error code 18) ``` The same failure occurs again each time the event is triggered. ## Filesystem timeline A filesystem watcher captured the following sequence: ```plaintext 20:34:15 Created Desktop\中文名称测试素材2.wav 20:34:19 Created FMOD Project\Assets\中文名称测试素材2.wav 20:34:19 Created Metadata\AudioFile\{GUID}.xml 20:34:20 Created .cache\fsbcache\Desktop�������Ʋ����ز�2.fsb 20:34:52 Runtime attempted to open Desktop中文名称测试素材2.fsb 20:34:52 Remote open failed with error code 18 ``` ## Encoding evidence The corruption is deterministic. The intended filename encoded using Windows CP936/GBK produces these bytes: ```plaintext 44 65 73 6B 74 6F 70 D6 D0 CE C4 C3 FB B3 C6 B2 E2 CA D4 CB D8 B2 C4 32 2E 66 73 62 ``` If those CP936 bytes are incorrectly decoded as UTF-8, the result is: ```plaintext Desktop�������Ʋ����ز�2.fsb ``` This exactly matches the filename created by FMOD Studio, character for character. This suggests that a Live Update path may be converted from Unicode to the Windows local code page and then interpreted as UTF-8. This is an inference based on the captured filenames and byte-level comparison. ## Reproduction B: Chinese FMOD project directory The issue also occurs with an ASCII-only audio asset when the FMOD project itself is under a Chinese directory: ```plaintext D:\FMODTest\音乐\FMOD Project ``` In this case, `ProfileRemoteFile::fileOpenProcess()` fails to open an ASCII-named FSB below the Chinese project directory with error code 18. Renaming only the parent directory from: ```plaintext 音乐 ``` to: ```plaintext Music ``` makes Live Update work again for ASCII-named assets. Chinese asset names still fail even under the ASCII project path. ## Additional observations - Live Update remains connected. - Event metadata and hotswap `.bank` files are transferred successfully. - Volume, pitch, timeline, and event-structure changes are synchronized. - Only the compressed audio asset `.fsb` fails. - FMOD Studio 2.03 added support for sending compressed assets through Live Update; previous versions sent uncompressed WAV assets: [https://www.fmod.com/docs/2.03/studio/welcome-to-fmod-studio-new-in-203.html](https://www.fmod.com/docs/2.03/studio/welcome-to-fmod-studio-new-in-203.html) Thank you. ---
**Author:** ![li\_fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/li_fmod/32/6577_2.png) [@li\_fmod](https://qa.fmod.com/u/li_fmod)\ **Post date:** [July 15, 2026, 2:33am UTC](https://qa.fmod.com/t/2-03-14-windows-zh-cn-live-update-corrupts-chinese-asset-and-project-paths-when-creating-compressed-hotswap-fsbs/24396/2 "2026-07-15T02:33:30Z")
Hi, Thank you for the detailed report and investigation! I was able to reproduce the issue on my end, although I didn’t observe a garbled filename being generated on my machine. In my testing, the corresponding hotswap `.fsb` file simply wasn’t created. However, the resulting failure appears to be the same. I also could not reproduce the issue on the latest 2.02 release. I have passed it on to our development team for further investigation. Thanks again for bringing this to our attention. ---
**Author:** ![mksadk](https://avatars.discourse-cdn.com/v4/letter/m/ecc23a/32.png) [@mksadk](https://qa.fmod.com/u/mksadk)\ **Post date:** [July 20, 2026, 11:11am UTC](https://qa.fmod.com/t/2-03-14-windows-zh-cn-live-update-corrupts-chinese-asset-and-project-paths-when-creating-compressed-hotswap-fsbs/24396/3 "2026-07-20T11:11:11Z")
[Generated by Codex, GPT 5.6 Sol] Additional finding / temporary workaround: I enabled the following Windows system setting: Settings \> Time & language \> Language & region > Administrative language settings > Change system locale > “Beta: Use Unicode UTF-8 for worldwide language support” After restarting Windows, I repeated the same test with FMOD Studio 2.03.14. The previous Live Update error no longer occurs when the FMOD project path and/or source audio filename contains Chinese characters. No FMOD project settings or asset names were changed. Before enabling this option, the Windows active code page was CP936/GBK. After enabling it, the active code page became UTF-8/65001. This result appears to further indicate that the affected Live Update compressed-asset path is passing through the Windows active code page incorrectly. When the active code page is CP936, the filename is corrupted before the hotswap FSB is opened. When the active code page is UTF-8, the same workflow succeeds. This can be used as a temporary workaround, but it is a system-wide Windows setting and may affect legacy applications that depend on the local ANSI code page, so it would still be preferable for FMOD to handle these paths explicitly as Unicode/UTF-8. I hope this additional information helps locate the incorrect encoding conversion. 🙂 ---
**Author:** ![li\_fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/li_fmod/32/6577_2.png) [@li\_fmod](https://qa.fmod.com/u/li_fmod)\ **Post date:** [July 20, 2026, 10:54pm UTC](https://qa.fmod.com/t/2-03-14-windows-zh-cn-live-update-corrupts-chinese-asset-and-project-paths-when-creating-compressed-hotswap-fsbs/24396/4 "2026-07-20T22:54:57Z")
Thanks for sharing the additional investigation and potential workarounds. We have already identified the issue, and our development team has a fix planned. I will update this thread once there’s more information I can share. Thanks again!