sundogak

For the newest LB version 13.15 the only thing that matters is you have RPCS3 games installed within the emulator along with any DLC/updates and that auto import is turned on in LB. LB then uses RPCS3 emulator to determine which games are installed vs what files are within your roms directory. In fact you must not point your path for games within LB for the PS3 platform to your PS3 roms in that case or it winds up importing everything. Point the games path to empty directory and make sure LB has your emulator path correctly set. As we just went through this with the beta, they fixed a glitch where it was importing eboot.bin files for the updates and the original main game (as emulator sees them). LB now prioritizes the update eboot.bin if present.

For the emulators, you don't have to put them where LB wants. If you do the auto install it does place them in LB\emulators by default but you can point to any location. What you do is up to you but should be consistent for all emulators or gets confusing. For my setup, I do not put ROMS or emulators in the LB directory. Regardless of what you choose, once you have setup your application path that is where LB will then save any updates for future. So in case below, I have an update pending for PCSX2 and it is not located in LB\Emulators directory. If I hit update it will update in path I have selected in Application Path. If you decide you want to move an emulator to a different directory than what originally selected, then do so within Windows file manager (i.e., copy/paste folders). Then go back into Tools, Manage, Emulators, and update the path to the executable accordingly. The key thing here to remember is the location has nothing to do with the "monitoring" aspect in LB. LB does this by polling the executable which is listed in the application path. Now as to the monitoring aspect. That is a new feature in LB and isn't fully applicable to all emulators. Your example of 4DO is one where LB has a box to click to download but it doesn't automatically monitor the executable for versions. In screen shot above the non-checked emulators in Status are examples of emulators that LB does not yet have "monitoring" functionality yet. As far as ROM locations, again you can do however you want. LB isn't any more efficient one way or other. My 2 cents is you pick a logical process and stick with it. Personally, I use the completely separate folder structure for ROMs and Emulators. I have a "G drive" which has each platform (or emulator) and then the "roms" within that folder. The key for LB, especially with the new auto import feature is you have a structure where your ROMS are within an isolated directory per platform/emulator (see example for Atari 2600). ROMs are then within the next folder depth: Not really sure on your question on "separate drives" but again LB doesn't care where the files are located. You could have files on different paths or multiple drives. For ease of use, you are better off keeping things as simple as possible but for example if you have some larger files on a "H drive" then as long as LB can see it when it launches then no issues. How you name the folders is again up to you, LB doesn't care as long as you have pointed paths correctly. To give you point of reference here is snip of some of the rom locations for some of my platforms to give idea. Again, this is way I did it but consistency is the key item on any naming you do. On Retroarch, it is good for many things and I do use it for maybe half of my systems. Like all things use what is easiest and gives you performance for your system. For most of the earlier cart based systems I find it is easiest to use. For MAME, recommendation is to not use RA for that. It just gets way too complicated but people still do. But other than MAME, for most part if RA has a core for it give it a try first. Some RA cores lag behind their standalone counterparts but for most of us it isn't a huge issue.

So if you right click the Vita platform and edit platform the "Game" entry at top is pointing to a completely empty directory (no subfiles, not pointed to UXO directory)? It looks (just based on screenshot) that you are still pointing to the \uxo directory. And your Vita3K emulator has all the games installed and launch from outside LB?

There is option when delete to not remove media. That is what i used. Everything matched back.

Neither do I. The key thing is that that the path in LB is to your exe and that LB has auto filled in the appropriate command lines for Vita and RPCS3. Other than that you can place the emulator where you want.

Path is changed in LB in Manage Platforms under tools (not Vita3K). Change to dummy folder that is empty. Doesn't matter where as long as no data/roms in the folder.

Yep, same for PS3. Two red circled directories are completely empty. As long as you have games imported in the emulator it will pick up. If having issues with Vita still make sure directory changed, delete the platform for Vita. Then close out LB and restart. Should then within few minutes pickup any games in your Vita3K emulator and import.

Don’t point your Games directory to your Roms. Point to empty directory. LB uses the emulator data for Vita3k and Rpcs3.

Yeah for CHDs like you mentioned I "skip" steps as they are one big file vs roms with parts inside zip. I use torrent check to make sure it is just that one file (or if they renamed it). As just ran this, here was torrentcheck output showing I was missing that new file in my 266 version: TorrentCheck v0.9e Report file ------------------------------ File check/size check: File not found: "T:\Downloads\Complete\Torrent\MAME\MAME 0.267 CHDs (merged)\cuttherope\cuttherope.chd" Correct files: (994/995) - Missing files: (1/995) - Wrong sized files: (0) - Successfully trimmed files: (0/0) - Deleted wrong sized files: (0/0) Attempting to find missing/renamed files: Fixed missing files: (0/1) I just downloaded that one file directly and copied into my 267 CHD folder. Did a quick recheck (as it checks the hash to make sure exact same file MAME expects) with TorrentCheck and came back complete. TorrentCheck v0.9e Report file ------------------------------ File check/size check: Correct files: (995/995) - Missing files: (0/995) - Wrong sized files: (0) - Successfully trimmed files: (0/0) - Deleted wrong sized files: (0/0) Unneeded files check: Unneeded files: (0) - Unneeded directories: (0) - Successfully deleted files: (0/0) - Successfully deleted directories: (0/0) Then you don't have to bother with slowest step which is the rehash check in your torrent client. For CHDs that is easiest as long as you keep a relatively recent version as they don't tend to add many version to version.

There are two different things getting talked about here. One is updating rom set. Other is updating MAME executable install. They are independent. Generally speaking you should align your versions and romset but within several versions either direction where your MAME exe is newer than rom set (i.e., using 0.267 MAME exe for a 0.266 rom set) the MAME planet will not stop revolving. If get too carried away eventually things will break as the EXE will look for romset checksums that may not be present in older set (among many potential issues). Hence better to keep in sync just to avoid potential issues. Updating MAME install from 266 to 267 is easy. Take the file here , open in 7zip, drag and drop all files to your MAME directory (Replace files when asks). You now have a 267 install. Your existing setup files remain. There are no settings files in that pack so your setup doesn't get overwritten. It doesn't contain a MAME.ini, or do anything to existing NVRAM files or CFGs (other than default presets). You don't need to move any folders as nothing user specific will be overwritten. You also don't need to tell LB anything as you are using the same name for exe. Same for artwork, the update folder is empty in the MAMEDev update file so doesn't make any changes to existing files when dumping a new MAME version onto older. For updating romsets you are either doing via CLR MAME Pro (or similar rom managers) or via TorrentCheck as discussed above. But each is separate from other. One thing on torrentcheck method is the longest part of process is the recheck within your torrent client. Particularly for the software list packs. To give realistic example: I just did update for 0.266 to 0.267 rom set. It took about 10 minutes for Torrent Check portion (get torrent file, do TorrentCheck run. But it took 20 minutes for the recheck process within Qbittorent. The actual download of delta files was 5 minutes to make complete pack. But only the first part requires your attention as rest is all auto. I generally avoid doing a recheck within client on the huge Software CHD as it takes a LONG time.

The easiest way is to use a tool called TorrentCheck (particularly if using the PD sets). Google as one word and should find the download. Let says you have existing complete set: MAME 0.266 Software List ROMs (split) I rename the directory by only changing the number for new set: MAME 0.267 Software List ROMs (split) It is critical to use same naming as torrent used or the torrent program won't check/join but will download the whole thing. Then drag and drop into TorrentCheck your path to that 0.267 folder. Drag and drop you torrent file for the new 0.267 pack (not DAT, the torrent file*). Check the boxes "delete wrong sized files" and "delete unneeded" along with "create backups" (always use this if mess up your originals can be restored back). The utility will then remove anything that is no longer in the torrent. Using the "attempt to fix/rebuild" option helps if just a rename change (this can slow things down). Once completed you will then join (do a recheck) the 0.267 torrent in your torrent download program and it will only download changed files vs doing the whole thing over. It is far quicker than using clrmame pro and in essence is doing the same thing. Keeps the unchanged files. Removes old stuff. Download the deltas. *note that PD uses magnet links. Using qbittorent I have torrent files set to be backed up. If you start a "new" torrent using magnet it will after a minute or so download the torrent file to backup directory (basically when you see it start to download anything). You can then use that file for TorrentCheck and later for downloading. There are some magnet to torrent tools but I never could get them to work and this always works and adds maybe a 5 minutes of time (software list MAME is a complicated torrent file so takes longer for that one).

There is a workaround to "exclude" certain platforms with auto import on. Your points are valid, particularly #1 and for anyone who has Exo packs installed. They were many of reasons I avoided turning auto import on as it messed too much up. However, during the 13.15 beta I wanted to test things so found this workaround. You point any platform that you don't want to have auto import function to any empty directory (see critical note at end). In my case I do not use the LB\Games directory so that is where I put the empty directories as LB generates them anyway. Figure 1 shows how to turn off platforms for no import. For simpler platforms where auto import works reliably then you point the Game platform directory to your roms location as normal (Figure 2). Example below: Figure 1) anything in "Games" LB directory is empty and "off" as nothing to import [I don't put my roms in LB directory, where you place is immaterial as long as empty]. Figure 2) where you want auto import to work point to path of your roms directory like normal in platforms: There are three special cases so far as of the new 13.15 release: Vita3K emulation for Sony Vita should point to empty directory as LB pulls the games list from the emulator. (applies to 13.15 forward). If you point to roms directory it will pull in tons of extra stuff plus the games it sees in Vita emulator. PS3 emulation via RPCS3 is the same as Vita, point to empty directory as pulls data needed to import via emulator (applies to 13.15 forward). Similar issues as Vita if point to a directory with PS3 games. Note they did fix the "sub folder" and app/updates issues in PS3 similar to Switch so suspect that should be something to see in future updates. ScummVM which should point to game platform where scumm games are located as LB uses the path naming to figure out which ScummVM game is needed. Lastly there is one important rule if you decide to do this way: you cannot use the scan for removed roms for any "dummy" platform locations or for all platforms as LB will delete your LB entries. I would weigh in/pay attention during beta rounds as they seem to be working down the list of special cases like you mention in each update so having people test is critical.

On the release version found this was still not working. However, I found I had to completely delete the platform as I had one game installed as test originally. I reinstalled the Vita3k emulator from LB perspective as I didn't change anything with Vita3k emulator itself. Closed LB. Then reopened LB and it then added the platform and the missing games including the one I had originally manually installed per the "old way". I didn't change anything as far as the platform game location in LB (still points to dummy empty folder). As a test setup with 13 games, nuking the platform wasn't a huge deal (and I had tried that during the beta as well). So maybe something got fried during the beta tests and/or improvements somewhere fixed the glitch. Others mileage may vary.

JoeViking245 posted ahead of me and echo you are best off just picking games you want. There are two lists from the site referenced as has a handy export feature: MAME search - ADB Working only CHD Games.txt (58 games working with CHD games) MAME search - ADB Working + Imperfect CHD games.txt (100 games working + imperfect CHD games

I cannot get LB to auto import Vita games. I assumed it was similar to PS3 that works well at this point. Auto import is turned on. I have Vita3K installed and let it auto fill in the command line items just to be sure (same as what I had). Vita3K shows the handful of games installed in its UI and they all run directly. Vita3K apps are within the emulator directory. That is the only "default" that is different as Vita3K wants to put items in the Windows User location so have it set in the config.yml to the emulator directory to: pref-path: G:\Emulators\Sony PlayStation Vita\Vita3K\. LB doesn't seem to be seeing the Vita3K emulator virtual drive. All apps are in the ux0\App directory as Vita3K installs when you use a PKG file (and unencrypted). If I force run a scan it finds no games. If I force run "remove" games it tries to remove the one game I had used prior as test (even though it is also within Vita3K UI). LB Games directory in Manage Platforms is pointed to an empty directory for Vita (just like Sony PS3). If I change that to ux0 location (or just the root of emulator) it pulls in all sorts of files (similar to PS3 RPC as it doesn't depend on the emulator virtual drive then). Anyone have Vita up and running with auto import?

Appears fixed as see no errant "\\" in paths when reimported PS3 games.

All seems to import correctly and with no additional apps now if there is an update. Two minor items: For disc based games and no update the path has an extra "\" but appears to not matter as game launches correctly. Also noticed the games.yml has a "\\" prior to GameID. If select browse button it does go to correct folder but if select eboot.bin and save it removes the extra "\" (and also launches). 2. The game update patch typically has same name as base game (for the few games I have). However, some like Lego Jurassic World the game update has additional text: "Add-on Content and Patch Data". That is the name LB pulls in vs the parent game name. The game doesn't match the DB unless strip off the additional wording. May not be much can do for these cases unless ability to pull base game name. Listing with game data option view showing within RPCS3. With game data hidden in RPCS3:

Right now until a per platform turn off feature is implemented, I just point the Game path entry under the platform to a dummy/empty folder if want that platform "off". As nothing in that folder, nothing to import. Not ideal but for items like pinball and computers the auto import feature creates too many headaches. Example below, as I don't use the LB Games folder anything pointing there is empty/dummy and anything pointing to emulator rom directory is "on" for auto import as that is where my games are located. Note: can never use "scan" function with this setup for dummy folder platforms, particularly the scan for "removed" games as it will nuke anything installed.

Not specific to this beta but a suggestion for fine tuning of auto import for pinball emulators Visual Pinball and Future Pinball so as to restrict to table files for import into LB: Visual Pinball - only table files needed: *.vpt and *.vpx Otherwise imports other files such as back glass (directb2s), logs, and other non-table files Future Pinball - only table files needed: *.fpt Otherwise imports other files such as library (fpl) type files. Example VPX table imported into LB pointing to table

I see the same as I just installed beta 5. Beta 4 showed the LB default plugins but beta 5 with no user plugins other than what comes via installer will nag at start there are updates to plugin but in plugin window it is empty. Beta 4 showed the default plugins listed but now empty. If install a plugin like rename media to rom dll it will not show in plugin manager (or any plugins I tried). However, the plugins operate normally and show in tools menu as prior.

Using a music type utility can remove the cover tags without re-encoding. EMUMovies just embedded the coverart tag into the file. Mp3Tag is free utility that can select a whole batch then remove cover art in one whack. As only tag removal far quicker than any sort of re-encoding.

Yep, restarted LB and as you said indicates updated correctly as you noted...so nevermind! I have had a couple crashes today (while changing platform path of games directory). When I closed LB it appeared it didn't actually terminate in Task Manager. So once I zapped all those zombie tasks and restarted it displayed correctly. Will see if screen shot it next time crash happens + logs.

Two minor UI issues: 1) dialog box when using drop down box has typo noting download link to the left, should be to the right button. Noticed for ScummVM but a few others had same (didn't check all). 2) Update indicator logic if the install is newer still shows that it needs to be updated (and potentially over write newer if user downloaded). Bottom circle is the running version of PCSX2 which is 5927.

Does your standalone Mame use waitvsync option? My try in LB without. Just a guess, as nothing else looks out of place.

I tried this with RPCS3 and the way LB is pulling from RPC seems to be using the eboot.bin entries within RPCS3. Thus, there is issue with how LB prioritizes updates resulting in potential for the original (non-updated) eboot.bin selected to launch in LB. Running directly from RPCS3 prioritizes the correct eboot.bin file so not an issue in the emulator. For example, Angry Birds Trilogy has an update to 1.02 to the disc based game. LB auto imports two eboot.bin entries: One within RPCS3\games directory where disc based games are installed A second under the RPCS3\dev_hdd0\game directory where updates and/or PSN HD games are installed. If LB doesn't prioritize as default the eboot.bin in the update directory the game will run under the non-patched/non-updated version. For some games this can cause issues plus not running updated version. You can manually select the updated version and select as default in LB. But that implies the user knows enough to do this or remembers/notices it. For solely PSN download games then not issue as those are files all are within deve_hdd0\game directory. RPCS3 can run commands and direct and that is how it generates its shortcuts. For example the same game shortcut is: "G:\Emulators\Sony Playstation 3\RPCS3\rpcs3.exe" --no-gui "%RPCS3_GAMEID%:BLUS31054" Calling the game from the RPCS3 GameID variable avoids the eboot.bin issue but just like Vita the issue is tying the GameID to a game name so LB knows what to add to the game name and DB lookup.