libretro / RetroArch

Cross-platform, sophisticated frontend for the libretro API. Licensed GPLv3.
http://www.libretro.com
GNU General Public License v3.0
10.22k stars 1.82k forks source link

Qt5 GUI not using new shared thumbnail path for MAME 20XX playlists #8495

Open metchebe opened 5 years ago

metchebe commented 5 years ago

There has been a change to the thumbnail path for MAME cores. Now all MAME 20XX cores share the same thumbnail path, which is simply thumbnails/MAME/.

However, as of the current nightly build, the desktop Qt5 GUI is not using thumbnails from this path, it is still searching for images in the old paths, that is for the specific MAME 20XX directory in thumbnails/.

The result is that MAME thumbnails appear fine in XMB, but are missing from the Qt5 GUI.

ghost commented 5 years ago

There should not be any core-specific code in RetroArch and so I'm against adding it to Qt. Whoever added the existing code for that (and the TyrQuake-specific code in runtime_file.c) should have handled this through the core info interface instead and that code should not have been merged.

jdgleaver commented 5 years ago

@bparker06 I don't like the MAME thumbnail hack either - I only added it to menu_thumbnail_path.c because that's how it was already done in XMB/Ozone. Since I manage my own thumbnails, it matters nothing to me if the 'MAME hack' is removed - but the issue is that there is only one 'standard' MAME thumbnail pack for users to download. For people who have this, the only alternative to the hack is to set the database for all MAME core info files to the same value (or for playlist generation to somehow set the same db_name for MAME content). I don't think that's something I should decide...

As for the TyrQuake-specific code in runtime_file.c, what would you have me do? TyrQuake is unique in that it handles content differently from all other cores. Without a specific hack, we can't log runtime for TyrQuake at all. I'm not being defensive, or complaining or anything - if you know to do this 'properly', I'd be glad to listen :slightly_smiling_face:

ghost commented 5 years ago

we should add generically named fields to core info to deal with these... e.g. "thumbnail_path" for the MAME thing (set each mame core's info as thumbnail_path = "MAME" etc) plus whatever is appropriate for the tyrquake thing.

markwkidd commented 5 years ago

I agree with @jdgleaver that the combined MAME thumbnail pack is not good in practice. I would like to suggest that we consider what the purpose of combining the MAME thumbnails was, and whether it has turned out to meet that goal.

I don't believe that it actually serves its intended purposes, including saving bandwidth, and that we should have different thumbnail packs for the different MAME versions since they don't necessarily even share the same names for the same games across the years.

Another negative outcome is that it puts the thumbnail packs out of reach of people with limited hardware because the combined pack is too large to cache or to store in the filesystem.

I also agree with @bparker06 that it would be good to add a thumbnail_path field to the playlist spec to be able to deal with this issue in a more general way.

(Edited)

metchebe commented 5 years ago

As I'm not a programmer, I would like to share these comments as a grateful user:

Whatever the decision is, I think it is important to maintain consistency across all of the user interfaces in the Retroarch family (Retroarch and its menu drivers, the Qt5 GUI, side projects like Ludo and db.libretro.com). The thumbnails/<playlist name>/ path works well across all of them.

Also I would like to link this with the fact that individual thumbnail downloading appears to be working well across different implementations (Qt5 GUI, Ludo, maybe others) and it is a great improvement to the pack system. To me it seems like a far better solution than having to download the whole pack which is a waste of time, bandwidth and disk space.

So, maybe instead of thinking about the zipped pack which led to the 'hack', I think it would be better to update thumbnails.libretro.com to have the corresponding 'MAME 20XX' subfolders with thumbs individually available so that the different downloaders can find them.

This would allow to reverse the 'hack' (which apparently also has to be implemented in more places to maintain consistency) while allowing users to properly fetch only the thumbnails they need with the current GUI tools. @markwkidd and others have done a lot of work updating the databases and thumbnails and I think it would be a shame for users to have trouble downloading them if they want them.

Thanks for your time and work.