When I tried to import zip file with multiple impulse response files, “loading” windows don’t disappear and error is logged:
02/04 23:15:21 Error: Error in thread pool work item: System.NotSupportedException: Encoding 437 data could not be found. Make sure you have correct international codes
et assembly installed and enabled.
at System.Text.Encoding.GetEncoding (System.Int32 codepage) [0x0025f] in <a8460a77e67a430a8486a9751162e5f4>:0
at ICSharpCode.SharpZipLib.Zip.ZipConstants.ConvertToString (System.Byte[] data, System.Int32 count) [0x0000e] in <8e8fa28d216a43ec8dcb2258d1f7bf00>:0
at ICSharpCode.SharpZipLib.Zip.ZipConstants.ConvertToStringExt (System.Int32 flags, System.Byte[] data, System.Int32 count) [0x00020] in <8e8fa28d216a43ec8dcb2258d1f7
bf00>:0
at ICSharpCode.SharpZipLib.Zip.ZipFile.ReadEntries () [0x002b2] in <8e8fa28d216a43ec8dcb2258d1f7bf00>:0
at ICSharpCode.SharpZipLib.Zip.ZipFile..ctor (System.IO.Stream stream) [0x00066] in <8e8fa28d216a43ec8dcb2258d1f7bf00>:0
I don’t know it is caused by archiver (tried build in windows 10 and 7zip) or some strange problem with locales on RoonServer side (linux).
Your locale stuff on linux looks very clean/normal.
I’ll dig more into what we might have to do to support that zip file during the week. Also need to check how it behaves on mac/windows in case there are issues there.
Same issue here. I’ve unzipped and zipped using Windows 10, Mac, and Linux, each time getting the same issue:
02/05 21:51:43 Error: Error in thread pool work item: System.NotSupportedException: Encoding 850 data could not be found. Make sure you have correct international codeset assembly installed and enabled.
at System.Text.Encoding.GetEncoding (System.Int32 codepage) [0x0025f] in <a8460a77e67a430a8486a9751162e5f4>:0
at ICSharpCode.SharpZipLib.Zip.ZipConstants.ConvertToString (System.Byte[] data, System.Int32 count) [0x0000e] in <8e8fa28d216a43ec8dcb2258d1f7bf00>:0
at ICSharpCode.SharpZipLib.Zip.ZipConstants.ConvertToStringExt (System.Int32 flags, System.Byte[] data, System.Int32 count) [0x00020] in <8e8fa28d216a43ec8dcb2258d1f7bf00>:0
at ICSharpCode.SharpZipLib.Zip.ZipFile.ReadEntries () [0x002b2] in <8e8fa28d216a43ec8dcb2258d1f7bf00>:0
at ICSharpCode.SharpZipLib.Zip.ZipFile..ctor (System.IO.Stream stream) [0x00066] in <8e8fa28d216a43ec8dcb2258d1f7bf00>:0
@maciekb’s first zip file used a newer version of the .zip spec than (even the newest version of) our zip library supports. This is not getting fixed until we can get that support from upstream, but it doesn’t seem difficult to produce zip files without this issue with a little bit of fiddling.
When I re-zipped it on my mac, it fixed the first issue, but exposed the second problem, which relates to codepages stuff you guys noticed. This needs to be fixed on our builds–there are a couple of files missing from our package. That’s coming.
I also cleaned up the error handling so it shows an error instead of hanging at a spinner.