sundogak

Assuming names are correct then either the media is in wrong directory or you need to refresh the images (in LB, select all within that platform view, then F5 or right click and select refresh). Assuming you have not changed the defaults in LB, then the ima ges are all in C:\Launchbox\Images\ So for say the Atari 2600 logos, then that is in C:\Launchbox\Images\Atari 2600\Clear Logos folder. Don't have to worry about the country folders if manually placing media in the subfolder.

Typically your ROM and Media names should be similarly named already coming from Hyperspin, so surprised LB isn't picking them up. But I haven't messed too much with Hyperspin, so could be assuming too much there. If minor issues with naming, then I found FatMatch was quicker/simpler. But if you have complicated renaming, Tur seemed to be "smarter" in matching and seemed easier to match files that renamer didn't know what to do with So, I might go with Tur in that case if got a bunch to do so you can see what the issues are with the ROMs vs your Media with the grid view. I didn't have to do much renaming, so I am by no means expert on either. Typically, any media packs I dumped in were about 90% there versus my ROM names and then I just let the Launchbox DB search and fill in the gaps. The one thing you have to get used to with LB is that once you get things imported and media to a place you like with LB seeing the media, then don't worry too much about how LB names things if you use the LB Database. It used to drive me crazy it didn't download files as the ROM name and named them like "Asteroids-01.png" rather than the ROM name but in the end it doesn't matter as long as the ROM and media are connected in LB so it displays. You can get a bunch of duplicate images in some cases over time depending on your importing check boxes you select if using the LB DB where for example you checked EMUMovies and LaunchBox DB to pull images can get multiple files of same type. But you can use the Tools, Cleanup Images feature in LB to delete any media that is not connected to a ROM in LB. Be careful with that Cleanup Images feature if using since it is a permanent delete and does ALL platforms (which I don't like, thus don't use most times without backup). MAME is only one I nuke the image sub directories completely when updating media (say going from MAME 202 to 203 media packs for Flyers, Snapshots, etc) since ROM names always match the media names if using proper MAME sets. Otherwise, as long as got all my media coming up for each ROM makes no difference on the name at that point. The Tools, Audit feature in LB is also very handy when doing all your initial imports to see what is missing on media.

LB will take the name of the ROM or the the name that is listed in the title when you look at the Edit Game view. So for example, if my ROM name is "Addams Family, The (USA).7z" and the clear logo is "Addams Family, The (USA).png" it will match that automatically and show up in LB. It would also work in this case if the clear logo was called "The Addams Family.png" since that is what it is called in the LB Database for Gameboy game. The "01, 02" referenced above is what LB uses when downloading and there are multiple media of same type in the LB and/or EMUMovies DB. You don't have to bother with the "01" if only have one media type for that entry (i.e., box, clear logo). My preference, if not using the LB DB is to use the ROM name, particularly the case for MAME and sets where there is consistency in naming. LB does have some fuzzy logic to a degree if not quite the ROM or game title where things are in brackets such as (Disc 1), (Disc 2). Where it does not match is if you have a ROM such as "Disney's Toy Story 2 Buzz Lightyear.zip" but the media is "Toy Story 2.png" or "Disney's Toy Story 2.png" it will not pick that up as match since too many word differences. In that case, you either have to manually match via the LB game edit view or fix the PNG and/or ROM name. You just have to decide what is easiest/quickest.

The Tools, Audit feature in LB will show duplicate ROMs in red. You can then just select and tell to remove and/or delete if you have LB set to delete ROMs.

Sometimes it is a ROM file name issue which doesn't match in DB or slightly different so have to select correct one and then will add media on next search. First thing always check is if each ROM has a LB ID assigned for ROMs first off the bat. If it doesn't, then will not know what to download. Easiest way is to toggle the drop down box and select "NONE" for Launchbox ID and then select all in that grouping and then go to Tools, Download Metadata and Media and follow screen prompts. The other tool for helping on this is the Tools, Audit feature which you can then see all your media info data for that platform in tabular form to which you can click on the columns to sort. So again, at end of that list is the LB ID field, if missing that is your first step. Otherwise, may not have media for that particular ROM and it means searching around via Google, Hyperspin site (forum has many forms of media) or LB site here. Once you start getting into computer platforms or pinball (Future, Visual, etc.) then LB DB can be sparse and it is a manual affair to find media at that point. But the big console platforms you should almost always find it in LB database and then some art (not always all items, but at least logo or screen snap).

@Asparky I like the images that you uploaded but have you seen version where it has the source PSD or graphics so can make alterations to button layouts? They work in about 90% of cases “as is” for my Xbox One controller but there are a few tweaks prefer to make. I am not great with Gimp and such but if had backgrounds and buttons could work it. Thanks.

@dragon57 you are awesome, thank you for making it!

Looks like a cool plugin. Really like the ability to see the available media in picture form since makes very easy to pick what want and weed out errors.

Thanks to all that are creating these rings. If anyone has time, the following auto generated AO.Bigbox.Plugin playlist types would be useful to have a ring made. Currently, I am using the "playlist" ring but something specific would be great. Frequent Random Recent Everything (EDIT: I found them in existing pack. For some reason not picking up in my theme. Must be naming issue). Rhythm (I don't see these in the recent Arcade MAME playlist rings but maybe I missed it) If only I could master GIMP and/or Photoshop! Thanks.

@latin625 I had some screenshots of working 5200 install on another thread. Might check and see if anything jumps out on your setup.

@fyrenthenimar They are in the Game Console zip pack (2.2 version). (edit: noticed later you asked for Odyssey 2, that is in there as well)

I assume you are using the 4DO core, right? If so, that core works with zip, 7z and CHD compressed formats. I just tried a 7z Battle Chess ROM set and it works okay. Inside the zip/7z files should be a cue and bin filed that is named correctly (i.e., your cue file references exact title of the BIN file. CUE you can open with text editor). You might try unzipping a file into a folder and trying to load the cue file uncompressed. Unless there is some issue with the 7z file or it was compressed with a bunch of subfolders inside. Other than that, if you said the zip files are working then you could use a batch file to convert the 7z to zip, but again, shouldn't be the case since should work with 7z as well.

Glad you landed on something that is working for your setup. Whenever possible, I try to use that format for CD games if the emulator will support. ePSX (standalone) is one of few found that will not play CHDs. The one advantage to CHD is it is a reversible compression process so can always go back to BIN/ISO if needed. One thing ran into recently is that the CHD.exe was updated to "V5" a couple MAME versions back and anything compressed in newer version has some differences. Most cores seem fine, but I found the Sega Dreamcast cores had issues. The Retroarch Reicast core gags on the V5 CHD compressed files although works fine on older compressed versions (which drove me crazy wondering why wasn't working on some and not others). Redream core works fine either way and Demul standalone works. I did see that there they have patches in works to update Reicast so they are at least working it.

Weird, it scans in my CHD files but skips the PBP files with Retroarch scan even though they use the same naming convention and the Beetle PSX HW core runs PBP format. I don't scan things into Retroarch since LB does what need it to do so never noticed. Maybe some sort of import bug since I can see it stop at the PBP files for awhile then move onto CHD files.

I wouldn't say better just what I used at the time but both will give same results. The Dolphin one is more convenient to use if already have imported the ISO/GCMs. But either tool will work and compress to GCZ or un-compress back to ISO (or GCM which is just ISO with different extension). GCZ files for both tools compress to same level (at least based on a quick test of two games I did). You can multi-select in Dolphin and compress so that would easiest if already have Dolphin up and running. Oh this was a good link I found that helped me along the way with all the format craziness.

Well, ultimately when compressed mine that is why I went the CHD route since I missed you could do any batch method with PSX2PSP. Other than my multi-discs which I did convert to PBP, all rest I bulk converted to CHD with batch script. However, the CHD route doesn't work with the ePSX standalone emulator, only the Retroarch core.

No, you are not alone in the above limitations. I did the same thing on a test install with various re-importing cycles and found the same thing. I actually dithered on if should go back to a backup and not use the feature. Basically, as you observed, for all practical purposes one cannot make any additions or changes or they will be overwritten (including game deletions). I tried a custom field (so could put a flag in or additional info) and those also get reverted to blank upon a re-import. It does remember the check box fields such as favorite and hidden as long as you don't delete the game in between import cycles. Additionally, if you click on a game and get the metadata from the LB Database, that data will be overwritten with the MAME developed meta data upon subsequent import. You also have to watch that don't update with the LB DB Genre and Play Mode fields since don't follow the "MAME way" of things. Of course, easy to re-import to fix in that case. I did find that if you import a group type, say the "Casino" group and then delete all but a few and do NOT select the "Casino" group on future imports it doesn't touch the the existing Casino games or add in the other ones. Seems logical but was trying to not have to sift through things to re-delete again. However, of all the issues the biggest one for me is that if you do delete games within an import group it will re-add them again since no permanent flag assigned so will pop in again. I tried adding the "to be deleted" roms to a playlist thinking maybe it might keep the playlist intact but it removes playlist entries if you delete a game. Again make sense, but was trying to figure a way of nuking the games had no interest in easily after each update without having to go one by one. The only way I came up with was the playlist route again where I spent time to move ones didn't want to the list and then hiding. They will remain hidden and within that playlist on subsequent imports as long as don't delete the game. The only problem with that is there is no feature to hide a playlist from Bigbox, so I had this "zzzz-Lame Game-zzz" list in my setup. I figure I could brute force it by copying the playlist xml file after moving games to playlist but just before deleting and then replacing that playlist on a re-import cycle but that is a bit of a fiddly process and will likely break with a MAME ROM name change. I like the genre and play mode Mame metadata but the game info leaves a lot to be desired and in many cases the LB DB has better info. I just don't like the format of some of the data they use like, "XYZ. released 3 different machines in our database under this trade name..." So right now, like you found, if you want to do any customizing of the info the re-import is really not an option. A "lock" field box would like resolve the problem but not sure if that is even on development horizon.

There is the create folder option that allows using the game title that might work. You could then use the import feature within LB to use folder title for import rather than the ROM title. Not ideal but one way but would be quickest without having to go to second step with a file renaming tool.

Looks like you can batch convert with PSX2PSP, see When went back and looked at the PSX2PSP folder there is a "batch mode" script that somehow I managed to miss that obvious link! Although seems issue is that uses the Sony game number and not the title.

One other thing to try and meant to mention in earlier response is to go to the ..\MAME\CFG\ directory and rename/delete the "default.cfg" and try again. In theory it regens the default file automatically but something to verify. Also check in same directory that the game you are testing doesn't have any unwanted controller mappings in it. Beyond that not sure why wouldn't be taking the CTRLR file (whatever you decide on using) as primary other than trying a vanilla install of MAME in test directory somewhere and working backwards.

@Buddy Dacote I tried that "kinks" ctrlr file you referenced in the link (I hadn't realized could remap multiple ways in one file by machine type so that was cool). I use a XBOX One wireless as well so our setups are similar. It seems to remap with keyboard and joystick as expected (see screen snap of 1944 CP1 controller maps vs Neogeo game where can see the buttons are remapped based on machine type) when tab in using the "kinks" ctrlr file. So you might double check a couple areas to verify pulling in correct file. It sounds like you placed the downloaded cfg file into the ..\mame\ctrlr directory so that is first item. Then in your mame.ini file check that the file name is the same but don't include the CFG extension in name. I had an existing cfg I had made called "xbox2player" so I just renamed the downloaded one to what I had for testing. As long as the mame.ini reference and cfg file match it should be golden. I don't necessarily like all the mappings of buttons with XBOX controller but may borrow some of them items they I had in their file. I had a much more simpler one (just two player only) \ which like Neil9000 and Lordmonkus stated above, typically works for bulk of the games. Either way, you will want to get the ctrlr mapping issue figured out so whatever mapping choose is fixed so MAME doesn't have issues of resetting controller maps if forget to turn on controller before launch MAME. Edit: As I was messing around noted (at least) the following problems with the "kinks" file. 1) Don't map the right stick at all, so problem with games like Robotron where just run around but cannot shoot...death results quickly! 2) there are extra spaces in the select and coin commands which seemed to cause funky results when starting games (stopped when deleted them). The Neogeo machine also had some extra spaces in the button commands. 3) they used a "remap" set of commands to map the UI arrow keys to the number pad in start of file. Don't see why since arrow keys not used anywhere else, plus they use the incorrect command for number pad key binding so number pad up/down don't work anyway because have extra "_" in them. 4) pedal/paddles don't look quite right but didn't try them. 5) the player 1 keyboard bindings were removed so would have issues if using for say Apple II emulator game with keyboard (i.e, Castle Wolfenstein).

The Atari800 core should auto load the game without having to go into the emulated 800 menus. It sounds like the 5200 isn't selected. I have attached a couple snaps of a working install of 5200 in Retroarch with the Atari800 core. Might double check the Atari 5200 system is getting saved as default in options window and verify in the core options file (snap below). Lastly check that your ".atari800.cfg" file that is located in the root of the Retroarch directory is present and has correct paths. I have attached a copy of my cfg file so you can look at. It has the ROM paths to the System directory so you should be good there but good to verify it is pointing to where expected. It typically is auto-generated but my recollection is that it was "fiddly" when setup. If all else fails I think it was the Atari systems that were picky about the ROMs being same case in titles as expected (may be mixing up Altirra but doesn't hurt to verify). In my Retroarch core options this is what is saved for the 5200 emulatorThis is the .atari800.cfg file location. I have attached my copy of working file but you will have to adjust the paths to the roms according to your install. .atari800.cfg

I originally wanted to stick with PBP for the PS1 since ePSX is not compatible with CHD and likely will not be anytime soon based on some comments made by the developer in their forums. Size wise they are fairly close but CHD being more efficient. However, the deal breaker for me was that the only tool I could find a few years back was the PSX2PSP tool. PSX2PSP is not a batch tool so you have to do each game individually (at least I couldn't figure out how to do in mass). see For the 30 or so multi disc games I had that was okay but it gets tedious real quick doing one by one. Maybe there is a batch PBP tool out there but I didn't find. So that pushed me to CHD where could easily batch convert and/or use my MAME Software CHD set which I already had with no conversion. If there was a batch tool, I likely would have stuck with PBP. So really just up to how much time you want to burn and/or how many games have. ReDream supports CHD via Retroarch core and via the main ReDream emulator. My understanding based on the Retroarch News is that ReDream core is still work in progress relative to the Reicast. In Retroarch, if you ever want to see what file types a core supports, go to "Information" and then "Core Information" within Retroarch and will note. On GameCube, not sure on that. Mine were ISOs >>>GCZ. I never saw (but wasn't really looking at time either) a GC WBFS container. Only my Wii files are in WBFS. To some degree, I was less worried about the "best" compression as long as they were close. Convenience to convert and emulator compatibility became key considerations. I didn't mess too much with worrying about compression for Wii U since I only have a few games (mostly as a curiosity just to see if could get running). Once start getting closer to current generation of consoles things get complicated beyond the compression aspect. CEMU is a cool piece of software but my experience was it took lots of fiddling around to get most to run in good state and it takes a fast computer. My Switch has most of the games I would want on Wii U anyway. ? So not much help there but the CEMU site and Reddit may be best bets for info.

Hmm, the PBP files work in my (non-Retropie) build using either ePSX or Retroarch core. Not sure if there is something different with Retropie. Where you using PSX2PSP (1.4.2) to convert them? My only suggestion would be to re-crunch them again and make sure the BIN files are selected in proper order. I used the default settings in PSX2PSP. Oh, what was the game title you were trying to run?