New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG][PATH PARSING] Cannot upscayl Non-ASCII path #802
Comments
Huh, interesting. #770 mentions the same bug but I was unable to reproduce it. Using lámpara as the directory name caused the error on Linux. On MacOS, It's not the case, the image upscayls just fine. |
I think it was very hasty to close my thread, and I don't understand why. I have tested on two different computers, with different versions of Tumbleweed (6 months without updating one of them) and the problem occurred on both of them. Also, I was previously using Upscayl without problems in folders with non-ASCII characters, so if suddenly after an update of Upscayl, it stops working properly, I think it is clear that some change in Upscayl causes the problem, and even more when all the other applications work in those folders with the same files without problems. For my part, I have again taken the trouble to check from which version some change in the Upscayl code caused this problem to occur and I have found out that it is the versions after 2.9.8 that fail. Interestingly, version 2.9.9 at least gave an error (not like the latest version, which tells the user that ‘everything is fine’). In 2.9.9 it shows this error:
It shows an error about Upscayl is not able to find same file was processing. I even tried to test the install version (RPM) but I couldn't, because it doesn't find the libuuid library (in openSUSE, it's libuuid1). Of course, in any way I can help you find out what's going on by providing more information or testing, please let me know. |
@RafaelLinux I only closed the other thread because I was unable to reproduce the issue with your provided paths on Linux. This issue however, mentioned another name which I was able to reproduce the bug with. |
I'll investigate more |
That's because in 2.9.9 we pointed a separate tool to the file path to post-process it. We later infused processing into our own CLI which tries to output it all in one go. |
I expect it helps in some way. |
Checklist
Describe the Bug
If the path that contains the destination folder, or the folder itself, has non-ascii characters in the name, the program fails to save and show the enlarged image. The logs say the image has been processed correctly and report it as saved in the selected path, but the image is not saved (or shown in the UI) unless an output folder without non-ascii characters in the name or path is selected. The log does not display any errors. By all accounts, the image should be saved but it's not, and the UI does not display it.
To Reproduce
lámpara
orcañón
.Upscayl Version (or commit hash)
2.10.9 and 2.11
Platform
Linux
OS Version
Arch Linux (using both AUR and AppImage)
GPU Name
AMD Lexa PRO (Radeon RX 550X rev. c7)
Expected Behavior
The image should be saved correctly in any folder with write permissions.
Screenshots
Logs
The text was updated successfully, but these errors were encountered: