Nielk1

(I'm actively uploading more logos so my numbers are changing, but clearly something's gone wrong.)

I had 121 clear logos uploaded in the past but I notice that now my approved changes is 0? Even weirder, it says my proposed changes number 3, but I only have 2 current proposed changes. Did something in the database break?

OK I'm officially at a loss. I might need to just try to fix some of the other more minor issues and see if it fixes itself. Also, add even more logging.

@percybuttkins This is interesting on 2 levels. So, it's dying when it is trying to check if a shortcut is in Steam. What's interesting about this is what code path it is on. If it cannot communicate with Steam itself, it will try to read the shortcuts.vdf and scan that for the shortcut. For some reason, the program is failing to communicate with Steam to ask for the shortcut and is instead using this alternate path. Additionally, something is wrong with it's reading of the shortcut file, as when it attempts to access the items in the file it is crashing because there are no entries in the file. Your shortcut file looked fine when I checked it.

@percybuttkins That's... interesting. It looks like instead of calling the ToString() function of the Exception, it just wrote "ex.ToString()". That's... unique. I'll upload another build in about an hour that will still have an error but will hopefully actually say what the error is. It will be version 0.0.4.1 . EDIT: Actually, the line after it might give me a clue as it's the Exception message and it did print properly. Oddly, it doesn't really help explain the issue. EDIT 2: https://github.com/Nielk1/GameLaunchProxy/releases/tag/0.0.4.1 This should throw the error with a bit more fanfare in the log.

As a side note, I am now having issues with the 7z dll I indicated to utilize with the tool. If the library scanner is not looking inside zips like it is supposed to (the name system is being confused by archives that LaunchBox is extracting) try changing the 7z DLL setting in GameLaunchProxy to the 7z.dll that comes with LaunchBox. Also, I know the browse button on that field is a bit fiddly, I have fixed that for 0.0.4.1 but am not going to push out a new version for 1 little button acting odd.

Oh wow, so it really was 'ghost borders', but it was cause by your own code instead of by .net's.

@percybuttkins So, it wasn't the VDF file, hilariously enough. I think I fixed it anyway. I also added logic to write the Exception to the log if it happens again. I've also updated the data scan and UI to be compatible with LaunchBox's new database format. It should work properly for both LaunchBox.xml and the new Data folder. Note that when using the new Data folder the "Scrape LaunchBox" button will allow you to scrape the entire library with a left click or a specific platform with a right click. This is useful if you need to update the name cache for just one platform. The new version is numbered 0.0.4.0 given the scope of changes for LaunchBox. It can be downloaded from the github release page. BTW, you can load the existing *.json files from the program's folder with the new version. If the data format changes it *should* load them anyway and just drop the parts it doesn't understand. You will want to re-apply the LaunchBox Library setting if your copy is using the new library Data folder. If you are not using that version yet, please let me know if the program has any issue using the old library.

@Jason Carr It sounds like you've already done everything you can then. The only benefit of further threading would be preventing the UI from becoming unresponsive during certain operations, which is only worth doing if you can do it. As the data is being used with arbitrary selections you can't really benefit from a hashmap either, unless you generated a key map for every query-able attribute, ew.

First I apologize if I repeat things others have said, I've not had the opportunity to read through the whole topic. I am seeing improved performance but it's still painfully slow for me in some cases. I know for a fact my issue is related to the size of my library as my Steam.xml alone is 15 MB. I've done checks of file IO and CPU load and such during my freezes and general slowness and know it has nothing to do with I/O. From what I can tell, the issue is with the in-memory XML data. My guess is that your data is optimized for serialization rather then access and modification, probably stored still as XML even in memory, perhaps abstracted through a DataTable or EntityFramework interface. I understand that the XML based system allows for other tools to easily access the information, as well as make it easy for people to alter the data if needed externally. There might be some value in custom writing your deserializer and serializer for the XML (not write your own text->data reader, but use the existing DOM parser and then convert that into custom data-structures optimized for speed). Additionally you might be able to turn off validation on the XML for a speed boost at the cost of integrity. For work I am currently programming APIs in C# that need very quick response times, so I can try to give some general suggestions for speed. It might be worth using async tasks to prevent the UI from freezing during a change. Right now I am seeing a minimum 3 second freeze of the entire program when selecting a platform with only 1 item in it. I also see the same freeze when attempting to update any information, including the playcount when I start a game. (Though, it's not too bad when starting a game since it does not prevent LaunchBox from starting the game in question.) If possible, pushing whatever action this is off the UI thread would definitely help. I can see you doing it with anonymous one time delegates attached via a function parameter on the event trigger. You'd also probably want to lock some UI elements that allow for data altering and unlock them in said delegate if you don't go the custom task queue method and instead just the async delegate UI block prevention method. You might want to look at a memory cache or optimized file/data structure cache that is faster. This cache could also be an actual database, but then you'd need to sort out how you wanted to ingest or outgest the XML. If you make it so external updates can't be made via the XML, then you can simply dump the DB out to XML on exit or via an export command. If you use such a cache and thus have a bifurcated memory model, you would need to put the XML updates on a deferred task queue for a dedicated thread to chew through or you wouldn't gain anything. If you do go the database method it would probably be worth using a connection string in the app.config that defaults to an SQLite file but has support for other databases for those that want to go a little crazy (me).

@percybuttkins I've downloaded your files. I'm a bit busy at the moment to go through the debugger to confirm, but looking at your logs now that you are on the latest version (which logs a few more details) I am pretty positive it's an issue with my shortcuts.vdf reading code. I'll reply again when I can get away from my work and computer issues to fix this. I wanted to be sure I let you know I got your files though and that I have a lead on the probable cause that I just need to confirm. (My computer keeps randomly shutting down if anyone's wondering what my computer troubles are.)

@percybuttkins I can't replicate your issue locally. I've tried direct names without issue with the renaming logic disabled. I've passed in names I had shortcuts for and names I didn't. When it couldn't find a shortcut it fell back to SteamProxy, when even SteamProxy was missing it threw a nice error message box. The thing about "%platformname%" and "%gamename%" is that they are handled well before your crash there. Additionally, the user input is updated via replacement if it contains either of those keywords, after the replacements are done there's no logical difference between having or not having those keywords. My only thought is that perhaps it's choking on your shortcuts.vdf file for some reason. You might need to pass me that file from Steam if you don't mind.

I need to debug the shortcut selection logic. I'll do that after work in about 5 hours.

@percybuttkins No that should be working. Can you post a log from the attempt? Is it throwing any message boxes up or just closing?

@cammelspit I had overlay issues with Vulkan, but I was doing a lot of odd things at the time. I bet I can fix your friend's Netflix issue with just a better designed BAT file for them.

So, if you have the overlay you can edit a game's controller settings mid game, but if you don't you have to fully close the game to edit them? I'll put that on my list of things to look at trying to improve. I think if I could make a function that allows for the SteamProxy to throw up a DirectX based dummy window it could hold the overlay for editing in game via switching to it. As cammelspit indicated, using the RetroArch version of an emulator will work with the Steam Overlay for sure, as RetroArch uses an OGL renderer. (Though RetroArch forces the emulator to render at it's native resolution and then upscales it itself, which might be sub-optimal in some cases.) RetroArch actually has a bunch of modes in it, OGL, DirectX, and even Vulkan. However, there doesn't appear to be a Steam Overlay for Vulkan yet.

@percybuttkins It's possible that the emulator in question does not support the Steam Overlay. The program needs to be running OpenGL or DirectX for the overlay to work. I don't know what Steam does with controller profiles when the overlay doesn't work as I don't have a Steam controller yet. It's also possible that the emulator has thrown off another process instance that isn't a child of the original and thus isn't in the line of succession for the Steam overlay, but that's quite unlikely. @cammelspit What happens with the Steam Controller when you play a Steam game that's not compatible with the overlay, for example the original Binding of Issac? What happens if you launch notepad via a steam shortcut and try to use the Steam controller?

@percybuttkins I've posted a new 0.0.3.1 release with more logging added after the last line in your log. It might help us find the issue easier. @cammelspit I've made an attempt to fix Issue 4, however this makes scraping the LaunchBox Library much slower. Any zip and 7z files will now be inspected for cases where LaunchBox has extracted the archive before passing it through the proxy. Note you will need to download a copy of the 7-Zip Extra archive for 7za.dll, use the 32 bit version.

Version 0.0.3.0 uploaded as source code and binary release to GitHub. Note: Command line parameters after -proxy will be executed as written. For proxy commands such as -name and -fallbackname values may be enclosed in quotes. The value must be enclosed in quotes if it contains a space (as spaces normally separate the parameters). This is normal command line behavior that all programs should use, but some emulators are weird. This is why the proxy preserves the command after -proxy as written.

@cammelspit OK that makes sense. I now avoid doing any logic at all in the process launched by Steam because of that forced close behavior. The name back is now done in the outer proxy. I've also swapped out the logic for an active loop as described that checks if the process is running every second. When I release you will have to let me know if that causes any issues. The new system reads shortcuts right out of steam's shortcut config file and has perfected shortcut ID generation. I discovered I needed to specifically use a UTF-8 byte array where my logic was trying to use an ANSI char array, Game names and paths with symbols and non-standard characters should work now. I've set it up so that the steam data file is not removed until after the shortcut name is restored, so now when the proxy runs, if it sees an old steam data file is hanging around it can find the shortcut with the old name and fix it.

@cammelspit Does DeSmuME also hang open, or just the proxy? I'm adding logic so that the proxy will try to correct when run if it was terminated early. The new GameLaunchProxy will wait on SteamProxy.exe if it finds it within 10 seconds of telling Steam to start the game, otherwise it will quit out. The current implementation has it looking for the proxied program instead, so it would try to find DeSmuME.exe, or whatever it's called, and give up if it didn't see it for 10 seconds. What it sounds like is happening for you, is that GameLaunchProxy.exe is finding DeSmuME.exe and calling WaitForExit, but for some reason it is never continuing. I am not sure of how WaitForExit works; it might work via subscribing to an event similar to a concurrent construct called a Monitor. Even with the new code waiting for SteamProxy.exe, the issue could still occur. I will try replacing that logic with a loop that checks if the process is still valid every few seconds instead of expecting the process to inform it that it has closed. I am adding a dummy shortcut adder that handles the "[Platform] Game" naming scenario. It seems quite sensible. In the future I will add something far more flexible but for now just hard coding the formats for the dummy shortcut generator is fine. The dummy shortcut generator is a fallback that shouldn't be used unless the rename engine dies anyway, so having it develop a little slower is fine. I'm thinking it might be wise to also make the system able to discover ICE entries on it's own and use them instead of the proxy app if they are appropriate. That is a future plan though.

@percybuttkins The currently released versions of the proxy program is pretty tough to use. I've taken all of the issues and tried to rework it for the next version to avoid all of them. It might still need a guide, but it's about what buttons to press now instead of complex manual tasks. I am still a bit confused by @cammelspit's issue where the proxy gets stuck. The system latches onto a process and waits for the process to stop, but for some reason it seems to be getting stuck for him. I might need to fix that by adding a sentinel rather than allowing .net to do the sentinel itself. On my TODO list before 0.0.3.0 is ready (and I might change the number to 0.1.0.0 as it won't be able to use 0.0.2.#'s or 0.0.1.#'s config files): Restore original functionality such as font loading. This is what the proxy used to do before Steam was a consideration. Add manual/custom game name and platform name list. Right now only the LaunchBox scrape is in with an option to rename platforms. I might skip this for this release as we're all using LaunchBox. Improve the ICE like functionality that adds dummy shortcuts to Steam. I might skip this for this release as it's the fallback system for if Live Shortcut Renaming breaks. Live shortcut renaming is working at this time and as I use the beta Steam client I'd be one of the first to know if it's going to break. If you have any suggestions, now's the best time to make them.

I've personally not seen anything with DPI, I just bring it up since it's a known WPF issue. It causes unusual scaling but not ghost borders. I am thinking I might run my entire image library though a png optimizer just for sanity's sake and for size reduction.

It's odd, you'd think triggering it to draw the image as tiled+flipping would solve any sort of issues since there's no missing data to extrapolate a border from. I guess you'd need to inject that logic into the actual draw logic which is abstracted away from you at that level. My only idea now is to check the DPI of the PNGs to make sure they are 96dpi. My experience is with WinForms and ASP.net so sadly my experience in this area is a bit tangential. It seems like you need to somehow inform the renderer of data outside the image render area (hence the above tiling hack) at the time of the rendering. Like if you added that transparent border but then somehow cropped it out while the actual render logic still knew about it.

It's funny, at first I thought it was resolved looking through my wheel but I recently saw one. Placebo effect? Perhaps adding a 1 pixel transparent border to the images would work?