History Playlist & Thumbnails

RetroArch Windows devices
#3

It is correct in my playlists AFAIK.

For example a random entry:

  "path": "..\\..\\ROMS\\Nintendo\\Game Boy Advance\\ROMS-GBA\\Sabre Wulf (USA).zip#Sabre Wulf (USA).gba",
  "label": "Sabre Wulf (2004, Rare, GBA)",
  "core_path": "cores\\vbam_libretro.dll",
  "core_name": "Nintendo - Game Boy Advance (VBA-M)",
  "crc32": "73787A16|crc",
  "db_name": "Nintendo - Game Boy Advance.lpl"

But when I run it retroarch adds this entry in the history playlist:

  "path": "D:\\Games\\Emulators\\ROMS\\Nintendo\\Game Boy Advance\\ROMS-GBA\\Sabre Wulf (USA).zip#Sabre Wulf (USA).gba",
  "label": "Sabre Wulf (2004, Rare, GBA)",
  "core_path": "D:\\Games\\Emulators\\RetroArch\\RetroArch-v1.19.1\\cores\\vbam_libretro.dll",
  "core_name": "Nintendo - Game Boy Advance (VBA-M)",
  "crc32": "",
  "db_name": ""

Note the empty db_name field. If I go and manually add “Nintendo - Game Boy Advance” it will then find the thumbnails! However this is a dynamically created playlist I have no control over, retroarch just doesn’t add the correct value it seems. (Although like I said it’s the same for NES games but in that case it finds the thumbnails, so it’s weird).

#4

Maybe deleting the history playlist could help. So a new one would be created. Try that.

#5

A new file doesn’t make a difference.

I have a slight suspicion that if the db_name is absent retroarch tries to get its info from the core info file. For VBA-M that i’m using this is the line from its .info file:

database = “Nintendo - Game Boy|Nintendo - Game Boy Color|Nintendo - Game Boy Advance”

Retroarch goes for the 1st one which is wrong. For other cores it’s the correct one by accident, or because the core is associated with one database only. This would also explain why it’s looking in the “Nintendo - Game Boy” directory specifically. I suppose the correct db_name should be carried over from our playlists to the history file but that’s not currently happening.

#6

Then I’m out of ideas. I use the mgba core, which emulates both the regular Game Boy and the Game Boy Advance, and thumbnails are working fine in favorites and history playlists.

1 Like
#7

Interesting, then one final question is the db_name empty in your case in your content_history.lpl file and what’s your retroarch version?

#8

Not empty. Mine has values like "db_name": "Nintendo - Game Boy Color.lpl", for example. I’m using RetroArch v1.20.

#9

Yeah, that’s why it works then, needs the correct db_name.

Tried with v1.20 earlier but no luck here. All my plists have the correct db_name and if I add individual games to “Favorites” it carries over as expected, just not in History for whatever reason.

Thanks for trying to help!

1 Like
#10

You could try to mess with the “Playlist” options in the settings and see if something is amiss there. Or, as a last resort, even deleting the retroarch.cfg file, to make sure there’s no conflicting leftovers after updates.

#11

I can confirm that I have seen this behavior with the history playlist starting sometime early last year. I think this started with RetroArch 1.17. I think there may have been a recent change to thumbnail matching for that version that broke things in this manner. I tested renaming the thumbnail folder to sega - game gear for a system that was not loading thumbnails, and it loaded the thumbnails.

So it does seem as stated earlier that it is looking in the wrong db name for the thumbnails for some systems. In my case, mostly Sega systems besides Dreamcast, Saturn, and Game Gear that do load properly. I can confirm that Game Boy Advance also seems to have this problem as stated earlier in this thread.

Something is definitely wrong if it is trying to load thumbnails from a completely different system.

1 Like
#12

I think something related to this might have messed things up.

https://github.com/libretro/RetroArch/pull/16082

1 Like
#13

Or actually this, that mentions “use first database name for thumbnails if core has multiple”

https://github.com/libretro/RetroArch/pull/16062

1 Like
#14

Things work fine here (reminding that I’m not using Windows), but I try to do things as by the book as possible. All my thumbnails are stored in a folder called thumbnails, and each system has the proper name matching the playlist (i.e.: Nintendo - Game Boy Advance). Anyway, RetroArch’s thumbnail detection is pretty wonky, as it usually demands perfect name matching. That’s one of the main issues it has against other frontends.

#15

Can you provide some more details of one occurrence that does not work, including core and content name? And also whether the content was opened originally from a playlist that has correct thumbnail display, or some other way (load content, command line etc.)?

#16

Hi, I stumbled upon this thread while searching for a solution with the exact same issue, so I can confirm that the issue is indeed that for some reason, running games from files does not correctly save db_name in the History or Favorites playlists (it does it correctly, when you run the game from a platform-specific playlist, created by scanning).

As an example, I have a game for GBA called “Summon Night - Swordcraft Story”.

  • I ran a file called Summon Night - Swordcraft Story.gba with mGBA and it ended in the History playlist without a db_name (meaning it couldn’t match any thumbnails).
  • Then I ran a copy of that file called Summon Night - Swordcraft Story (USA).gba just to be sure, but to the same result:
  • When I previously scanned the same file into a GBA playlist, it scanned correctly
  • And when I play the game from that GBA playlist, it did update the item in the History playlist to have the correct values and it does load thumbnails correctly for it.
  • Also if I manually fill the db_name value for the auto-generated entry as Nintendo - Game Boy Advance.lpl or even just Nintendo - Game Boy Advance, it works as well

The workaround for the time being is simple, now that I know the issue is in the db_name value - I can either fill the value in the favorites .lpl file manually, or generate the big platform playlists and favorite the games from there, but hopefully the technical reason can be found and fixed as well.

(Note: Just to be sure, I did update to the latest nightly version, but it’s been happening for a while, I think, since previously i had something like 1.19)

1 Like
#17

You actually clarified how you loaded the game and I could finally reproduce the issue. There’s only a problem if the content is loaded through Main Menu > Load Content; otherwise, loading through a playlist works fine. I imagine this happens because the “load content” option is generic, letting the user roam through his directories and select whatever he likes, to whatever core he wishes. Even if a fix is attempted, it becomes pretty hard to detect the correct database related to the content, unless there’s some sort of folder structure to suggest the game’s association. You’d better open a proper issue on GitHub, if you wish.

1 Like
#18

I also can confirm the behavior with Game Boy Advance games thumbnails not showing in History, if run with “Load Content…”. Same issue with Master System games running with SMS Plus GX (can run GG and MS). For other cores it works, because there is only one database to match to.

As pointed out by efrainm23, it only uses the first entry if there are multiple entries divided by |: https://github.com/libretro/RetroArch/pull/16062/files

         strlcpy(tmp_buf, db_name, sizeof(tmp_buf));
            /* If db_name comes from core info, and there are multiple 
             * databases mentioned separated by |, use only first one */
            strlcpy(tmp_buf, db_name, (size_t) (pos - db_name)+1);
1 Like
#19

It used to work before like I said with like version 1.17 or so. It used to use the content folder to match the database to download the thumbnails. Whatever commit that made changes to the thumbnail matching as referenced in this thread, broke that functionality.

I always made sure to match the folder the roms are stored in for each system to match the system name / db name for this purpose. The reason I care about this is that I use a front end like Launchbox to launch the games. Making a separate playlist within Retroarch to get around this issue is redundant.

I liked the way it worked before where the history list would show thumbnails when browsing back to content that was launched from the frontend. It is not a major issue. I just liked how it worked before. Like stated earlier, it does not affect all systems. Seems to impact the ones that emulate multiple systems. Like for Genesis Plus GX, only Game Gear shows thumbnails.

It is still not consistent, as stated earlier, MGBA does seem to want to look into the the regular Gameboy database even though it is primarily a GBA emulator. I guess does depend on this seemingly incorrect priority. It should really check all the relevant systems and not just stop at the first one in the database.

#20

So you’re using an external launcher. Never used Launchbox myself, but shouldn’t those handle everything by themselves? When I used EmulationStation, it sorted everything out elegantly, no matter how messy things were within RetroArch. As those things goes, downstream projects should always adapt to upstream, not the other way around.

#21

Yes,

That is why the matter is not really a big deal, but it does treat any content being launched that way the same way you would if you were using the open content and file browser option in Retroarch. So the history playlist runs into the same issues as mentioned here. Obviously, if you create and manage platform playlists within Retroarch, the history playlist gets populated properly. It was just nice having the history playlist when launched this way to have the thumbnails for content. Felt like it complements the launcher and keeps things consistent. That is all.

#22

In my case (see this post at the top of the thread: History Playlist & Thumbnails), I’ve figured out the issue was using a relative path to the rom files.

That is, if a playlist uses relative paths for the roms then when I run a game retroarch adds an entry in the history file with these fields blank:

  "crc32": "",
  "db_name": ""

… and for some cores supporting multiple systems thumbnails break as discussed above. If I use absolute paths then the crc32/db_name fields are correctly copied to the content_history.lpl file and everything works as intended.

Small issue but ideally it would be nice to not have to chose between relative paths & working thumbnails, so I wonder if someone can replicate this and considers it worth of a fix.

(Using relative paths and adding a game to the favorites playlist on the other hand works fine, the db_name is written, so there’s probably different logic/code handling adding entries to favorites/history).

2 Likes