skizzosjt

Hi @AOR I re-read this, and now I know exactly what is going on! This is an eccentric macOS issue. macOS creates a hidden file prepended with "._" for every file. so due to you're putting your LaunchBox install onto I assume a NTFS drive connected externally, this will keep occurring. Said files must be getting accessed from Windows from the external disk, which reads them and says "what is this?!" because it's data is going to be nonsense to LaunchBox. The whole idea of running things through a VM is a bit of an exotic setup. Prolly should consider making a native Windows install and boot into that when you want to use LaunchBox I used to see this same thing occur all the time when I had one of my HDD's formatted as exFAT so I can share TV and movies between macOS and Windows. Drove me nuts to always see these ._ files everywhere in Windows. They are otherwise harmless, but in your case, they are a problem because LaunchBox is going to continually try and use them as a platform file.

it's impossible, you cannot put a playlist under a playlist. playlists can go at the root level, or under a category or platform. Some potential ways to set this up -Light Gun games (category) --Sony Playstation (Playlist) --Sega Dreamcast (Playlist) and so on... or if starting with platform... -Light Gun games (platform) --Sony Playstation (Playlist) --Sega Dreamcast (Playlist) and so on...

well I noticed the XML file is called "._Arcade.xml" ? I would think that is causing your issues. That likely is not a proper name. One would assume you mean to call your Arcade platform "Arcade" not "._Arcade". If you named it appropriate as "Arcade" it would create an XML file called "Arcade.xml" Otherwise the error is referring to the contents of the file. Literally the first character inside the file is a period "." per that error message and that is def not how it should be. Assuming there are not further issues, deleting the period would take care of that error. But, depending on how messed up the file is, a different error may pop up afterwards. Maybe due to what I am pointing out. Do you now have both "._Arcade.xml" and "Arcade.xml" in the data folder? guessing both are messed up, so it may produce throwing two errors

the light guns are seen as both a mouse device, and a dinput device. they are not a xinput device. not sure about what input API the tanksticks use though. check the user manual for your specific model, it should specify it somewhere. I'm not so sure the avg user would want them to go to P3 and P4 by default. then you got to remap light gun game controls to P3 and P4. likely cannot do that by core/system since I would bet most would be playing some standard conroller and light gun games that share same core. So would instead need to use directory or game level remapping. when you consider that, this default behavior of them going to P1 and P2 in my opinion is how it should be. TEC75 points out you can make use of Retroarch's device remapping, which has worked for me in the past. It's the same concept as device remapping in MAME (using the config files inside the ctrlr folder), using PIDs (product IDs) to identify the individual device and remap it's controls or player #. This does work, so maybe you went wrong somewhere? Unless you have a use case where you really need them on P3 and P4 all the time, it might not be worth the hassle to set them up like that. That lead me to share my point there is an easier solution with only plugging them in when in use

delete the red ones. leave the green one. the NES one without backup in it is 3MB in size so should have some data it in. If it does not show up you may have 0 games linked to that platform. the old one is dated from 2018, kinda obvious which one is the new one. or if you want to go this route instead..... yes, that's just starting that platform over per their date, got to think back to 2018 to figure that out.

Hi @Whatscheiser coming back with an update TVDB was back up later and script is working as expected so seems any issue with getting nothing returned was issues with their site/servers. Once I noticed they were back up, I had to recreate the issues you communicated and test my solutions. Good news, the issues are resolved. Found a couple other things and fixed them up too. Bad news, there is something funny going on with Modern Marvels. That is the most incomplete series I've seen on TVDB and I'm not sure if this is lending to the issue quite yet since I have not been able to recreate this specific issue for any other series. I created dummy files through the end of season 13 using the batch file renamer and was just shy of 600 episodes. Not once did it ever scrape metadata beyond part way through season 12, always ending at episode #35, Mountain Roads. The scraping loop is stopping prematurely, it should instead scrape the entire webpage the user provides. This explains why it acts like it is suddenly stopping part way through such a large series and why later seasons get zero responses. The scraping loop should only stop if there are no more "class names" to scrape, it would return an error that triggers the loop to stop. So, I know why it's stopping, but I haven't had enough time to dig into why an error is thrown at that specific spot. I will upload a new version as v1.1 to fix all other issues though. Hopefully will have time to do that in the next day. Then I will likely return my focus to working on v2.0, specifically get the beta test to you with relevant details. Thanks for your patience on all this stuff!

@Truest1 I experience similar behavior with light guns always going to P1 and P2. My approach is quite simple. The easiest way to deal with this is to only plug in the light guns when you use them. When you use them, you want them to be P1 and P2. So, who gives a crap where other stuff ends up when light guns are plugged in, it's not like you're using two light guns and the other devices like your xarcade tankstick at the same time. When you're done, unplug the light guns and your tankstick and other controllers return to their normal player # positions. Don't overthink things and take the path of least resistance, this is a "KISS" approach

I am getting no connection to thetvdb.com either. I would have to assume this is the issue with scraping not working until they clear this up and we know for sure. When I try the script just now, it doesn't grab any data from them. This is evident due to the "Total Series Webscrape Progress" count is only 1 rather than the number of episodes I think it should still find "S12E51 Coffee" assuming that is the file name, and "Coffee" is the episode's title. Last fallback is just the episode title, so that should work. I'll have to assume right now, likely part of this issue with their website. So far sounds like you stayed in the guidelines just fine. Sorry, this is another hurry up and wait thing before I can properly diagnose I also think I found the reason the network is being grabbed if the air date is absent. Gotta wait to test to know for sure. In risk of sounding like a broken record, I'll hurry up and wait to test lol. Kinda weird situation, I have been playing with their API in the last week, and it still works fine right now. So, they are must be having some issues that are purely website related. Not kidding you, I watch some of those Modern Marvels on youtube recently lol! It's interesting stuff! No judgement from me! Lastly, thanks for being willing to give the new version a whirl! I'm gonna get my ducks in a row on that and will shoot you a message with the new script and any details on what's new or different.

well that sure didn't take me long to find.....gotta love google and the internet..... might want to watch this thread

lmao pretty glad I snagged the newest copy of yuzu a few days ago....literally just in case of something like this. on the other side....wow....I did not think they would take this path. just a total collapse great.....fn Nintendo wins. what giant L for the emulation community. blame the literal idiots who did stuff like stream themselves playing games before they even released. too much negative attention was brought to project due to stuff like that. I got yuzu 1732 the other day (3/2/24) had I know Citra was connected to Yuzu I would have gotten that too before this went down. I unfortunately don't know any place hosting stuff like that

so to help explain, the Utilities > MAME tab allows the software to auto setup the stuff that is being discussed here. Hence why it asks for the path to the MAME exe and ini file. It's just remapping controls as every guide out there tells people to do by hand. Due to this discussion, I finally take a moment to see how this feature works, this software just automates some of the setup. For instance, soon as I click the enable check box it will edit the ini file, the most obvious edit being adding the Ctrlr config name, and when looking into your ctrlr remap folder you will see the newly created remap file. My point here is it's always better to know how things work rather than "I click this button and it works now....." and never understand the reasoning. So this is going to burst your bubble, it's bursting mine too......the software doesn't even do the controller (device) remapping as I assumed it did lmao. It is only remapping controls. I know that might sound the same, but it is not. All this software can do is "make trigger be player 1 button 1" kinda remapping. It does NOT do "make PID_1601 always player #1". so you have literally never even once needed stable controller ID's. I scan through the entire cfg file the software makes, no controller (device) remapping, just controls remapping. Here for ex the MAME ini edited, with the new cfg file created. Though, the contents of the file have no stable ID controller remap going on. Don't be fooled by the header, it is blocked off by comments so those VID and PID #s and Light Gun #1 business is like it's not even there to MAME. That's not even the right syntax to declare that stuff anyway Controller (device) remapping looks like this. They can be in the same file, but, this software only does remapping of controls. This is kinda lame it does not do this controller (device) remapping automatically too. And kinda proves how blown out of proportion this can be. You've been running for how long without one, without any problems lol. Obviously it's not needed for your use case. That's not a bad thing. Consider yourself lucky it works for you without any further intervention. So to be clear, this program doesn't remember anything about your lightguns being called player #1 or player #2 in MAME between reboots. You would need lines like the below file in your cfg file for that to be 100% guaranteed. For me, without this file, it normally assumes my two light guns are player #2 and player #3. So in my experience this reduces setup a little bit since I have less games I need to custom remap for. Better chances stuff works right out of the gate. When I enabled this feature in Arcade Guns, it broke my setup due to my light guns reverted to this issue for me being #2 and #3, further proving this utility does not do any device remapping

Hey there Whatscheiser, I'll address all your points here. I really appreciate the feedback you continue to give. 1) 400 episodes sounds like a lot. Largest show I know I scraped is 300 something episodes. The qty of episodes impacts the time taken. The script first scrapes all the relevant data from the website before anything else. So, it might act like it's frozen during that first scraping process since it's downloading said data. The message you got comes up when it detects a scrape is completed, so, it must have thought it went through everything. That can happen if you get no responses from the website. If it's still not working for you, that is strange, not like it went through some update and the code changed. To be clear for me, are you saying it doesn't work at all anymore, no matter the show or season? Doesn't work for a specific show? Doesn't work for a specific season for a specific show? 2) I actually thought I took care of ampersand character (&) as I'm well aware about that issue, but as I think about it, I likely did that for a different tool and not this one lol. That is a easy fix for me to implement, I'm kinda surprised I didn't run into that issue myself. Glad your hands on enough to understand the issue and fix it with a manual edit of your platform file when it occurs! 3) The air date not being on TVDB is bizarre. I wouldn't think they allowed incomplete entries like that (like at least put in the year rather than blank if exact date is unknown), but as I continue to work on this project I'm less of a fan of TVDB and more of a fan of TMDB now. After looking at TVDB's site with inspector, I think I know why this is occurring but I will need to recreate it to know for sure. With all that said, can you please provide an example of the 1st and 3rd issue, as in what show and season type are your scraping? I'll need you to please provide the URL address you enter into the script for both issues. In case you wonder, I don't need relevant video files on my PC. I can rename a bunch of files to mimic having them in my library for troubleshooting so this will give me a chance to recreate and hopefully fix these in a reasonable time frame. Now I actually have a favor to ask of yourself! Any chance you would be willing to test a brand new version of this script? As I alluded to above, I looked into using other databases to improve this script, and TVDB is not as good as TMDB (The Movie Database - which despite the name does have an extension database of TV series). So I am making this new version use their database, and it's using API rather than class names, among a handful of other improvements I hope users will like. It would be great to get some feedback on it, especially since you are already familiar with the current version. Please let me know if you would be into giving it a test drive.

prove to yourself you are using the proper commands by launching a game with the emulator directly from the command prompt. this will take LaunchBox out of the equation. if it's not launching a game from the command prompt it suggests you are not using proper commands correctly. if it does in fact launch a game OK directly from the command prompt, then it makes sense to look closer at LaunchBox settings.

marcosgaming is already using the correct AIMTRAK software that is meant for their specific light gun. they are different branding, but otherwise they both do the exact same thing. assign player #s, assign buttons, calibration, etc. I don't see a benefit of downloading another brands software, if it's even compatible. I wouldn't mess with it because I would believe firmware is not the same and if wrong firmware gets updated you may break them from ever working again. marcosgaming, in general the scope of questions you ask here and in PM is already shared in deep detail. I'll try to clarify some of your questions, but, otherwise, it sounds like you should return to existing guides to better understand the setup processes. this is totally up to you. there is no right or wrong way. you need to understand the layers you are going through though. if you set the gun's trigger to be button1 then MAME needs to have the trigger/shoot input be the corresponding button. if it were set to a mouse button in MAME, then that wouldn't work because there is a disconnect in that example. you pull the trigger, it sends "button1" but MAME expects "left mouse click", nothing will happen in that example. you just need to make said settings consistent between the light gun software and the game/emulator. on the same note, if the player 1 controls in a game are expecting inputs from "Gun 1", then that needs to be aligned between the light gun software and the game or emulator. for ex, if you have your light gun as player 5 in the light gun software, but player 1 in MAME expects inputs from player 1 (for ex "GUN 1") then that is a disconnect. nothing will happen. so hopefully you understand it is critical that things are aligned between these different programs. to fix that specific example, you either change light gun software to have the light gun be player 1, or in MAME make player 1 receive inputs from "GUN 5" the light gun is a mouse and controller. aiming the light gun is just like moving a mouse around. the trigger/buttons on the light gun can be mouse clicks, or controller buttons. meaning, any game or emulator that can receive these mouse and/or controller inputs will work with the light guns. you see "JOY" button in MAME because you assigned a controller button to that specific light gun button in the light gun software. given the info you shared, that seems normal. the other buttons may be mouse clicks and I think depending on how you do the device remap, should show up as "GUN". again, seems normal.

completely optional. you can choose to not opt into it. I always have it disabled. nothing sneaky about that. they ask you at setup of the emulator

well there was that fiasco with Dolphin not being released onto Steam. with some arguments stating the, I think it's considered decryption keys (don't quote me on this) were included in the emulator for Wii games. The article calls it "Wii common key" So they (Nintendo) are again citing the same offense. Anti-circumvention.....yet at same time allege they (Yuzu) didn't steal any keys. The anti-circumvention argument has some merit with Dolphin, which I personally think they (Nintendo) would loose in court. So this Yuzu ordeal sounds like it has even less merit on the anti-circumvention complaint. I think this has more to do with this conspiring....Aren't they gearing up for a Switch 2 release? If users can keep gaming through illegal means, less incentive to buy the newest console. Also some high profile games got leaked recently like Super Mario RPG was on the web several days, if not weeks before release. That kind of stuff they see as cutting into their bottom line. Nintendo is a business and like any business, they don't sell video games, or consoles, or services. They are in the business of making money. If they don't make money, no business exists. They could have went after Yuzu or the other Switch emulator Ryujinx years ago. Why now? Well, that's why I think now. But lets be real, that problem starts from within. Unless they got hacked, they have people working for them that are willing to sneak copyrighted and NDA software out of their facilities and studios and put it on the web for millions to obtain. Worry about that, Nintendo! Frankly Nintendo's argument could go after programs like LaunchBox / Big Box. They argue the software promotes and facilitates piracy. I've read the threads about Pay Pal regarding LaunchBox / Big Box not being able to do business due to the same exact view point. So, be careful for what you wish for if you're thinking Nintendo is in the right here. It will set the precedent to argue that software like frontends that promote and facilitate the use of illegal emulation, hence piracy, are just as bad and should be subject to lawsuits too. Frankly, dumber laws have been passed. If you want to keep being a fan of emulation, and in part, frontends, do not side or sympathize with Nintendo here. Period. I would take offense to that. Where the hell does Yuzu actually link to the product keys?! or even the websites that host said links?! That seems like a flat out lie rather than a skewed opinion.

I see the issue. It copies the default config Retroarch.cfg as soon as you go into "Process Retroarch" within the app. It takes Retroarch.cfg and turns it into "Retroarch.cfg.bkup" and then populates a brand new version of Retroarch.cfg. So, it does change overlays settings, turning them off, seems counter productive given what the app is. All I have to do is click "Process Retroarch" within the app and it changes my default config file. I don't even need to actually proceed with downloading and installing the bezels. Some of my custom settings stick, but others, notably input_overlay_enable = "true" is not even found in the newly created Retroarch.cfg. So, this certainly explains the behavior. I did test it just now, making sure 100% that this setting was enabled and present in the default config. I then go into Process Retroarch and it creates the backup file. I then check the contents of the backup file which still has input_overlay_enable = "true" in it. I then check the new default config and it no longer does. (makes some sense....so far at least) Then once the download finishes, another copy happens and I'm now I'm left with the default config and backup config being identical files (same exact contents and file size), except they are both the newly created config file version. as in no input_overlay_enable = "true" is present in either of them. Now we are at the part where it doesn't make sense, to me at least. Surely this is not what any user would want. Your app is changing my settings, in fact, flat out removing the overlay setting from the config rather than just changing its value. My experience with your app seems to contradict your comment. My overlay setting within the default config did not stay saved through processing. Either way, I really appreciate you taking a moment to respond. Thanks for the explanation! With that sad, consider it an area for improvement should you ever release a revision. The overlay setting should be getting enabled via your app rather than disabled. If I a missing something obvious and shooting myself in the foot here, like, creating this issue myself then please let me know where I am going wrong and I'll promptly insert my foot into my mouth lol

Windows App. That is at least what I can confirm is seeing this auto turn off overlays behavior. There have been a handful of users on here recently seeing similar behavior. Some were doing it through LaunchBox. I cannot personally confirm it's doing the same thing with that method, but given the circumstances I would hazard a guess both methods are seeing the same behavior.

potentially a flaw of the bezel project. every time you run it to install a new set of bezels it turns OFF overlays which seems the opposite of what you would expect. I just went through a resetup of Retroarch for several platforms and every time I had to turn overlays back on. ie install bezels for platform A, turn on overlays. install bezels for platform B.....overlays are off again.....turn overlays on manually. install bezels for platform C.....overlays are off again......turn overlays on manually, and so on. @dragon57 is this intended behavior? maybe Retroarch changed something over the years that impacted this? my assumption would be you would want overlays to turn on automatically. also, making assumptions you're the author for the bezel project, so forgive me if I am confused here. I know the OP indicates like they did this through LB running the bezel project, but I see same behavior when running it stand alone downloaded from the github. Referring to this one specifically for Windows https://github.com/thebezelproject/BezelProject-Windows/releases

there may be some better way to get to your goal, but I think a way to accomplish your goal to have multiple sources attached to a single game would be to create a custom field. maybe call it something like "Secondary Source". So if your entry for DOOM 3 has its source as Steam, its Secondary Source would be GOG. or just flip flop them around if it's the other way. then whether you search for Steam or GOG, the game entry for DOOM 3 should pop up in the results. the badge reordering thing sound like you would need to customize the theme to your liking.

not sure what to make of the errors, but in my experience, those symptoms (highlight a game and then get an error and crash) have meant a corrupted media file exists for that game. if that is the case you simply need to delete that file, or files, that are messed up. with LB closed, try renaming the \LaunchBox\Images folder to "Images1" for example. LB will no longer load any images. you can change the name back after this troubleshooting step. if you can then highlight the game without error/crashing, that would indicate that is the issue and you need to hunt down the offending file(s)

Make use of the startup applications feature You can select the file so it only launches if Big Box launches. This way it will not launch if LaunchBox is opened instead. But the catch is the file needs to be an AHK script that will do these basic steps due to the action must take place when Big Box closes: -Wait for Big Box to exist -Wait for Big Box to exit -Run the video file Just an example - better to run it through VLC rather than opening the video file as it will not close automatically that way without some further scripting tricks. Running through VLC you can use vlc://quit param which will close the video player at end of the video playing. and fullscreen param obviously does just that. WinWait, ahk_exe BigBox.exe WinWaitClose, ahk_exe BigBox.exe Run, \Path\To\VLC\VLC.exe "\path\to\video\file.ext" --fullscreen vlc://quit

LaunchBox and Big Box have separate settings for controller mapping. So, you should check your Big Box controller mappings. In Big Box it is instead called "Close active window"

did some more testing this week. I'm setup with Retroarch 1.16.0 as my main instance from a recent upgrade. I test with both LaunchBox and Big Box now with the newer Retroarch version. And though there are still issues with the startup screens as I previously describe, it didn't require the ALT+TAB input when a game is launched from Big Box. But it has constantly needed that type of input/user interaction if games are launched from LaunchBox and is so far repeatable with any core or game. So there is a noticeably different behavior between launching games via LaunchBox, or Big Box when using Steam Launcher, at least regarding using Retroarch. For Retroarch, I tested with systems such as NES, SNES, N64, Genesis, Master System. Cores would be nestopia, snes9x, both N64 cores paraLLEI and MupenPlus-Next, genesis plus gx So to summarize all testing so far, here is what I observe LaunchBox: Startup and Shutdown screens are both funny, they lose focus so you see the desktop/LaunchBox. Startup screens start OK, but lose focus prior to the emulator/game loading. Shutdown screens are delayed in starting, so you see the desktop/LaunchBox and then after X secs the Shutdown screen shows up. Retroarch loses focus at game startup so requires some user input to get it in actually focus. The emulator/game is visible and on top of all other windows from what I can tell, but just not in focus. As in, if I have the option to pause emulation if Retroarch is not in focus enabled, the emulator is in a pause state and you see the pause sign on the on screen display in top right corner. Big Box: Startup screens are funny in the same way as described for LaunchBox. However, Shutdown Screens, at least with Retroarch, behave as expected. I did not notice it to flash back to the frontend for X seconds before the Shutdown screen appears. Also unlike LaunchBox, Retroarch did not lose focus at game startup so no additional user input required prior to actually playing the game. Let me know if there are any additional specific things I can check to help pass along more info.

Yes, Retroarch was the emulator that lost focus at startup and needing to ALT+TAB as a result. I'm not sure of exact timeline of my testing I previously detailed because I did recently update Retroarch to newest stable release at time when I downloaded it, which I know is 1.16. nightly/dev version was at 1.17 but I went with stable release - I see 1.17 is now the stable release I will do some more testing because unfortunately for me, my memory is a little hazy on if I tested anything since this Retroarch upgrade. To be thorough on my end, I'll need to test some more on my up to date version of Retroarch. I can come back with some more feedback after I get that completed. I know when I made my first post I was def not on a recent version so I'll do my due diligence here for sure by testing with the recent release version.