Metro patch no longer available

[Kaukoa]

Hello, I found that the given patch for metro is no longer available, which breaks the script. I don't know if there is a mirror for the tested version, but the most recent seems to be available here: https://steamcommunity.com/groups/metroforsteam/discussions/9/1621724915812034590/

[kotajacob]

Thanks for spotting this! I'll test that version tonight. If it doesn't work I can put up a mirror until I can work out updating to the new version.

[kotajacob]

I was able to replicate this, but unfortunately things came up in life and I wont be able to submit a fix until this next week is over. If during that time someone submits a PR I'll take a look and test it though.

[Tardog]

@Kaukoa Is this still an issue with the current master? It should haven been solved with #68. Can you confirm?

[JohnHuddleston]

This issue is back, currently running into the following:

$ wal-steam -w                                         1 ↵ 
Wal Steam cache found
Downloading config file
Downloading Metro for steam
Downloading Metro patch
Error: downloading needed patch file. Check your connection and try again.

[kotajacob]

Can confirm. I just tested it and had the download fail. Then a few minutes later I tested it again and it worked. This is going to be really weird to debug.

Maybe github is somehow blocking or limiting python request file downloads? Maybe the proper solution is to simply have wal_steam retry the download a couple of times before giving up?

[JohnHuddleston]

I tried multiple times earlier to no avail, but it went through on the first try just now. It could definitely be an issue with github limiting download requests, but if repetition helps, I'd work in a timeout and try limit. I've been in the middle of a move and unable to dive into the script, but if I get a chance I'll see if I can implement that. It might be good to add a flag to specify the max number of tries.

[ghost]

Hitting this same issue today :(

What do I do with the file from @Kaukoa 's first post to make it go? Edit some of the python source?

edit: ah it worked after a while... doesn't seem to skin the new steamfriends, though? Hmmm.. Fixed that by running steam -steamos. Good enough for me!

[lplover]

So I ran into this issue, but running wal-steam -w -d -u worked perfectly fine, seems like the hi-dpi patch is up.

edit: to install the theme for the time being, download the patch manually, then in the wal_steam.py file, change the METRO_PATCH_URL = variable from the URL to file:///home/user/Downloads/UPMetroSkin-e43f55b43f8ae565e162da664887051a1c76c5b4.zip or wherever you downloaded the file to. Afterwards just run python3 wal_steam.py -w and it should work.

Would be great to find out why github is declining the download query and get a fix out.

[Tardog]

@JohnHuddleston Do you still plan to implement a retry approach for this issue? If you haven't found the time yet, I could give it a shot. Let's not have this lying around for too long.

[ghost]

Or just ship the metro theme with this repo?

[JohnHuddleston]

I just started a new job and haven't had time to really dig into it, but I'm pretty sure I can help make it a little more robust. The part of the script in question is on lines 246-253:

try:
    opener = urllib.request.build_opener()
    opener.addheaders = [{'User-Agent', 'Mozilla/5.0'}]
    urllib.request.install_opener(opener)
    urllib.request.urlretrieve(METRO_PATCH_URL, METRO_PATCH_ZIP)
except:
    print("Error: downloading needed patch file. Check your connection and try again.")
    sys.exit(1)

I work primarily in low-level imperative programming, so forgive the clunky C-like approach:

patch_dl_attempts = 0
patch_dld = False
# MAX_PATCH_DL_ATTEMPTS could be handled by a global definition or 
# could be configured with a flag
while (patch_dl_attempts <= MAX_PATCH_DL_ATTEMPTS) and not patch_dld: 
    try:
        opener = urllib.request.build_opener()
        opener.addheaders = [{'User-Agent', 'Mozilla/5.0'}]
        urllib.request.install_opener(opener)
        urllib.request.urlretrieve(METRO_PATCH_URL, METRO_PATCH_ZIP)
        patch_dld = True
    except:
        patch_dl_attempts += 1
        print("Error: patch download failed.  [Attempt " + patch_dl_attempts + "]")
if not patch_dld:
    print("Error: could not download patch file.")
    sys.exit(1)

Okay, so I implemented this in my own branch (https://github.com/JohnHuddleston/wal_steam) but I have no way of testing it until I get home tonight. If anyone would like to give it a shot, please do. Once I can confirm that this: 1) actually works and retries the way I want it to, and 2) definitely helps the script work in more cases, I'll request a merge. **EDIT: I also added a new flag in my branch that attempts to cast the input for -a or --attempts to int, if it works then the default is overridden, if it doesn't it remains at 5.

[JohnHuddleston]

Okay, so my branch is useless. For some reason if it fails, it's going to keep failing. It goes through the entire urllib request sequence each time, but the only difference I see is between runs of the script.

NEVERMIND, I FIXED IT. Turns out the error had nothing to do with temporary network conditions and everything to do with using a Firefox useragent header. I don't know why I didn't do it before, but catching the exception and printing it showed that the error was consistently an HTTP 400 return:

The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

I decided to try a completely stripped down request, no useragent specified, and now it works flawlessly. I'm on test run 30 right now, and it'll keep running for a bit, but I have yet to error out. I'll push the changes to my branch then submit a pull request.

[kotajacob]

Thanks again @JohnHuddleston I have now pushed out update 1.3.2 with the pull request added, both here on github and also on python's pip. This issue should be fully resolved as the useragent issue was fixed and a download retry parameter has been added (-a --attempts should you need it).