Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IOS RetroArch - using “Clean Playlist” feature removes all entries from playlist #17500

Open
2 tasks done
moroboshi69 opened this issue Feb 1, 2025 · 2 comments
Open
2 tasks done

Comments

@moroboshi69
Copy link

Is there an existing issue for this?

  • This is a bug in RetroArch frontend
  • I have searched the existing issues

Description

This is in IOS Retroarch 1.20.0. When selecting “clean playlist” while managing a playlist, instead of removing invalid or duplicate entries, it removes ALL entries from the playlist

Expected behavior

”Clean Playlist” should only remove invalid or duplicate playlist entries.

Steps to reproduce the bug

  1. Settings > Playlists > Manage Playlists > [Select Playlist]
  2. Clean Playlist
  3. All entries are now deleted for this playlist

Version/Commit

1.20.0

Bisect Results

No response

Present in the nightly version

I don't know

Platform & operating system

iPadOS 18.2, iPadOS 16, iOS 18.2

Affected Cores

Not core specific

Environment information

Issue is present on
iPad M2 11” iPadOS 18.2
iPad 2017 10” iPadOS 16
iPhone 11 Pro iOS 18.2

Relevant log output

@i30817
Copy link
Contributor

i30817 commented Feb 1, 2025

Clean playlist will remove all unavailable entries in the path, its not for removing duplicates as far as I know (it would be a bad idea even considering softpatches can use copies of the same room and be different games).

It's extremely easy to clear it completely by accident if you have your games in a mountpoint that is not mounted. Ie: drive not powered on or connected, connected but not mounted, mounted but without permissions for the current user, network down for a network filesystem etc.

Can also easily happen if your mountpoint system location changed by accident, for instance, mounting two drives and what was E: is now F: in windows etc. Linux\unix\macos tries to be much more predictable about the name of the drive but it's still possible to change it (on purpose only).

if this is not the case for you, please comment with more information, like a log of the process occurring.

@warmenhoven
Copy link
Contributor

This is fixed in the nightly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants