Sony - PlayStation.lpl conflicts
See original GitHub issueThe redump dat set has hashes for the bin and cue files however these aren’t used by retroarch to match the roms?
<game name="Threads of Fate (USA)">
<category>Games</category>
<description>Threads of Fate (USA)</description>
<rom name="Threads of Fate (USA).cue" size="87" crc="009cfc2e" md5="33dfd831427e04229f0d307f4f51a39c" sha1="c055fc0410717a3615c3566b057a729c94215369"/>
<rom name="Threads of Fate (USA).bin" size="357454608" crc="59b2f8a3" md5="bf49e5e7a09acc46625b5ced33dd45f5" sha1="375e4a344c4feef969bef6042ff1f90e350fa5d5"/>
</game>
<game name="Urban Chaos (USA)">
<category>Games</category>
<description>Urban Chaos (USA)</description>
<rom name="Urban Chaos (USA).cue" size="83" crc="7632573f" md5="a9fa97c60f774d9b90aae4aaa04b17fd" sha1="6effedb519572cd1bf55380c4aeebbd8c1b5a3e1"/>
<rom name="Urban Chaos (USA).bin" size="616096992" crc="239c0746" md5="c9b4e03de8dd5c1fb799fc56e5cf031a" sha1="f6608f6ec4128366161f1aa99c6a8b69d76150fe"/>
</game>
retroarch seems only to index the cue files and doesn’t hash them, this has a conflicts e.g. Urban Chaos
./Threads of Fate (USA).cue
Threads of Fate (USA)
DETECT
DETECT
00000000|crc
Sony - PlayStation.lpl
./Urban Chaos (USA).cue
Threads of Fate (USA)
DETECT
DETECT
00000000|crc
Sony - PlayStation.lpl
Is this due to ‘Threads of Fate’ and ‘Urban Chaos’ having the same serial in the dat? https://github.com/libretro/libretro-database/blob/29ecb40c637bb0b646f4c9275a62880ef44dac04/dat/Sony - PlayStation.dat#L49792
This is my output from attempting to read the serials, I’m unsure of an intended method but this seems to show that the serials are close enough to conflict?
strings ./Threads\ of\ Fate\ \(USA\).bin | grep -i slus-01019
BASLUS-01019-DP
strings ./Urban\ Chaos\ \(USA\).bin | grep -i slus-01019
PLAYSTATION SLUS-01019
BASLUS-01019URBANSV
Sorry if this is intended functionality of the database
Issue Analytics
- State:
- Created 6 years ago
- Comments:8 (6 by maintainers)
Top Results From Across the Web
Sony's Obsession With Blockbusters Is Stirring Unrest Within ...
Sony's Obsession With Blockbusters Is Stirring Unrest Within PlayStation Empire. A small team had big ambitions for a Last of Us remake, but ......
Read more >Connectivity Support | PlayStation
Find everything you need for help with connecting to PlayStation Network, check PSN status and troubleshoot your Wi-Fi or wired internet connection.
Read more >PlayStation Plus Essential: 1 Month Subscription
When cancelled, it will expire at the end of the period for which you've already paid. ... Air Conflicts: Pacific Carriers (PS4). Air...
Read more >Troubleshooting game downloads from PlayStation Store
Find out how to fix issues when downloading games from PlayStation Store on PS5™ consoles and PS4™ consoles.
Read more >Air Conflicts: Pacific Carriers - PlayStation®4 Edition
One-time license fee for play on account's designated primary PS4™ system and other PS4™ systems when signed in with that account.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Edit: i dowloaded it and you’re right. Apparently there was a misprint on one of these games and the serial is the same in the executable. I think this will need to be differentiated differently.
The ‘serial’ for urban chaos on the redump page is either a correction to what was intended or a error.
I suggest using the ‘label’ if you detect that serial and assign the right one to Urban Chaos. Threads of Fate has ‘DEWPRISM’ and Urban Chaos has ‘SLUS-01019’ so something like
If indeed it’s urban chaos that is wrong.
edit: I think it is. I just updated my script to id serials from games too (romhacking update pending).
This has to be changed on the Retroarch serial scanner code to work (and assuming that has access to the label), not the DAT file.
When running, RetroArch should report the serial that was found. Mind posting that? Another thing you could do is create a post on the Redump forums. We roll with what they provide.
In the mean time, I’m going to close this one.