* Minor thumbnail improvements
- set standard name if only one entry is in the playlist
- use first database name for thumbnails if core has multiple
* Fix playlist thumbnail downloader
Playlist thumbnail downloader function was missed from the flexible
thumbnail name update, now it is added.
Auto savestate (and its optional thumbnail) is generated on core unload
(quit, netplay start, etc). This ends up using the task-queue, which in
many cases deadlocks and/or causes a crash due to its asynchronous
nature.
Given that this is a state that must be generated before quiting or
reloading the core, it makes no sense to use the task queue, it should
be a synchronous job like for instance SRAM saving.
This should fix#15248 (tested by @schmurtzm)
* Simplify autosave command function
* Simplify and split save and savestate logic
save.c contains "SRAM" saves and their logic, which uses no task/queue.
Add logic to handle 3 possible thumbnail names, in following order:
- most exact name derived from content file (same name, with .png extension)
- usual name derived from playlist (usually coming from database)
- shortened name up to first bracket, chopping off region/publisher etc. info
For local file system, names are checked always.
For thumbnail downloads, names are checked each time the item comes up
in the playlist, meaning that it may take going back and forth 3 times
for a thumbnail to appear. However, as a positive change, failed thumbnail
downloads are not repeated for the same playlist, which was not the case
earlier.
In the commit [1], a global configuration "thumbnail match with filename"
was added which allows thumbnail match with filename.
This commit adds playlist level "thumbnail match with filename" for more
flexible configuration.
[1] 32ed9b6041 ("플레이리스트 롬파일 이름으로 썸네일 이미지를 찾도록 옵션 추가 (#15731)")
Signed-off-by: masky2012 <msuanming@163.com>
Before this fix with the folder setting enabled a core using the netpacket interface would append the sort folder name twice thus breaking existing save states
Right now close is based on core unload. There are several places where
cores are unloaded without the intention of stopping the emulation (for
instance whenever Netplay is started, core is updated, etc).
Moreover scheduling a quit under some of those events causes a task
queue deadlock (as per issue #15313) and freezed retroarch.
This fix moves the quit on close to a "manual" check, placed in the
relevant places (close content menu option, close content event (which
also covers hotkeys), etc.)
