(Menu) Ability to remove old cores

[klepp0906]

So as far as i know, at current - the only means to get rid of cores that are no longer supported, have been merged, or were discarded - is to literally manually compare and delete. (or purge and re-acquisition)

you guys have come a long way on quality of life stuff with updating and thumbnail downloads etc. This will serve the OCD folks such as myself who like to keep things proper/right/current, as well as prevent perpetual bloating over time. Not to mention confusion from people trying to run old unsupported cores.

I dont know that a 1-click solution is the best choice, at least as an only option, as people might be hanging onto something for a certain reason, or for people that build cores that arent currently on the buildbot etc.

perhaps a list of things that dont match and that can be removed 1 by 1. (including .info files ;p)

Just an idea /shrug

[klepp0906]

I dont know, perhaps we are misunderstanding one another.

I just manually purged and reacquired all current cores ala the stellar > new cores option. I was alerted by another contributor over the apparent removal of the mupen64plusopenGL core after the addition of the mupen64plus-next core.

There was a naming discrepancy I was having trouble with and he said to remove it. This prompted me to question how to stay current on these sorts of things so they dont present future issues.

Needless to say, I imagine stellar pulls cores from the buildbot and it pulled the new mupen core, while not pulling the old one (as i would assume it was removed from the buildbot)

it would need to be a means of checking whats in the cores that buildbot pulls/extracts vs whats in the cores directory and letting you choose what to remove id imagine.

[RobLoach]

I dont know, perhaps we are misunderstanding one another.

fr500 was agreeing with you. The core build scripts have the capacity to build and add new cores, but it doesn't currently remove old ones. Same with the online updater, just adds, currently doesn't remove.

Would be a nice to have this, unsure where in the menu it would live. Any thoughts?

[klepp0906]

Ah, it was me misunderstanding him then. Tends to happen before the coffee has crossed the blood brain barrier.

I agree it would be nice to have (obviously hence my posting) glad it wasnt too far outside the scope of things though. A step towards a sort of half-automated "maintenence" of retroarch. Retroarchs own built in ccleaner :) Long term users, as i expect myself to be. Over the next 5 years, 10, 20. Imagine the hot mess.

as for where it would reside, i didnt give that too much thought in all honesty. Thats one of the perks of being a user, we get to "live with" what you guys decide. But the way programmers think, often theres a good reason behind their choice and more often than not its the right one. At least in my experience.

Anyhow, I imagine - since it would have an online component, and be tied to the cores - perhaps in the online updater section under core updater. Or something like Online Updater > Core Maintenence > Core Updater & Whateveryouwanttocallit as sub entries. More or less the entire section includes means of curating or maintaining RA.

i know the information section includes the database manager, and cursor manager, i could see a core manager type entry - but i dont know that it would be well placed/easily found under the information banner.

As per my earlier sentiment, whatever you guys decide im certain will be fine lol

Ive no idea how it would check (even though im sure theres a way) but said section could include a toggle to remove corresponding info files, database files, log/save/state/config folders for cores no longer present.

that sounds like a ton of work though. I imagine its something that could be expanded on later. I just wanted to get the idea out there. It just certainly has to have options and selectable entries as some things people will want to keep whether it be old versions of a core for compatibility reasons, or cores not on the buildbot etc.

others will use the one and done button so to speak.

[i30817]

This is all IMO:

While i think there is no point in 'preserving' deprecated cores without explicit user intervention, i'm struggling to find a way to do that without user intervention that is not overbearing, simply because each core has no notion of 'previous deprecated filename'.

If that notion was added to the core info files, those could be deleted on core updates, instead of deleting everything that doesn't match, which could be overbearing for (for example) custom builds.

Asking the user for deletion or deleting automatically is a orthogonal concept to me, after this other detail is solved.

I don't like the button solution for the fact that not all cores that upstream doesn't know about are ok to delete and because RA needs less buttons, not more.

[killerz298]

The mupen64plus situation is what brought me here. My OCD can't handle not being able to removie it and I have not rooted my Shield. Also, I've been having problems with the save states using PPSSPP core, so the option to reinstall the old version would be a nice feature.

[andres-asm]

Only partially related, but I have a core backup feature in my fork: https://git.retromods.org/dev/RetroArch/commit/c1822272d45826af0921b3b46d09a5a65df344e0

[killerz298]

Only partially related, but I have a core backup feature in my fork: https://git.retromods.org/dev/RetroArch/commit/c1822272d45826af0921b3b46d09a5a65df344e0

Thanks, I'll take a look. Now I just need to find a version of PPSSPP before the problems started.

[soredake]

Any progress on this?

[hizzlekizzle]

Not the OP issue, no. You can, however, delete old cores by loading them and then going to main menu > information > core information > delete core.

[LibretroAdmin]

it is possible to remove cores now in Core Information. We can possibly further simplify this, but for now this will do.

[klepp0906]

it is possible to remove cores now in Core Information. We can possibly further simplify this, but for now this will do.

my motive behind posting originally wasnt so much to have a means of deleting cores from within the GUI (even though thats a welcome addition) as much as it was to have a means of knowing which cores are outdated/no longer maintained/ no longer used and as such bloat (discounting specific use cases).

an easy way of cross referencing what is downloaded/downloadable in the cores package from the buildbot vs what you have in your cores folder. a means of purging the bloat/cores that are no longer relevant using that information either as a whole or individually would be icing on the cake.

[RobLoach]

have a means of knowing which cores are outdated/no longer maintained/ no longer used and as such bloat

There's an "Update Installed Cores" button. Each core has its purposes, and I don't believe there is any desire to remove any from the buildbot itself. For example, while MAME 2000 is really old, there could be platforms that only have support for that version, and users who just want to use MAME 2000.

an easy way of cross referencing what is downloaded/downloadable in the cores package from the buildbot vs what you have in your cores folder

The "Core Downloader" menu has a flag on the right for if it's installed. It also only lists supported cores for your platform.

[klepp0906]

correct, i use both (core downloader/updater). just over the years cores have been added which in fact are no longer there. the only way to remove them has been manually and doing a manual comparison. the core downloader menu makes it easy to add new cores when they become available, but not remove old ones. for example when 4DO became Opera i had to remove the 4DO core.

its generally been a purge and redownload of them all to weed out the changed/no longer supported/deprecated old stuff.

admittedly its not something thats done frequently but for those of us who have kept and intend to keep the same RA folder we've used for years, it would be nice to know at a click without doing so manually.

that being said, its probably lower priority than say something like a built in exe updater :P

[hizzlekizzle]

We have discussed adding a flag to obsolete core info files to hide them from the list (e.g., 'superseded_by = corename_libretro', so if corename_libretro is in the list, it won't show), but we're generally pretty skittish about automatically deleting things. People tend to get pretty mad if things get deleted unexpectedly.

[klepp0906]

nope, i understand that entirely. instead of hiding them in the list, how about in the core downloader perhaps, showing a different symbol next to cores which are obselete? then the user can decide for themselves.

just trying to think of a means to stay on top of it without a complete purge and redownload of the cores folder or without cross referencing the directory vs whats on the build bot manually.