-
-
Notifications
You must be signed in to change notification settings - Fork 470
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
The version of some Winget apps fails to load and is shown as "Unknown" on the infobox section #307
Comments
It seems like you forgot to add tags to this issue |
True! |
I'm sorry. i forgot about that. Please note that a few days ago I improved the discover software parser, so this could be fixed already (i couldn't reproduce this issue). |
Maybe it happens only on Windows 10? It's not fixed for me yet: |
By the way, this problem happens on clean Windows 10 installations |
This problem actually seems to have gotten worse... |
Could you please send a screenshot of the failing packages? |
It doesn't happen with any specific package (it seems random) 2022-11-08.18-32-55.mp4 |
Couldn't this be solved by making the |
I don't think so, because looking at the outputs the packages are actually shown by winget, but they are just not parsed correctly by WingetUI. My bet is that what is failing is the wingetui cli parser |
Fixed! The issue is actually caused by winget itself, but looping the command until it returns a valid output fixes the issue for 99.756% of the times this happen |
Thanks a lot! Lol, nice statistics by the way! |
I've tested the latest head and it seems much better. But I am still facing the following problem sometimes:
Python CLI shows the version, but WingetUI still displays unknown. Maybe using the version info previously available from |
Fixed using the same method, brutte-force run the command until it returns something |
Now version loads fine, but other fields are unknown (the opposite of what happened before 85ae7ab). Thank you nonetheless |
does this happen again with the same frequency as before? Because for me it is still fixed... Anyway, I have done what I could,lets hope that winget 1.4 fixes that |
Honestly, I don't think this is an issue related to the changes to screenshots. The code is completely separated and one uses winget and the other parses an online json file, so I don't think they are related. |
I've just tested it. WingetUI-1.4.2 (the last version before screenshot) doesn't have this bug for some reason. If it's not the screenshot I have no idea what could be the cause of this issue This bug started on version 1.5 and you have been able to mitigate it to a great extent, but it's puzzling me why it didn't use to happen on version 1.4.2 |
Well, this is suspicious, since the bundled winget version did not change... |
I've tested replacing Winget 1.3 with stock Winget 1.4 RC (there's still this bug, but the console log is different): Situation 1 (both CLI and GUI failed to load URL): Situation 2 (CLI is stuck, nothing is displayed): Situation 3 (CLI loads installer URL, but GUI doesn't): Situation 4 (Probably similar to 2, CLI times out and only version is displayed) |
Please note that some wording changes could have been done v1.4, i will analyze every parameter to see if it has changed its name. |
Winget is (in theory) about to release a COM API, so this part of winget could work with the api, preventing this issue to happen |
I have the same issue, but in my case the package id gets truncated or rather the truncated package id from the UI is used. The UI shows the package id as While trying to reproduce this issue I also had the case that it sometimes the package id is not truncated and everything is working properly and the infobox is able to load. Winget log from
WingetUI log:
|
This is a different issue, and it resulted to be winget's fault. The winget client often chops long names/IDs. There's an issue somewhere talking about this, but in a summary, we need winget to fix this |
Nice! #712 |
On winget, i assume? |
yes |
Could you please open a new issue? |
this appears to be fixed on v. 1.7 beta |
It should not, I havn't done any changes to that |
I just triple checked. For me Microsoft.DotNet.Framework.DeveloperPack_4 usually doesn't load on 1.6.5, but on 1.7 beta it loads 10 out of 10 times. How this got fixed is beyond me |
all right then |
No description provided.
The text was updated successfully, but these errors were encountered: