- Move flag logic to task_push_pl_entry_thumbnail_download - this
enables individual "download thumbnails" entry to be also flexible
- Add a message when this download has been tried enough times
(i.e. 3)
- Optimize cases when full or short name is the same as standard
name, skip queries if so (both download and local file)
* 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.
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] 32ed9b604154 ("플레이리스트 롬파일 이름으로 썸네일 이미지를 찾도록 옵션 추가 (#15731)")
Signed-off-by: masky2012 <msuanming@163.com>
(menu_displaylist.c) Some optimizations:
* Make sure val_d is never bigger than 16, it should just
contain a number. 16 is more than plenty (and probably too big even)
* Hose val_d out of loops if its value never changes inside the loop
* Attempt to avoid calling msg_hash_to_str inside loops unnecessarily
as deprecated.
* Use fill_pathname_join_special in the vast majority of cases where
we can ensure out_path is a new empty string
* Get rid of some extension concatenation with strlcat where encountered
* Some general cleanups with NULL termination of strings that get immediately
passed to strlcpy/strlcpy-adjacent functions
* struct was erroneously named 'catagory' - changed to 'category'
* Removed some strlcpys that were just setting the string to a fixed constant value
* Random nits
