Hi, I'm trying to add the .dat so that the manual scan detects the arcade games but retroarch doesn't load the file. This happens in 1.8.2 and Nightly.
When you click on "Arcade Dat File", it lets you search for the file, but none appears even if you have the file "FinalBurn Neo (ClrMame Pro XML, Arcade only) .dat" on the drive. If you deactivate the file filter in the Retroarch file explorer options, the .dat file appears, but when you select it you try to load it as if it were a game instead of adding the data in the manual scan option.
Thank you.
edit: never mind this, the problem is worse than i thought... the core doesn't support separate bios dir. It says 'bios0.ic23 NOT FOUND (tried in kofxi awbios kofxi)' but even if 'awbios' is in the list (not the same dir admittedly, in a 'bios' subdir) it doesn't find it.
I guess the idea is all the stuff in the same dir, but a arcade dat file containing only the 'games' for filtering?
I think you were confused as a post @i30817 or what you are commenting is not related to the problem I encountered.
The idea of the manual scanning function in arcade games is the possibility to automatically rename arcade games in the playlist.
To do this, there is an option to dig the FBA or MAME data, but they cannot be loaded. The .dat that I have from FBA works perfectly in clrmamepro and other managers, but when selected with the option of manual scan, Retroarch interprets it as if it were trying to load a rom and launches the core compatible with .dat
No it's related. The option to use a MAME dat on the manual scanner implies that it can also used as a filter, which means i could filter 'useless' zips (they're useless because i use split sets).
That is, the manual scanner might have opened the opportunity to 'support' split sets of arcade games in retroarch. 'Just' dump everything but chd's in the same dir (i kept bios separate), the find a split dat containing only the main games roms. and filter.
If the manual scan filter function works that way anyway, if the MAME core can tolerate the bios split zip being in the same dir as the game but not on the playlist.
In the previous scanner, split sets wouldn't work because the scanner didn't care about the 'other' zips so the games were always incomplete when checked against the database and not added (or it was a different checksum, it's same result).
btw you can use this .xml here to 'validate' a collection but from the name it might be outdated:
https://github.com/libretro/libretro-database/blob/master/metadat/mame/MAME%202016%20XML%20(Arcade%20Only).xml
The problem is that it does not load any dat or xml file, Retroarch in that option within "Manual Scan" interprets it as if it loaded a rom or it gives error or launches the core Flycast, because if it is a .dat it interprets it as a game from Naoimi.
Seems to be an issue with the File Browser (at least on Windows, haven't tried yet with my Linux VM):
Settings > Directory > File Browser if I have it set to <Default> it will try to load the .dat with Flycast core.F:\Roms and the .dat is somewhere on my F: drive, no problem.F:\Roms but the .dat is on my C: drive for example, it won't work and try to load it with Flycast.edit: here's a video showing the problem: https://youtu.be/dRqFMQvQu-8
1) I show that File Browser path is set to F:\Roms.
2) Go to Manual Scan and Load .dat from F: drive -> no issue.
3) Load the same .dat but from C: driver -> Flycast starts.
4) Set File Browser to C: then load .dat from C: -> no issue.
5) Set File Browser to Default -> Flycast starts with both C: and F:.
Ok, the solution works, the reason is weird, but it works, thanks.
Although I will leave the error because it is something that has to be solved, because everyone will have the same error.
Yup that's just a workaround, you should leave it open until it's fixed! ;)
Just tried on my Linux VM, it seems affected too (minus drive letters conflict of course): if File Browser is set to <Default>, it will try to load the .dat with a core, if it's set to anything else it works fine.
Yeah I remember having the same kind of issue a while ago with the Disk Append option, where it starts directly the new disc instead of actually appending it. I thought it was fixed since then :p
edit: Oh nvm, it has been fixed for the Disk Append option, so maybe it was a different issue.
I am having the exact same issue as OP. Is this something that can be easily fix? I am about to try the temporary solution but seriously, I was looking forward to manual scanning using DATs.
Using Windows 10 x64
Workaround did not work for me on Windows 10.
For Windows basically you have 2 conditions:
Settings > Directory > File Browser, it can't be <Default>.So for example if you set path to E:\Roms, your .dat/.xml must be located somewhere on your E: drive.
If it's still trying to load Flycast then idk, maybe there's a 3rd condition... 馃槗
edit: Oh yeah also, as fr500 said above, when you navigate to find your .dat/.xml, do not go to "top level directory" (where you see all your drive letters) or the glitch will happen too.
I'll confirm this worked for me. After doing the steps below my playlist was created and the names in the playlist were matched from the dat file. Before doing these steps I was having an issue where the names in the playlist would just come in as the name of the zip files. But once the names were good thanks to this thread I was able to use the download thumbnails successfully.
Settings > Directory > File Browser to D:\RomsPlaylist created using retroArch manual scan with these settings.
But the bug should still happen if I navigate to another drive (meaning I go through the top level directory) with the Disk Append option, right? Or I misunderstood your message :p Because I can append a disc properly from another drive right now.
Hi all
This should be fixed by PR #9916
Could you please verify (once it has been merged)?
Works like a charm now! 馃憤
edit: And it also fixes the issue fr500 mentionned above when loading overlay presets from other drive. Thanks :D
Great - thanks for the confirmation!
Most helpful comment
Hi all
This should be fixed by PR #9916
Could you please verify (once it has been merged)?