DECODING ERROR => on macOS 10.13.6

[alcomposer]

DECODING ERROR => is generated when upscayling image in macOS 10.13.6

[Kureii]

on windows 10 same bug

[aaronliu0130]

Note that if you switched "Batch Upscale" on and selected input from a folder with non-images in it, this isn't the same error. For that one see #53 (comment) .

Also, there was a prior issue that was fixed where the "output" had "8x" in the filename. Does that happen here?

[NayamAmarshe]

Send me the image for testing

[pollymow]

Same issue on Mac OS Mojave 10.14.6. According to the crash log, the reason for this is simple:

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Termination Reason: DYLD, [0x4] Symbol missing

Dyld Error Message:
Symbol not found: __ZNSt3__14__fs10filesystem10__absoluteERKNS1_4pathEPNS_10error_codeE
Referenced from: /Applications/Upscayl.app/Contents/Resources/bin/upscayl-realesrgan (which was built for Mac OS X 11.0)
Expected in: /usr/lib/libc++.1.dylib

So upscayl-realesrgan has to be built for earlier systems to ensure compatibility.

Thanks!

[NayamAmarshe]

1.5 was built on Big Sur I think and 1.5.5 on Monterey. In the next build, I'll try Mojave.

[pollymow]

Hi, one more thing: 1.5.0 also crashes on Mojave, same error as 1.5.5. The crash report says that the binary was also built for OS 11.0, which is BigSur. So maybe you compiled (one or both versions) on Monterey but the deployment target for both versions likely was BigSur (and not Monterey). Since quite a lot of electron apps work on Mojave and below (High Sierra etc.) I think the app should work an all higher OS versions even if the deployment target is HighSierra or Mojave, provided you can manage to build the binary for this kind of older Mac OS versions. Of course, you will have to try and watch the outcome, but I am quite confident that using an old OS version as the deployment target you would make lots of users happy and have less worries for yourself while supporting the latest versions of MacOS (at least on Intel Macs). I guess the lowest OS version to support should/could be HighSierra, below shouldn’t make too much sense. Mojave should make very much sense, since it is the last OS to support 32bit apps, so quite a few people still stick to it. I am happy to test things for you. I can do tests on HighSierra and Mojave and even Monterey (which I do not use but have installed) on MacPro or BigSur and Monterey on the iMac, both Intel (as well as Ubuntu Linux and others in emulation on the MacPro). Don’t have and won’t have an M1 machine though. Thanks a lot! Peter

…

Am 06.10.2022 um 12:40 schrieb NayamAmarshe ***@***.***>: 1.5 was built on Big Sur I think and 1.5.5 on Monterey. In the next build, I'll try Mojave. — Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADUJQQ2MAETC5PSB2P6TLDWB2UBTANCNFSM6AAAAAAQ23XIPE>. You are receiving this because you commented.

___ Peter Hartmann ________ ***@***.***

[aaronliu0130]

1. Catalina'd also make sense as it's 10.x, used the old UI, and didn't require you to have 16+16*2 gigs of storage to install.
2. Setting build targets for python is very much possible. However, just compiling it on an older system would be much easier if it's not so easily found. Note that the binary in question is another open source project written in python.

[pollymow]

1.5 was built on Big Sur I think and 1.5.5 on Monterey. In the next build, I'll try Mojave.

[###Somehow this previous reply to this post got lost somehow, so I repost it here###]

Great! My main production machine is an old MacPro (Early 2009 (!)) beefed up to run Mojave (and if I wanted also Monterey) - because I prefer to use my old workflows relying on several old 32bit-application which won’t run from Catalina (OS 10.15) on. So a built running on Mojave is very very welcome.

I can confirm, however, that on my late 2014 double-boot iMac (similarly beefed up using OpenCore Legacy Patcher)

(a) Upscayl 1.5.5 runs perfectly on Monterey - the results are excellent, the speed is quite good. (Did not test 1.5.0 on Monterey.)

(b) Both 1.5.0 AND 1.5.5 (!) work on BigSur, same quality, same speed.

What I am missing is
• a cancel button to stop a running conversion process (I accidentally chose an upscaled image as source, so the speed was veeery slow, so I’d have liked to bail out)
• I see a message, that a new version is being downloaded, but nobody knows how far the download is going and what eventually happens to this download. Dunno why, but auto updating never really seems to have worked for me, although I see download traffic created from Upscayl.

But these are minor quirks.

On a side note:
On Mojave v. 1.5.5 crashes very late in the conversion process, shortly before it is almost completed (>97% or something). The Electron app GUI does seem to be compatible anyway. Just the processing binary is problematic.

Thanks a lot for this great tool!

[aaronliu0130]

@pollymow Please submit new issues for these.

[pollymow]

Hi,

Am 06.10.2022 um 12:40 schrieb NayamAmarshe ***@***.***>: 1.5 was built on Big Sur I think and 1.5.5 on Monterey. In the next build, I'll try Mojave.

Great! My main production machine is an old MacPro (Early 2009 (!)) beefed up to run Mojave (and if I wanted also Monterey) - because I prefer to use my old workflows relying on several old 32bit-application which won’t run from Catalina (OS 10.15) on. So a built running on Mojave is very very welcome. I can confirm, however, that on my late 2014 double-boot iMac (similarly beefed up using OpenCore Legacy Patcher) (a) Upscayl 1.5.5 runs perfectly on Monterey - the results are excellent, the speed is quite good. (Did not test 1.5.0 on Monterey.) (b) Both 1.5.0 AND 1.5.5 (!) work on BigSur, same quality, same speed. What I am missing is • a cancel button to stop a running conversion process (I accidentally chose an upscaled image as source, so the speed was veeery slow, so I’d have liked to bail out) • I see a message, that a new version is being downloaded, but nobody knows how far the download is going and what eventually happens to this download. Dunno why, but auto updating never really seems to have worked for me, although I see download traffic created from Upscayl. But these are minor quirks. On a side note: On Mojave v. 1.5.5 crashes very late in the conversion process, shortly before it is almost completed (>97% or something). The Electron app GUI does seem to be compatible anyway. Just the processing binary is problematic. Thanks a lot for this great tool!

…

___ Peter Hartmann ________ ***@***.***

[ohxxm]

This is also happening on EndeavourOS.

[WindSpirit48]

DECODING ERROR after I select Photo option , windows 10.
It gest stuck in endless error, and wont close. I have to use task manager to close.

[aaronliu0130]

@WindSpirit48 That doesn't appear to be the same issue, could you file a new one?

[WindSpirit48]

it seems to be the same error code. unless there are multiple decoding issues. Ill post it specifically later with screen shots if i can

[aaronliu0130]

@WindSpirit48 See here:

Termination Reason: DYLD, [0x4] Symbol missing

Dyld Error Message: Symbol not found: __ZNSt3__14__fs10filesystem10__absoluteERKNS1_4pathEPNS_10error_codeE Referenced from: /Applications/Upscayl.app/Contents/Resources/bin/upscayl-realesrgan (which was built for Mac OS X 11.0) Expected in: /usr/lib/libc++.1.dylib

So upscayl-realesrgan has to be built for earlier systems to ensure compatibility.

The error here is that the upscayl executable was built for a late version of macOS so it couldn’t run on earlier systems. I don’t think that’s how windows works.

[aaronliu0130]

@allancavalari Then you have a different error. This issue is a very specific problem with mac executable compilation

[ricardo-manguedev]

getting this same error on Peppermint using appimage

[aaronliu0130]

@ricardo-manguedev GUYS, if you do NOT use a macOS lower than monterey, file a NEW issue! This specific issue only applies to macs below monterey!

[wellmeaning]

1.5 was built on Big Sur I think and 1.5.5 on Monterey. In the next build, I'll try Mojave.

Just a vote for, and additional comment in regards to a possible future attempt to build Upscayl in Mac OS 10.14 Mojave.

I noticed that on the "To-Do" page it currently reads:
"Compile on Mojave/Big Sur? DECODING ERROR => on macOS 10.13.6 #98"

I'm not sure why it's worded that way, but it's important to note that for the reasons mentioned earlier - Upscayl would really need to be done in Mojave specifically, and not any later OS such as Big Sur (unless still testing current OS compatibility).

The primary reason for choosing Mojave is that it was the last Mac OS to continue 32bit support (as well as 64bit). Big Sur was a bigger OS change and supports 64bit only. The reason most people still persisting with Mojave and earlier do so is because of that 32bit compatibility with other specialist programs.

Obviously Upscayl can't necessarily be made to be compatible with every possible past OS from history. But in practical terms - the two Mac OS models to consider ongoing are Mojave, plus whatever the current revision OS is going forward. The need for Mojave will drop off one day also, but it currently does still serve a unique purpose.

This is just a request of course, but hopefully emphasizing why it might be a worthwhile consideration.

Thanks

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[aaronliu0130]

@alcomposer does this still happen?

[NayamAmarshe]

Anything less than MacOS 11 will not be supported anymore, I think 😅

This is because GitHub has removed access to anything other than MacOS 11+. So, sadly we won't be supporting MacOS 10.x going forward (Not unless I buy a used MacBook or something).