Closed andres-asm closed 2 years ago
andres-asm
commented
6 years ago @bparker06 mentioned it happened to him when he loaded DKC2 and DKC3, I thought maybe it would be a string_is_equal_fast somewhere not accounting for length but doesn't look like it.
Maybe some memcmp? strstr?
i30817
commented
6 years ago Something very similar to the scanner too, see https://github.com/libretro/RetroArch/issues/6699 and my speculation of a possible program cause there. Though it makes less sense for the history list.
In short my idea of the scanner SNAFU is that there is a loop where a variable isn't being zero'ed at the start of the loop, something fails but the variable is being treated as if it succeeded because it 'exists' from a previous loop iteration. In the scanner case, the playlist is apparently being built by appending to the start of a list (or similar) because the 'missing' (mismatching) games that appear as DD Crew have the name of a 'later' game on the playlist, which means that later game was processed first.
Rant ensuing if you don't want to read:
fixing these would be unpleasant anyway for me because the games are missing from the database but they're valid (they're the newest split sets, which libretro-database decided not to bother with for some reason in spite of that being the most compact way to organize the mame rom set). I understand that split sets are not complete games but imo retroarch has to stop thinking it needs to verify all the things... just because there are more required files doesn't mean that the scanner can't verify the existence of the 'main' archive files of each game and just not include the bios and devices... In fact if it wasn't for hacks, achievements and netplay (which need crcs), i'd be all over a libretro database that just verified 'dump names' as primary key to metadata. Those have much less false positives and false negatives and are much much faster. Verification is clrmamepro job.
bootsector
commented
6 years ago Having this issue as well. Ubuntu 18.04, RA 1.7.3 built from master.
ghost
commented
5 years ago i found an easy way to recreate this (at least for me)
Example: open SamuraiShowdown from history. close content. then open StreetFighter using load content... the history will show SamuraiShowdown but this opens StreetFighter
12-30-2018: @fr500 @twinaphex i just recreated the history messed issue. 100% this time even on an empty history list. the game has to be scanned so it is added to playlist. load this game so it adds to the history. exit RA and launch again. launch that game. then launch something else using Load content and load rom that is not on history
inactive123
commented
5 years ago I can reproduce the issue that @retro-wertz describes here.
I will try to fix this before releasing version 1.7.6.
orbea
commented
5 years ago I think the underlying issue is connected to issue https://github.com/libretro/RetroArch/issues/7997 too. That is where RetroArch doesn't keep track of both the current core and the next loaded core which results in various problems. See comment https://github.com/libretro/RetroArch/issues/7997#issuecomment-453866999 for more discussion.
ghost
commented
5 years ago request to reopen:
Apparently, as of latest commit 5e5c9e4, this can still happen, at least for cd-based titles
requirement:
files tested were .chd and .cue files using mdfn_psx, pcsx (for psx games), supergrafx (for pce-cd games)
i can replicate it 100% using cd-based games hence the example. dunno if this can or cant happen in other combination of steps/cores/files yet.
orbea
commented
5 years ago @bparker06 Maybe this needs to be fixed a little more?
hizzlekizzle
commented
5 years ago Yeah, this seems to have returned...
First and foremost consider this:
Description
Sometimes history entries get messed up, I think it may be when you load the same game with many cores, for testing, then it all gets screwy. For example my current history list:
In a nutshell:
As you can see, plenty of entries are messed up as in, they read megaman zero but the rom is not the one indicated
Steps to reproduce the bug
Beats me, no idea, it's hard to tell what triggers it, @bparker06 noticed this too
Bisect Results
[Try to bisect and tell us when this started happening]
Version/Commit
You can find this information under Information/System Information
Environment information