Protonup-qt crashes immediately (2.8.0 regression)

[cylgalad]

Please fill out the following when reporting a new bug:

Describe the bug
Immediate crash at launch.

To Reproduce
Launch protonup-qt

Expected behavior
Protonup-qt window.

Desktop (please complete the following information):

• Platform: PC
• System: Archlinux
• Version: ProtonUp-Qt 2.8.0
• How did you install ProtonUp-Qt?: yay -S protonup-qt

Additional context
Maybe tied to https://github.com/DavidoTek/ProtonUp-Qt/issues/202#issue-1620272605 Commenting out lines 73-74 in steamutil.py fixes the issue, but I still don't have any Steam games in the list.

Terminal output

ProtonUp-Qt 2.8.0 by DavidoTek. Build Info: built from source.
Python 3.10.10 (main, Mar  5 2023, 22:26:53) [GCC 12.2.1 20230201], PySide 6.4.3
Platform: Arch rolling Linux-6.2.10-arch1-1-x86_64-with-glibc2.37
Loading locale fr / fr_FR
Loaded ctmod GE-Proton
Loaded ctmod Wine-GE
Loaded ctmod Boxtron
Loaded ctmod D8VK (nightly)
Loaded ctmod Kron4ek Wine-Builds Vanilla
Loaded ctmod Lutris-Wine
Loaded ctmod Luxtorpeda
Loaded ctmod NorthStar Proton (TitanFall 2)
Loaded ctmod Proton Tkg
Loaded ctmod Proton Tkg (Wine Master)
Loaded ctmod Roberta
Loaded ctmod Steam-Play-None
Loaded ctmod SteamTinkerLaunch
Loaded ctmod SteamTinkerLaunch-git
Loaded ctmod vkd3d-lutris
Loaded ctmod vkd3d-proton
Loaded ctmod Wine Tkg (Valve Wine)
Loaded ctmod Wine Tkg (Vanilla Wine)
Loaded ctmod DXVK
Loaded ctmod DXVK Async
Loaded ctmod DXVK (nightly)
qt.pysideplugin: Environment variable PYSIDE_DESIGNER_PLUGINS is not set, bailing out.
qt.pysideplugin: No instance of QPyDesignerCustomWidgetCollection was found.
Qt WebEngine seems to be initialized from a plugin. Please set Qt::AA_ShareOpenGLContexts using QCoreApplication::setAttribute and QSGRendererInterface::OpenGLRhi using QQuickWindow::setGraphicsApi before constructing QGuiApplication.
Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get'
Traceback (most recent call last):
  File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/usr/lib/python3.10/site-packages/pupgui2/__main__.py", line 2, in <module>
    main()
  File "/usr/lib/python3.10/site-packages/pupgui2/pupgui2.py", line 549, in main
    MainWindow()
  File "/usr/lib/python3.10/site-packages/pupgui2/pupgui2.py", line 108, in __init__
    self.update_ui()
  File "/usr/lib/python3.10/site-packages/pupgui2/pupgui2.py", line 223, in update_ui
    get_steam_app_list(install_loc.get('vdf_dir'), cached=False)  # update app list cache
  File "/usr/lib/python3.10/site-packages/pupgui2/steamutil.py", line 74, in get_steam_app_list
    apps.extend(get_steam_shortcuts_list(steam_config_folder, c))
UnboundLocalError: local variable 'c' referenced before assignment
Gamepad error: No gamepad found.
QThread: Destroyed while thread is still running

[sonic2kk]

Does this happen when running an AppImage/from source directly?

I ask because I've been running ProtonUp-Qt from source for months and haven't encountered this.

The issue you pointed to seems related but if that's the case then this isn't a ProtonUp-Qt bug. May be worth trying to restart Steam and seeing if the problem persists, assuming running from source rules out the possibility of this being a packaging issue.

---

Just checked the lines you referred to and Pyright does complain that c may be unbound. This shouldn't happen unless the Exception is raised, which in your log I can see that it is.

@DavidoTek would it be a good idea to move the if not no_shortcuts check inside the try block? That way c should always be set. It may also be worth adding some more exception catches for specific exceptions. Apparently get doesn't throw any exceptions even if there's no fallback value, I guess that makes sense but I thought the fallback existed for that purpose and that the default behaviour would still be to throw a KeyError. I guess we could catch a AttributeError though.

---

However the broader issue here is that something is None when it shouldn't be. From the log, it's not easy to tell what is None. There are a few gets here which could return None, though in general they shouldn't unless the data in one of Steam's internal VDF files is invalid, as seemed to be the case in #202 -- When that issue was raised, the part that's triggering the issue with c being unassigned was not present afaik as it was related to Steam shortcuts, which were only added in 2.8.0.

Since c is not set, it is possible that it's falling over when trying to get some values for c, which suggests the config_vdf_file is not valid - That is, it's trying to assign c, but triggers the exception, and then when the check underneath tries to reference c it triggers the crash.

It is also possible that the libraryfolders_vdf_file is causing the issue. Perhaps it is None and when we try to call v.get('libraryfolders'), it throws the exception. Though looking at the return value for vdf.load(), it should always return a dictionary (it's not typehinted in the code but codium tells me it should return -> dict[Unknown, Unknown], so :woman_shrugging:).

You could check the contents of your config.vdf and libraryfolders.vdf files using the Python VDF library or some other way if you are willing to see if the contents is valid. Sometimes Steam has to be restarted before the file is set properly, I've had a few weird hiccups where some data is invalid until the Steam client is restarted.

If you were to use a 2.7.7 build (i.e. flatpak) I would guess that maybe the games list would be blank.

---

I just tested the protonup-qt AUR package and it worked fine for me, so likely not a packaging issue. Probably more likely an issue with the Steam config.vdf file.

[cylgalad]

Hi, I had the empty game list issue since the previous version. I have my games on a separate partition, so I have an entry for the corresponding folder in Steam. I had Steam "repair" the entries in its game folder setting dialog. I tried removing the appinfo.vdf and Steam regenerated it, it didn't help.

[sonic2kk]

It's not the appinfo that's the issue I don't think here, I think it's either libraryfolders or config. But interesting that it's an issue. I have many games across many drives and ProtonUp-Qt sees them all.

I guess if you got appinfo to be regenerated that you already tried restarting Steam, and if this has affected you since the previous version.

Do any of your partitions have anything "unusual" about them? E.g. any special characters, etc?

[cylgalad]

It's not the appinfo that's the issue I don't think here, I think it's either libraryfolders or config. But interesting that it's an issue. I have many games across many drives and ProtonUp-Qt sees them all.

I don't see anything weird with the config file or the libraryfolder file. The game list was only empty since 2.7.7, the game list worked with previous versions. In the CompatToolMapping list, there are entries with empty "name" value or outdated proton/proton-ge versions, some with "None" in them, removing those entries doesn't change anything, even an empty list, it still doesn't work.

I guess if you got appinfo to be regenerated that you already tried restarting Steam, and if this has affected you since the previous version.

Do any of your partitions have anything "unusual" about them? E.g. any special characters, etc?

I don't have anything "unusual" in my games partition.

[sonic2kk]

Is there any extra terminal output when trying to open the games list, either with 2.7.7 (AppImage is probably easiest to test with) or when commenting out those lines causing the crash for you and running from source? It would be interesting to see if it gives any errors like #202 (about NoneType).

---

In this line:

c = vdf.load(open(config_vdf_file)).get('InstallConfigStore').get('Software').get('Valve').get('Steam').get('CompatToolMapping')

If any of the gets here fail, it will give a "NoneType has no attribute get" error. But these should all exist.

@cylgalad Can you check for the following in your config.vdf:

• InstallConfigStore
• Then Software
• Then Valve
• Then Steam
• Then CompatToolMapping The first few should look like this:

"InstallConfigStore"
{
    "Software"
    {
        "Valve"
        {
            "Steam"
            {

            }
        }
    }
}

Then inside of the "Steam" block there should be a "CompatToolMapping" section. This should be indented about 4 tabs.

---

Then can you check your libraryfolders.vdf and see if it:

• Starts with a "libraryfolders" key
• Has several entries with each library folder, numbered "0", "1", etc followed by curly brackets ({})
• Each of these entries should have a path field and an apps field

---

Also, is the path to your config.vdf file ~/.local/share/Steam/config/config.vdf, and your libraryfolders.vdf file ~/.local/share/Steam/config/libraryfolders.vdf?

I am trying to understand the format of these files to see if anything could be different from expected in them, and so causing ProtonUp-Qt to throw the error. If you'd like you could send these files but I am not sure what kind of information is in them or if anything needs to be "redacted", so I'm giving an idea of what ProtonUp-Qt looks for and what might be breaking it.

---

I tested with a blank config.vdf and libraryfolders.vdf file. Here are my findings:

• With a blank config.vdf, all tools are unused, and no games show up
• With a blank config.vdf, I can reproduce the crash on main
• With a blank libraryfolders.vdf, only shortcuts show up in the games list, and only compat tools in use by a shortcut will show up as used
• With a blank libraryfolders.vdf, I cannot reproduce the crash on main

This suggests the empty games list is caused by the config.vdf not having an expected value somewhere.

[cylgalad]

I found the issue! In config.vdf the "Valve" entry was spelled "valve", changing it makes protonup works. Now, the real problem is that Steam rewrites the entry with the lowercase "v"

[DavidoTek]

@ DavidoTek would it be a good idea to move the if not no_shortcuts check inside the try block? That way c should always be set.

Sounds good. I think there are a few instances in the code where a variable is referenced which is only defined if a try block succeeds. I think we should move those either into the try block or alternatively to the finally block. Checking with Pyright sounds like a good idea :)

I thought the fallback existed for that purpose and that the default behaviour would still be to throw a KeyError. I guess we could catch a AttributeError though. From the log, it's not easy to tell what is None.

Yeah, we either should do that or add fallback values and then check whether c is None. I wonder if there is a better way to find out which get causes the issue.

In config.vdf the "Valve" entry was spelled "valve", changing it makes protonup works. Now, the real problem is that Steam rewrites the entry with the lowercase "v"

Interesting... Did they change the format? That would mean we need to implement different nested get's for the different cases.

---

It might make sense to implement some kind of nested_get function for nested dicts in util that accepts something like InstallConfigStore.Software.Valve.Steam. If the path exists, it will just return the value. If it does not, it would throw an error and spit out the part of the path that didn't exist.

[sonic2kk]

Interesting... Did they change the format?

On my side, it's still Valve. I checked the stable and beta clients, with existing and fresh config.vdf files each time.

Having a lowercase v sounds like some kind of regression on Valve's side rather than a format change... It might be worth reporting it on the Steam for Linux issue tracker. It's been an uppercase "V" for a long time, and the general convention in the VDF format is to have CamelCasing.

Just tested renaming the key to valve and Steam corrects it to Valve the next time it writes out to this file.

It might make sense to implement some kind of nested_get function for nested dicts in util

This would probably also solve the issue of figuring out which get caused the issue, it could be implemented with some sort of string split at each . and then calls get on each of those string values. Then a debugger/logging/something along those lines could be implemented, or at the very least it would be easier to figure it out by adding logging statements in the code too :sweat_smile:

Having a function like this makes sense to me as well :+1:

[james2432]

Can confirm that on steamdeck and Arch Linux install my config.vdf have it as "Valve"

I changed it to "valve" and it crashes like above. Changing it to "Valve" fixes the issue

protonup-qt 
ProtonUp-Qt 2.8.0 by DavidoTek. Build Info: built from source.
Python 3.10.10 (main, Mar  5 2023, 22:26:53) [GCC 12.2.1 20230201], PySide 6.4.3
Platform: Arch rolling Linux-5.15.30-hardened1-1-hardened-x86_64-with-glibc2.37
Loading locale en / en_CA
Loaded ctmod GE-Proton
Loaded ctmod Wine-GE
Loaded ctmod Boxtron
Loaded ctmod D8VK (nightly)
Loaded ctmod Kron4ek Wine-Builds Vanilla
Loaded ctmod Lutris-Wine
Loaded ctmod Luxtorpeda
Loaded ctmod NorthStar Proton (TitanFall 2)
Loaded ctmod Proton Tkg
Loaded ctmod Proton Tkg (Wine Master)
Loaded ctmod Roberta
Loaded ctmod Steam-Play-None
Loaded ctmod SteamTinkerLaunch
Loaded ctmod SteamTinkerLaunch-git
Loaded ctmod vkd3d-lutris
Loaded ctmod vkd3d-proton
Loaded ctmod Wine Tkg (Valve Wine)
Loaded ctmod Wine Tkg (Vanilla Wine)
Loaded ctmod DXVK
Loaded ctmod DXVK Async
Loaded ctmod DXVK (nightly)
qt.pysideplugin: Environment variable PYSIDE_DESIGNER_PLUGINS is not set, bailing out.
qt.pysideplugin: No instance of QPyDesignerCustomWidgetCollection was found.
Qt WebEngine seems to be initialized from a plugin. Please set Qt::AA_ShareOpenGLContexts using QCoreApplication::setAttribute and QSGRendererInterface::OpenGLRhi using QQuickWindow::setGraphicsApi before constructing QGuiApplication.
Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get'
Traceback (most recent call last):
  File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/usr/lib/python3.10/site-packages/pupgui2/__main__.py", line 2, in <module>
    main()
  File "/usr/lib/python3.10/site-packages/pupgui2/pupgui2.py", line 549, in main
    MainWindow()
  File "/usr/lib/python3.10/site-packages/pupgui2/pupgui2.py", line 108, in __init__
    self.update_ui()
  File "/usr/lib/python3.10/site-packages/pupgui2/pupgui2.py", line 223, in update_ui
    get_steam_app_list(install_loc.get('vdf_dir'), cached=False)  # update app list cache
  File "/usr/lib/python3.10/site-packages/pupgui2/steamutil.py", line 74, in get_steam_app_list
    apps.extend(get_steam_shortcuts_list(steam_config_folder, c))
UnboundLocalError: local variable 'c' referenced before assignment
Gamepad error: No gamepad found.
QThread: Destroyed while thread is still running
/usr/bin/protonup-qt: line 3:  2538 Aborted                 (core dumped) /usr/bin/python -m pupgui2 "$@"

[DavidoTek]

Can you try reinstalling Steam and see if that issue still persists on your PC? Maybe the installation is stuck with a broken version. Are you using the Steam Beta Client?

[morgway]

The same error Manjaro Linux

[vladimir@mypc ~]$ protonup-qt ProtonUp-Qt 2.8.0 by DavidoTek. Build Info: built from source. Python 3.10.10 (main, Mar 5 2023, 22:26:53) [GCC 12.2.1 20230201], PySide 6.4.3 Platform: ManjaroLinux 22.1.0 Linux-5.10.176-2-MANJARO-x86_64-with-glibc2.37 Loading locale uk / uk_UA Loaded ctmod GE-Proton Loaded ctmod Wine-GE Loaded ctmod Boxtron Loaded ctmod D8VK (nightly) Loaded ctmod Kron4ek Wine-Builds Vanilla Loaded ctmod Lutris-Wine Loaded ctmod Luxtorpeda Loaded ctmod NorthStar Proton (TitanFall 2) Loaded ctmod Proton Tkg Loaded ctmod Proton Tkg (Wine Master) Loaded ctmod Roberta Loaded ctmod Steam-Play-None Loaded ctmod SteamTinkerLaunch Loaded ctmod SteamTinkerLaunch-git Loaded ctmod vkd3d-lutris Loaded ctmod vkd3d-proton Loaded ctmod Wine Tkg (Valve Wine) Loaded ctmod Wine Tkg (Vanilla Wine) Loaded ctmod DXVK Loaded ctmod DXVK Async Loaded ctmod DXVK (nightly) qt.pysideplugin: Environment variable PYSIDE_DESIGNER_PLUGINS is not set, bailing out. qt.pysideplugin: No instance of QPyDesignerCustomWidgetCollection was found. Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get' Traceback (most recent call last): File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main return _run_code(code, main_globals, None, File "/usr/lib/python3.10/runpy.py", line 86, in _run_code exec(code, run_globals) File "/usr/lib/python3.10/site-packages/pupgui2/main.py", line 2, in main() File "/usr/lib/python3.10/site-packages/pupgui2/pupgui2.py", line 549, in main MainWindow() File "/usr/lib/python3.10/site-packages/pupgui2/pupgui2.py", line 108, in init self.update_ui() File "/usr/lib/python3.10/site-packages/pupgui2/pupgui2.py", line 223, in update_ui get_steam_app_list(install_loc.get('vdf_dir'), cached=False) # update app list cache File "/usr/lib/python3.10/site-packages/pupgui2/steamutil.py", line 74, in get_steam_app_list apps.extend(get_steam_shortcuts_list(steam_config_folder, c)) UnboundLocalError: local variable 'c' referenced before assignment Gamepad error: No gamepad found. QThread: Destroyed while thread is still running /usr/bin/protonup-qt: рядок 3: 2377375 Перервано (збережено знімок оперативної пам’яті)/usr/bin/python -m pupgui2 "$@"

[sonic2kk]

Did you check your config.vdf to see if the key is valve instead of Valve?

[morgway]

Did you check your config.vdf to see if the key is valve instead of Valve?

the key is valve I changed to "Valve" but it didn't fix crash

[idiotein32]

It seems like at least on my Steam Beta installation the problem is different from the "Valve" key listed here. I was able to start both the appimage and flatpak by symlinking "libraryfolders.vdf" and "config.vdf" from ~/.steam/steam/config/ to ~/.steam/root/config . On my installation those files are on different path than what the app is looking for. I will try on other machines to confirm.

[sonic2kk]

but it didn't fix crash

@morgway Make sure you open ProtonUp-Qt before Steam has a chance to overwrite it again, as explained in this issue.

On my installation those files are on different path than what the app is looking for

@idiotein32 Strange, I'm running the Steam Beta on all my devices and it's ~/.local/share/Steam, the same as it's been for me for many years. I do have ~/.steam/steam but it's a symlink. Not sure if I have the ~/.steam/root path but I think I do, and it should also be a symlink. #173 was created and abandoned a while ago but it seemed from that issue that the root path is an old path.

[idiotein32]

Steam installation paths are wildly inconsistent, I am reviewing it on the machines I have at hands and they all have some sort of idiosyncrasy. I only have Debian systems around. My installation is really old, like maybe close to a decade. The ~/.steam folder seems to be the "main" place, ~/.steam/root is a symlink to it, which is a problem since what ProtonUp-Qt is looking for at this path is in ~/.steam/steam folder. Proton-GE versions are in ~/.steam/compatibilitytools.d/. ~/.local/share/Steam is mostly empty except for some old empty folders.

Maybe ProtonUp-Qt should either list its expectations in terms of paths to the user, or include a more robust and wide ranging lookup.

[sonic2kk]

Maybe ProtonUp-Qt should either list its expectations in terms of paths to the user, or include a more robust and wide ranging lookup.

I actually just looked in the code and there is logic to check for ~/.steam/steam and ~/.steam/root.

# support different Steam root directories
_POSSIBLE_STEAM_ROOTS = ['~/.local/share/Steam', '~/.steam/root', '~/.steam/steam', '~/.steam/debian-installation']
_STEAM_ROOT = _POSSIBLE_STEAM_ROOTS[0]
for steam_root in _POSSIBLE_STEAM_ROOTS:
    ct_dir = os.path.join(os.path.expanduser(steam_root), 'config')
    if os.path.exists(ct_dir):
        _STEAM_ROOT = steam_root
        break

However given that #173 was raised as well as this comment, there may be something else wrong here. I just did a quick check and all but the debian-installation paths exist for me (I'm on Arch, so that's expected). I also did a quick code mockup and the os.path.exists checks work for me as well.

~/.local/share/Steam is mostly empty except for some old empty folders

Do you have ~/.local/share/Steam/config? If so, ProtonUp-Qt would be returning True for this check, and skipping the others (which in this case are your valid install dirs).

This may also explain one recent issue where a terminal output said libraryfolders.vdf did not exist. If it's looking in a library folder with the right "folder structure" but that is not actually being used by Steam, that may explain the problem.

---

I should also mention that ~/.local/share/Steam is the assumed path in a lot of other project's documentation as well, so though the paths do indeed seem to be inconsistent, it appears that the primary one is ~/.local/share/Steam, at least now. So I think current behaviour of defaulting to ~/.local/share/Steam (_POSSIBLE_STEAM_ROOTS[0]) is acceptable.

@DavidoTek Maybe ProtonUp-Qt should have a more "strict" check here, and should check if config.vdf and libraryfolders.vdf exist in the Steam install dir before selecting it. We could also check if they're not empty, or if they have the relevant keys we're looking for - though checking if they exist should be enough, and checking if they're not empty may even in itself be overkill, so any more checks may not be required.

---

To sum up, there are the following issues then it seems:

• The config.vdf cannot be read properly due to the key casing difference that occurs on some installs - Should be addressed by #227.
• The Steam root selection may not always be correct, may be addressed by #231 if the issue is related to an unused Steam install dir having the correct folders but not the correct files.
• libraryfolders.vdf not found (#228), may be fixed by #231 as well.

[idiotein32]

Do you have ~/.local/share/Steam/config? If so, ProtonUp-Qt would be returning True for this check, and skipping the others (which in this case are your valid install dirs).

On my main system the .local/share/Steam is empty and has not been touched since 2019. On a fresh installation (not beta) done today, Debian "soon to be" Bookworm, this folder is absent altogether. The "config.vdf" is in ~/.steam/steam/config/ and I symlinked it to ~/.steam/config/ to allow ProtonUp-Qt to launch.

This may also explain one recent issue where a terminal output said libraryfolders.vdf did not exist. If it's looking in a library folder with the right "folder structure" but that is not actually being used by Steam, that may explain the problem.

Same applies to libraryfolders.vdf.

On newer Debian systems everything is under ~/.steam/debian-installation/ .

[sonic2kk]

I symlinked it to ~/.steam/config/ to allow ProtonUp-Qt to launch.

Is this path definitely correct? This doesn't look like a path ProtonUp-Qt should be looking for. It should be ~/.steam/root/config or ~/.steam/steam/config...

On newer Debian systems everything is under ~/.steam/debian-installation/

That's one of the paths that ProtonUp-Qt looks for, so that's good at least.

[idiotein32]

Yes, this path is correct, I just removed the symlinks in ~/.steam/config and ProtonUp-Qt refused to start. Put it back and it starts. The real files are in /.steam/steam/config/, both config.vdf (to launch app) and libraryfolders.vdf (to get games list) symlinks are needed.

[sonic2kk]

That is very strange indeed, as ProtonUp-Qt shouldn't be checking ~/.steam/config at all. Take this code snippet for example:

import os
_POSSIBLE_STEAM_ROOTS = ['~/.local/share/Steam', '~/.steam/root', '~/.steam/steam', '~/.steam/debian-installation']
for sp in _POSSIBLE_STEAM_ROOTS:
    print(os.path.join(os.path.expanduser(sp), 'config'))

None of these should return /home/<username>/.steam/config.

If you edit _POSSIBLE_STEAM_ROOTS in constants.py to include ~/.steam/config, does ProtonUp-Qt launch? You can run from your modified source with python3 -m pupgui2.

[idiotein32]

On my system .steam/root is a symlink to .steam, so when creating symlinks in .steam/config/ they effectively get picked-up by the .steam/root check.

[sonic2kk]

Ah okay, that makes sense then why it's being picked up. I appreciate the explanation :-)

If you'd like you could test #231 to see if it resolves the earlier issue of the ~/.local/share/Steam existing and being picked up by ProtonUp-Qt, but not finding the config.vdf. That PR should only pick up a Steam root dir if it has a config.vdf, instead of the current check on main which checks for the config folder. In cases where this folder exists but is empty, the root dir would still be chosen on main, but that PR changes the behaviour so that it should only be picked up config.vdf and libraryfolders.vdf exist in a given Steam root config dir.

[idiotein32]

Sure, I will check out this branch an give it a try when I have more time. I am curious if anyone knows a place where Valve or Steam people have kept track of all the historical changes they have made to Steam installation hierarchy. My older system seems to be a monument to their wanderings.

[idiotein32]

If you'd like you could test #231 to see if it resolves the earlier issue of the ~/.local/share/Steam existing and being picked up by ProtonUp-Qt, but not finding the config.vdf.

I tried this branch, but got the same outcome, ProtonUp-Qt only starts if I manually symlink config.vdf to ~/.steam/config, the games list requires a similar symlink for libraryfolders.vdf.

During the testing I removed completely ~/.local/share/Steam and it didn't change anything, Steam starts fine, so does ProtonUp-Qt (with the symlinks in place), and the folder is not recreated by Steam.

[sonic2kk]

Thanks for testing!

This is pretty strange behaviour for sure... I wonder if prioritising ~/.steam/steam would help, as in moving ~/.steam/steam to be the second element in that list. Since you mentioned you have the real files in ~/.steam/steam/config.

The real files are in ~/.steam/steam/config/, both config.vdf (to launch app) and libraryfolders.vdf (to get games list) symlinks are needed.

I just did some testing in case there was some kind of issue with the folder symlinks somehow (even though it works for you when you use symlinks). On my PC and Steam Deck, ~/.steam/steam and ~/.steam/root are both symlinks to ~/.local/share/Steam. But the config file was still found and loaded, and the os.path functions still return the expected values (exists, isfile, isdir all work as expected).

---

If you want you could try to change the _POSSIBLE_STEAM_ROOTS list in the PR code to put ~/.steam/steam ahead of ~/.steam/root and see if that works, like this:

_POSSIBLE_STEAM_ROOTS = ['~/.local/share/Steam', '~/.steam/steam', '~/.steam/root', '~/.steam/debian-installation']

I'm still not so sure that this would work, but it may be worth a try. On my PC, I tried removing the ~/.local/share/Steam path from that list and ProtonUp-Qt still loaded. Even if I put the ~/.steam/debian-installation directory first (which I don't have on my systems, so this was a test with an invalid path as the first element), ProtonUp-Qt still successfully falls back to ~/.steam/root. I also tried having only ~/.steam/root and ~/.steam/steam as the paths in the list, in either order, and ProtonUp-Qt still loaded the files for me.

---

The ~/.steam/root folder shouldn't symlink to ~/.steam but rather your real Steam installation (in your case, I suppose ~/.steam/steam), so this is more strange behaviour. However that PR should catch that, since it should see that the config,vdf and libraryfolders.vdf don't exist in that folder, and skip onto the next one.

I actually just tested removing ~/.local/share/Steam from the _POSSIBLE_STEAM_ROOTS, changing the ~/.steam/root symlink to ~/.steam, and on that branch, ProtonUp-Qt did catch that it wasn't valid and moved onto ~/.steam/steam.

[idiotein32]

If you want you could try to change the _POSSIBLE_STEAM_ROOTS list in the PR code to put ~/.steam/steam ahead of ~/.steam/root and see if that works, like this:

_POSSIBLE_STEAM_ROOTS = ['~/.local/share/Steam', '~/.steam/steam', '~/.steam/root', '~/.steam/debian-installation']

This works without the "config.vdf" symlink, but I am loosing the games list menu entirely, and the default "compatibilitytools.d" is wrong, it has to be selected manually again.

I will need to look into the code more closely, and also tidy up my Steam installation. I think the problems come from old empty "config" and "compatibilitytools.d" being picked up. ProtonUp-Qt is just checking for the first match in those directories, and doesn't check for the required content apparently. I will run more systematic tests, with both modified and unmodified code every time.

[sonic2kk]

I will need to look into the code more closely, and also tidy up my Steam installation. I think the problems come from old empty "config" and "compatibilitytools.d" being picked up. ProtonUp-Qt is just checking for the first match in those directories, and doesn't check for the required content apparently.

ProtonUp-Qt main currently matches the Steam root directory based on where the config folder is. With the PR I put up, it matches the Steam root based on where the config.vdf is.

The path to compatibilitytools.d is then built based on that Steam root path:

{'install_dir': f'{_STEAM_ROOT}/compatibilitytools.d/', 'display_name': 'Steam', 'launcher': 'steam', 'type': 'native', 'icon': 'steam', 'vdf_dir': f'{_STEAM_ROOT}/config'},

The _STEAM_ROOT is the path to the Steam root directory, e.g. ~/.steam/steam. The config folder (which contains config.vdf and libraryfolders.vdf) and the compatibilitytools.d folder should be in the same Steam root directory. In your case, _STEAM_ROOT should be chosen as ~/.steam/steam, and so the paths should be as follows:

• Config VDF path: ~/.steam/steam/config/config.vdf
• Libraryfolders VDF path: ~/.steam/steam/config/libraryfolders.vdf
• Compatibilitytools.d path: ~/.steam/steam/compatibilitytools.d

I appreciate all the investigation you've done so far, it's been pretty interesting :smile: If you get some time to delve further in like you mentioned I'd be pretty interested to hear what you find out!

[DavidoTek]

~/.local/share/Steam is the assumed path in a lot of other project's documentation as well, so though the paths do indeed seem to be incons

That seems to be the path that at least the current version of Steam (official .deb) is using. Older versions of Steam may have used other paths and it may also be different with other distro packages.

@DavidoTek Maybe ProtonUp-Qt should have a more "strict" check here, and should check if config.vdf and libraryfolders.vdf exist in the Steam install dir before selecting it

Seems like a good idea.

I wonder if prioritising ~/.steam/steam would help On my PC, I tried removing the ~/.local/share/Steam path from that list and ProtonUp-Qt still loaded. Even if I put the ~/.steam/debian-installation directory first

With a correct installation, all of them should work. I think the reason I choose this order is that ~/.steam/root should be the correct one and ~/.steam/steam could contain an old installation, though I can't remember where I picked that up.

The ~/.steam/root folder shouldn't symlink to ~/.steam

I think I've seen that one before... interesting.

I appreciate all the investigation you've done so far, it's been pretty interesting

Definitively!

[idiotein32]

The ~/.steam/root folder shouldn't symlink to ~/.steam

This is definitely not an outlier, I encountered this on two more systems, all "old" Steam installations and using Beta. On all there were more than one instance of "config" folder. I tried different cleanup methods, and only one didn't result in a broken Steam installation, re-download of all games, or non-functional ProtonUp-Qt. I put it here for reference to help anyone stumbling upon this problem:

Backup your Steam folders. At least take a snapshot of every file/folder you move around.

Do not move the "root" symlink if it points to ~/.steam, it will break Steam.

Locate the "real" config folder, it should contain many more files than the "old" one, and contain the files "config.vdf" and "libraryfolders.vdf".

Copy any files from the "old" config folder to the "real one", move the "old" one away, and place a symbolic link in the Steam root folder (~/.steam for me) pointing to the real one (for example for me it is in ~/.steam/steam/config).

Locate the "userdata" and "appcache" folders, if they are not at the root of your Steam installation, create symbolic links for each in the root.

Finally look into .local/share/Steam and copy the content of any additional "config" folder to the one you placed at the root of your Steam installation, then move it out of the way. If you have an additional "userdata" folder (I did), do the same.

Launch Steam, you will have to log in, and you will see a lot of games queued for download, but they won't be all re-downloaded, just checked. Make sure your preferences are fine, check your additional Steam library location if you have any (I have three), it should all be fine.

Now ProtonUp-Qt should be fully functional, including the games list.

[morgway]

but it didn't fix crash

@morgway Make sure you open ProtonUp-Qt before Steam has a chance to overwrite it again, as explained in this issue.

I closed Steam and changed valve to Valve. After that I launched Protonup-QT:

[vladimir@mypc ~]$ protonup-qt ProtonUp-Qt 2.8.0 by DavidoTek. Build Info: built from source. Python 3.10.10 (main, Mar 5 2023, 22:26:53) [GCC 12.2.1 20230201], PySide 6.4.3 Platform: ManjaroLinux 22.1.0 Linux-5.10.177-1-MANJARO-x86_64-with-glibc2.37 Loading locale uk / uk_UA Loaded ctmod GE-Proton Loaded ctmod Wine-GE Loaded ctmod Boxtron Loaded ctmod D8VK (nightly) Loaded ctmod Kron4ek Wine-Builds Vanilla Loaded ctmod Lutris-Wine Loaded ctmod Luxtorpeda Loaded ctmod NorthStar Proton (TitanFall 2) Loaded ctmod Proton Tkg Loaded ctmod Proton Tkg (Wine Master) Loaded ctmod Roberta Loaded ctmod Steam-Play-None Loaded ctmod SteamTinkerLaunch Loaded ctmod SteamTinkerLaunch-git Loaded ctmod vkd3d-lutris Loaded ctmod vkd3d-proton Loaded ctmod Wine Tkg (Valve Wine) Loaded ctmod Wine Tkg (Vanilla Wine) Loaded ctmod DXVK Loaded ctmod DXVK Async Loaded ctmod DXVK (nightly) qt.pysideplugin: Environment variable PYSIDE_DESIGNER_PLUGINS is not set, bailing out. qt.pysideplugin: No instance of QPyDesignerCustomWidgetCollection was found. Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get' Traceback (most recent call last): File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main return _run_code(code, main_globals, None, File "/usr/lib/python3.10/runpy.py", line 86, in _run_code exec(code, run_globals) File "/usr/lib/python3.10/site-packages/pupgui2/main.py", line 2, in main() File "/usr/lib/python3.10/site-packages/pupgui2/pupgui2.py", line 549, in main MainWindow() File "/usr/lib/python3.10/site-packages/pupgui2/pupgui2.py", line 108, in init self.update_ui() File "/usr/lib/python3.10/site-packages/pupgui2/pupgui2.py", line 223, in update_ui get_steam_app_list(install_loc.get('vdf_dir'), cached=False) # update app list cache File "/usr/lib/python3.10/site-packages/pupgui2/steamutil.py", line 74, in get_steam_app_list apps.extend(get_steam_shortcuts_list(steam_config_folder, c)) UnboundLocalError: local variable 'c' referenced before assignment Gamepad error: No gamepad found. QThread: Destroyed while thread is still running /usr/bin/protonup-qt: рядок 3: 296951 Перервано (збережено знімок оперативної пам’яті)/usr/bin/python -m pupgui2 "$@"

Protonup-QT-2.7.7-x86_64.Appmage runs. But it also makes errors to the console.:

[vladimir@mypc Завантажене]$ ./ProtonUp-Qt-2.7.7-x86_64.AppImage ProtonUp-Qt 2.7.7 by DavidoTek. Build Info: Official AppImage by DavidoTek. Python 3.8.2 (default, Mar 13 2020, 10:14:16) [GCC 9.3.0], PySide 6.2.4 Platform: ManjaroLinux 22.1.0 Linux-5.10.177-1-MANJARO-x86_64-with-glibc2.29 Loading locale uk / uk_UA Loaded ctmod GE-Proton Loaded ctmod Wine-GE Loaded ctmod Boxtron Loaded ctmod D8VK (nightly) Loaded ctmod Kron4ek Wine-Builds Vanilla Loaded ctmod Lutris-Wine Loaded ctmod Luxtorpeda Loaded ctmod NorthStar Proton (TitalFall 2) Loaded ctmod Proton Tkg Loaded ctmod Roberta Loaded ctmod Steam-Play-None Loaded ctmod SteamTinkerLaunch Loaded ctmod SteamTinkerLaunch-git Loaded ctmod vkd3d-lutris Loaded ctmod vkd3d-proton Loaded ctmod DXVK Loaded ctmod DXVK Async Loaded ctmod DXVK (nightly) qt.pysideplugin: Environment variable PYSIDE_DESIGNER_PLUGINS is not set, bailing out. qt.pysideplugin: No instance of QPyDesignerCustomWidgetCollection was found. Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get' Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get' Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get' Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get' Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get' Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get' Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get' Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get' Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get' Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get' Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get' Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get' Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get' Error: Could not get a list of all Steam apps: 'NoneType' object has no attribute 'get' Gamepad error: No gamepad found. [vladimir@mypc Завантажене]$

[sonic2kk]

@idiotein32 Thanks for the detailed investigation!

This is definitely not an outlier, I encountered this on two more systems, all "old" Steam installations and using Beta. On all there were more than one instance of "config" folder. I tried different cleanup methods, and only one didn't result in a broken Steam installation, re-download of all games, or non-functional ProtonUp-Qt. I put it here for reference to help anyone stumbling upon this problem:

I had some time and did a little bit of investigation into Steam paths across distros.

The Steam Arch Wiki page does state the following:

The default Steam install location is ~/.local/share/Steam. If Steam cannot find it, it will prompt you to reinstall it or select the new location. This article uses the ~/.steam/root symlink to refer to the install location.

Steam Deck also uses this path (SteamOS is Arch-based).

The Steam Gentoo Wiki page also states that generally speaking, ~/.local/share/Steam is the install directory.

The instructions throughout this page use the typical Steam installation directory ~/.local/share/Steam.

The Gentoo wiki does not mention the ~/.steam/root symlink, however the Arch wiki does state that ~/.steam/root should point to ~/.local/share/Steam.

---

The Steam paths across distros seem to be a real mess. I'm not sure if this is new, because many different project's documentation will reference ~/.local/share/Steam and have for a long time, though it could be a packaging thing.

I am not sure on the best way to try and resolve this on the ProtonUp-Qt side. If #231 didn't resolve it then I'm not sure why it isn't working, unless there are multiple copies VDF files (which may be the case from reading your explanation?) but it would be difficult for ProtonUp-Qt to know which is the "real" directory.

@DavidoTek Maybe putting ~/.steam/root as the first directory in the Steam roots list could help? If this exists it should point to the right folder (as in this issue and as per the Arch wiki, ~/.steam/root should always be a symlink to the real install directory). That would also potentially resolve #173 (though that issue hasn't been active in a while). I'm not sure if this would have any other potential regressions though. A change like that along with with #227 (to fix any potential crashing if the VDFs can't be loaded) and #231 (ensuring the directory has the files we need and isn't empty) could help this issue. I am thinking the order could be like this:

# `~/.steam/root` can seemingly point to various different places, but should usually exist
#
# If not we can fall back to ~/.local/share/Steam (~/.steam/root is usually a symlink to this path, but as this issue has shown it's not always the case)
# Otherwise, check `~/.steam/steam` and finally the Ubuntu repo location
_POSSIBLE_STEAM_ROOTS = ['~/.steam/root', '~/.local/share/Steam', '~/.steam/steam', '~/.steam/debian-installation']

@idiotein32 If you're still willing to play around with the code, you could try the idea above. The thinking here is that if ~/.steam/root exists then we should be able to rely on that to be the "real" path. There shouldn't be any issues with relying on a symlink, though it would be possible to get the "real" path in the check that sets the VDF dir. We could expand the real path that the symlink points to and set _STEAM_ROOT to that (if the path is a symlink at all), if we didn't want to use a symlink path for some reason.

[idiotein32]

Hello,

The Steam Gentoo Wiki page also states that generally speaking, ~/.local/share/Steam is the install directory.<

I only have experience with older Debian installation, on the systems I have this directory exists, but has not been touched since 2019. It contains a lone "userdata" with nothing recent in it. I could not link this data to anything, in fact just deleting "~/.local/share/Steam" didn't have any consequences, and it wasn't recreated when launching Steam client. On newer Debian systems (Actual "testing/Sid) with recent install this folder doesn't seem to be used either. That being said, since Steam is now using Arch mainly, and consolidating this folder as the root one, it has to accounted for.

Maybe putting ~/.steam/root as the first directory in the Steam roots list could help?<

I think this is the main point, from Steam client point of view the "root" symlink is always right. But even then there are a inconsistencies, like on the systems I have around even if "root" points to ~/.steam, a config folder is always present and recreated if absent in ~/.steam/steam. This is really confusing, and that is why symlinks are the best solution to make ProtonUp-Qt work in those cases.

So even if the logic is probably hard to get right, the way around those installations which have "root" pointing to something else than ~.local/share/Steam, is looking for the actual files "config.vdf" and "libraryfolders.vdf", it is the only way to tell what's what. Even if more than one "config" folder is present, there is only one of those files. Since littering symlinks around users systems isn't a good practice, maybe in those odd cases a popup could suggest to create the necessary symlinks, or point to a wiki url explaining the problem.

@idiotein32 If you're still willing to play around with the code, you could try the idea above.<

I will, I have been short on time since Steam isn't my main priority in life right now ;-) , but I will experiment with this.

[sonic2kk]

I think this is the main point, from Steam client point of view the "root" symlink is always right. But even then there are a inconsistencies, like on the systems I have around even if "root" points to ~/.steam, a config folder is always present and recreated if absent in ~/.steam/steam

Okay, that is really strange for sure. Even so then, if you have a ~/.steam/config, ~/.steam/root/config/config.vdf should be picked up by ProtonUp-Qt. Since ~/.steam/root should always point to the folder that has a valid config folder (so even if the true path is ~/.steam/config, ~/.steam/root will point to ~/.steam and this will have a config folder. In other words, ~/.steam/root/config should equal ~/.steam/config).

Even if more than one "config" folder is present, there is only one of those files [config and libraryfolders]

I agree, that's my thinking as well. #231 should have accomplished this as previously it was only checking for the first config folder it found, and this could've been empty or invalid in some way.

Since littering symlinks around users systems isn't a good practice, maybe in those odd cases a popup could suggest to create the necessary symlinks, or point to a wiki url explaining the problem.

Maybe, though ideally ProtonUp-Qt shouldn't have to make symlink at all. Wherever it finds the config and libraryfolders files should get marked as the Steam root, and thus the vdf_dir that it can use for its other logic (marking tools as unused, games list, bulk updating compat tools, etc).

[DavidoTek]

@ DavidoTek Maybe putting ~/.steam/root as the first directory in the Steam roots list could help? A change like that along with with #227 [...] and #231 [...]

I think I didn't put ~/.steam/root as the dirst directory is because there was a case where Steam was installed in ~/.steam/steam but it tried to use ~/.steam/root even though it was invalid (https://github.com/DavidoTek/ProtonUp-Qt/issues/23). With the improved checks from https://github.com/DavidoTek/ProtonUp-Qt/pull/231 that could be fixed. Actually, issue #23 is over a year old, so the path may have changed anyway since then.

I wonder if there is a better way to determine which folder is the correct one. Maybe determining the last modification using os.path.getmtime('/path/to/steam/config.vdf') and comparing which one is the highest(latest).

if ~/.steam/root exists then we should be able to rely on that to be the "real" path

Yeah, that seems to be the "correct" one, so we could change it to be the first path. Eitherway, we should add a notice that if ProtonUp-Qt isn't working properly and the Steam installation is ancient, the old folders should be deleted manually.

[cylgalad]

I found 2 other vdf files with "valve": ~/.steam/registry.vdf and ~/.local/share/Steam/userdata/number/config/localconfig.vdf. Changing to uppercase "Valve" in all 3 files completely fixes the issue.

[DavidoTek]

Very strange indeed. I installed Steam on a computer with Ubuntu newly installed. I checked it there and they are uppercase as they should be.

[sonic2kk]

Do VDF files generate differently based on system language/locale or the Steam language (if anything it's probably the Steam language)? That would be pretty strange, but just something that crossed my mind.

[sonic2kk]

As it's been reported a few more times, what is the path to resolution on this (if a resolution isn't already in place)? From re-reading the conversation most of the work has been done, except for the work of potentially making ~/.steam/root the first path in _POSSIBLE_STEAM_ROOTS, and the mentioned modification date check for the VDF files (a potential issue here might be performance but it's probably negligible since we're just checking a handful of files across set folders).

It would probably be helpful if any users who are experiencing this issue could re-test from main to see if the issue is fixed. The crash at least should hopefully be fixed but the games list issue may not be. The users who reported the issue as a result of the VDF keys should have the issue fixed in the next release (since we check for valve and Valve as of #227). The users with the Steam paths issue may have the issue fixed already with the VDF file checks (#231), or if not, changing the order of the Steam roots to prioritize ~/.steam/root may help.

Either way, main should more gracefully handle the cases triggering the crash (was triggered when trying to generate shortcuts without a valid VDF file, fixed by #227 as well) and may also restore the Games List in some scenarios unless the "real" Steam root still cannot be found.

[idiotein32]

Regarding the path problems I have encountered, disregarding the root link and looking for the needed files themselves would have worked, not the other way around. The only way I could keep the root link consistent (changing it breaks Steam client) and make ProtonQt-Up happy is symlinking the needed files and folders to the root path. I don't think this could or should be automated without user knowledge, littering user directory with symlinks doesn't look like an acceptable solution.

[DavidoTek]

As it's been reported a few more times

Interesting. But good that many people reported it, so that we know it wasn't just a single case.

except for the work of potentially making ~/.steam/root the first path in _POSSIBLE_STEAM_ROOTS

and the mentioned modification date check for the VDF files (a potential issue here might be performance but it's probably negligible since we're just checking a handful of files across set folders).

Hmm, still not sure on that. We could just change it and if it doesn't work revert it (https://en.wikipedia.org/wiki/Perpetual_beta)

should have the issue fixed in the next release [...] Either way, main should more gracefully handle the cases triggering the crash

I think it's time for a new release then (probably after I merged https://github.com/DavidoTek/ProtonUp-Qt/pull/245)

[Mace68]

Only places I have libraryfolders.vdf in Ubuntu 22.04 are

~/.steam/steam/config/libraryfolders.vdf
~/.steam/steam/steamapps/libraryfolders.vdf

also ~/.steam/root is just a link pointing back to ~/.steam

[sonic2kk]

@Mace68 does ~/.steam/root point to ~/.steam or ~/.steam/steam? In other words, is ~/.steam/steam/config equivalent to ~/.steam/root/config? This could be an important distinction.

[Mace68]

@sonic2kk ~/.steam/root points to ~/.steam

user@machine:~/.steam$ ls -l root
lrwxrwxrwx  1 user user 21 Jul  3 14:24 root -> /home/user/.steam

~/.steam/steam/config is not equivalent to ~/.steam/root/config as ~/.steam/steam is a real directory. ~/.steam/steam/config would be equivalent to ~/.steam/root/steam/config

[DavidoTek]

~/.steam/steam/config is not equivalent to ~/.steam/root/config as ~/.steam/steam is a real directory. ~/.steam/steam/config would be equivalent to ~/.steam/root/steam/config

Does ProtonUp-Qt detect your Steam installation in ~/.steam/steam? The ~/.steam/root -> ~/.steam symlink is a bit strange but shouldn't break anything as long ~/.steam/config/libraryfolders.vdf doesn't exist.

[sonic2kk]

Can anyone still reproduce this? It's been a long while now without any further reports, and there was significant work done to try and fix some crashes related to making Steam shortcut parsing more reliable, and to better detect various Steam install folders by changing the order in which they are checked, and checking to ensure libraryfolders.vdf and config.vdf both exist to discern a valid Steam installation directory.

There have also been an update to ProtonUp-Qt since the last comment was posted (v2.8.1 -> v2.8.2) with no further comments on this issue since.