Retropie Bezel Project & lr-mame2003 cfg does not persist after update?
Virtualman last edited by Virtualman
Hope all is well, I have been using Bezel Project for Arcade set and been loving it.
I have notice a behavior that is starting to drive me mad and it's needle in a hay stack.
- Every-time I update retropie (4.4.2 to 4.4.3 , and same 4.4.3 to 4.4.4) + all cores , all bezel project config files for lr-mame2003 get's ignored -> .configs\all\retroarch\config\MAME 2003\gamefiles.cfg
- So I'm force to tell emulator for each game to load proper config to load bezel then "save game override"
- Once I save the proper cfg/overlay for that 1 game and save game override all is good if i reload that game, but what happens that last bezel assigned well next game using lr-mame2003 I'm presented with the same last bezel loaded but force to set overlay for each game...
- This has happened for every update...
I really want to stay up to date with all emulators but lr-mame2003 has been giving me lots of trouble to keep bezel project to persist for only lr-mame2003. If you have any ideal why this is occurring I would be forever great-full! I have tried reloading bezel projects and still does not help after update. So I'm force to role back from backup so I don't lose my settings for lr-mame2003 overlays/bezel project. I really don't manual update this all over again. Thank you in advance and long live retro-gaming!
How does the Bezel Project adds the bezels ? Which configuration/override file does it modify ? Can you check if the override folder is identical between versions ?
@mitu can you elaborate check override folder/file 📁? All I know the bezel project downloads .cfg and associated .png and adds it to .configs\all\retroarch\config\MAME 2003\gamefiles.cfg.
@mitu I really don't think it's bezel-project the problem, i think it's update process of lr-mame2003 ... but this is there github has all code there https://github.com/thebezelproject?tab=repositories
@Virtualman What I meant is if the override folder is the same (
MAME 2003) between the versions of
lr-mame2003. There's been a change in the core name (see https://github.com/libretro/mame2003-libretro/pull/383) and I think this might impact the override folder for the libretro core.
@mitu Much appreciated, where exactly would I create the symbolic link to avoid this problem? It's rather confusing link I read...
@mitu your clue lead to my resolution to this this needle in the hay stack!!! Thank you!!! Here is the resolution to the fix!
pi@retropie:/opt/retropie/configs/all/retroarch/config $ pwd
pi@retropie:/opt/retropie/configs/all/retroarch/config $ ln -s MAME\ 2003/ "mame2003"
QuiverMonk last edited by
@Virtualman Can you explain a little more on how you fixed this?
zfa last edited by
Literally just updated my setup and got this issue then found this thread when seeing if it was a known issue with a real fix instead of my 'hack'.
My fix is as per @Virtualman except for the fact that as of today, mame 2003 is reporting its name as 'MAME 2003 (0.78)' (or was when I did my 'update from binary' an few hours ago). I'm also using a symlink to resolve the issue - to the uninitiated this is just a kind of 'alias' to let you access a file or dir by an alternative name.
To fix this issue:
SSH onto your pi using PuTTY etc., then issue these commands:
cd /opt/retropie/configs/all/retroarch/config ln -s "MAME 2003" "MAME 2003 (0.78)"
I guess the real fix is to get The Bezel Project guys to use the names as per the Retroarch guys, or make sure they include symlinks where there are name changes across versions of a core. If this doesn't work then update your emus again in case you have a version reporting itself as being
mame2003as per @Virtualman post.
markwkidd last edited by
I guess the real fix is to get The Bezel Project guys to use the names as per the Retroarch guys, or make sure they include symlinks where there are name changes across versions of a core. If this doesn't work then update your emus again in case you have a version reporting itself as being mame2003 as per @Virtualman post.
This name change/folder change came from RetroArch leadership rather than the mame2003 core. The code logic for this is kind of obscure but it has to do with enabling netplay between a broader range of different systems.
Based on the RA rationale for making the change I expect it will be permanent.