Fix error where ISO files are prioritised over CUE files #794
Conversation
| if (isoFile !== null && (supportsExt('iso') || supportsExt('cso') || supportsExt('chd') || supportsExt('elf'))) { | ||
| this.fileName = isoFile; | ||
| } else if (supportsExt('cue') || supportsExt('ccd') || supportsExt('toc') || supportsExt('m3u')) { | ||
| if (supportsExt('cue') || supportsExt('ccd') || supportsExt('toc') || supportsExt('m3u')) { |
There was a problem hiding this comment.
When core supports both cue and iso and iso file provided, it will try to load (or create) cue and will not load iso.
There was a problem hiding this comment.
That was the goal.
Ideally a user would only be providing a cue file if they intend to use the cue image loading method, so I don’t think this should be an issue.
Certainly better than those ROMs that have both a cue and iso and require the image to be loaded via the cue but end up trying to load the iso instead resulting in a failure.
There was a problem hiding this comment.
Oh wait... that's not what you wrote :D
You meant core supports both core and iso and only an iso is provided, it'll try and create a cue and fail to load the iso.
Apologies. I'll dig back into this again.
There was a problem hiding this comment.
@ethanaobrien; this issue has reared it's head again - this time with Amiga. It's trying to use cue files which simply don't exist.
I'm wondering if we shouldn't re-evalute the logic for the selection of files...
Could we use something like the following psuedo code?
if game file extension ends in not [ zip, 7z ] then start emulator with provided file name
else
extract file to /game (so files aren’t mixed with others)
determine if common files exist [ m3u, iso, chd, cue ]
if (m3u) start emulator with the m3u file
if (cue) start emulator with the cue file
if (chd) start emulator with the chd file
if (iso) create cue file and start emulator with new cue file
There was a problem hiding this comment.
this time with Amiga.
How is this issue platform specific?
It's trying to use cue files which simply don't exist.
Any clue why? I’d rather fix that then change the file name extensions since not all cores support compressed files
Could we use something like the following psuedo code?
For specific systems, it should work
As a note - the only reason cue generation exists is because of the mednafen psx core. Back when the core was first pushed to stable, the amount of people that couldn’t configure the file properly was huge, and would open an issue/complain about a bug when it was just a very common user error, so I wrote the generate cue function to fix users mistakes
(as well as needing a cue, the core is also very specific about the paths of the files in the cue file)
There was a problem hiding this comment.
Ah... this makes sense. I didn't know the reasoning behind creating the CUE files.
I'll have to ruminate some more on it.
BTW: I found the Amiga fault, I was sure that I had added puae to
Line 950 in cc69305
This is my fault. I'll submit a PR to fix that.
Closes #792