# [VITA] Imported/scanned content and playlists disappear after restarting RetroArch and require rescanning
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 14.1k
- Forks
- 2.2k
- Avg merge
- 7h 35m
- Merged PRs (30d)
- 51
Description
Is there an existing issue for this?
- This is a bug in RetroArch frontend
- I have searched the existing issues
Description
Description
RetroArch on PS Vita does not consistently retain content that has already been scanned/imported into RetroArch.
I can scan my ROM directories successfully and the games appear normally in the RetroArch interface.
However, after closing and reopening RetroArch, the previously scanned/imported content can disappear from the interface.
The ROM files themselves remain on the SD2Vita storage.
I then have to scan/import the same directories again.
Repeated rescanning temporarily restores the content, but the problem can happen again after restarting RetroArch.
Environment
- Platform: PlayStation Vita
- Model: PCH-1000
- RetroArch: latest official Vita nightly/build
- Storage: SD2Vita
- Content: Retro game ROMs
- Playlists/content databases: RetroArch playlists
Symptoms
The sequence is approximately:
- Open RetroArch.
- Scan/import a ROM directory.
- Scanning completes successfully.
- The games appear in the RetroArch playlists/content list.
- Close RetroArch normally.
- Reopen RetroArch.
- Previously imported/scanned games are missing from the RetroArch interface.
- The actual ROM files are still present on the SD2Vita.
- Rescanning the directory causes the games to appear again.
- After another restart, they may disappear again.
This has happened repeatedly.
Important distinction
The ROM files themselves are not being deleted.
The problem appears to be that RetroArch is not retaining or correctly loading the playlist/imported-content information after restarting.
Therefore this does not appear to simply be a storage failure or missing ROM issue.
Repeated testing
I have performed multiple rescans.
Each scan successfully finds the content and makes it available again.
However, the imported content can disappear again after reopening RetroArch.
This makes the problem persistent rather than a one-time failed scan.
Possible trigger
I am not yet certain what causes the playlist information to disappear.
Possible triggers I have noticed/considered include:
- Exiting RetroArch
- Restarting RetroArch
- Changing configuration
- Updating RetroArch
- Online Updater operations
- Configuration files being rewritten
- Cloud Sync activity
- Crashes/GPU crashes
I cannot currently identify which operation is responsible.
Relationship to Cloud Sync
I initially suspected this might be related to my Cloud Sync/WebDAV troubleshooting because I was configuring and testing Cloud Sync around the same period.
However, the playlist/import problem continues to occur independently and should not necessarily be assumed to be caused by Cloud Sync.
I would like to determine whether RetroArch is failing to save/load the playlist database locally.
Possible areas to investigate
Could the Vita build be checked for:
- Playlist files not being written correctly.
- Playlist changes not being saved before RetroArch exits.
- Playlist files being written to an unexpected location.
- Playlist paths becoming invalid after restarting.
- Absolute vs. relative path handling on Vita/SD2Vita.
- Case-sensitivity/path normalization problems.
- Playlist database corruption.
- Configuration changes overwriting playlist paths.
- Playlist files being recreated/cleared during startup.
- Vita filesystem/SD2Vita write issues.
- Crashes occurring before playlist changes are flushed to storage.
Useful diagnostic information
The important thing to check is whether the playlist file itself still exists after the content disappears.
For example, if a playlist was created for GBA games, I can check whether the corresponding .lpl file remains in RetroArch's playlist directory after restarting.
If the .lpl file exists but RetroArch does not display its contents, that would suggest a playlist loading/path problem.
If the .lpl file disappears or is reset after restarting, that would suggest a playlist persistence/write problem.
I can provide the affected .lpl files and debug logs if needed.
Expected behavior
Expected behavior
Once a ROM directory has been scanned/imported successfully, the resulting playlist/content entries should remain available after closing and reopening RetroArch.
Actual behavior
The content can disappear from RetroArch after restarting even though the ROM files remain on storage.
Rescanning the same directory restores the entries temporarily.
Steps to reproduce the bug
Reproduction
- Scan/import a ROM directory.
- Confirm the games appear in the resulting playlist.
- Exit RetroArch normally.
- Reopen RetroArch.
- Check the playlist.
- If the entries disappeared, verify that the ROM files still exist.
- Rescan the same directory.
- Confirm that the games return.
- Exit and reopen RetroArch again.
- Check whether the entries disappear again.
I can provide exact examples of affected systems/ROM directories and the corresponding playlist files if necessary.
Version/Commit
latest nightly vita build
Bisect Results
latest nightly vita build
Present in the nightly version
Yes, this is reproduced in the nightly build
Platform & operating system
PS Vita
Affected Cores
none
Environment information
PS VITA 1000
Relevant log output
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the scan, restart, and playlist disappearance sequence on the PS Vita nightly build. Check whether the affected .lpl file remains in RetroArch's playlist directory after restarting, and collect the affected playlist files and debug logs. Done means scanned entries remain visible after reopening without rescanning.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100