Tochd only processing either CUE/BIN or ISO, not both

[h1ghb1rd]

When running tochd in a folder containing BIN/CUEs and ISOs, it only processes one format, but not both.
I'm not sure under which conditions one format gets chosen over the other, I have folders where it ignores ISOs and folders where it ignores CUE/BIN files.

Is this expected behavior?

An sample test case, just showing the general problem, not an exhaustive test:

butnut@PAD /mnt/demo % ls -AhgG games
total 4.3G
-rwxrwxrwx 1 587M Dec 24  1996 BIN_PS2game.bin
-rwxrwxrwx 1   74 Sep 20 12:49 BIN_PS2game.cue
-rwxrwxrwx 1 2.8G Dec 24  1996 ISO_PS2game.iso
-rwxrwxrwx 1 978M Sep 20 10:15 ZIPPED_ISO_PS2game.zip

butnut@PAD /mnt/demo % tochd -X -s games
Files in queue: 2
Job 1     Skipped:      /mnt/demo/games/BIN_PS2game.cue
Job 2     Skipped:      /mnt/demo/games/ZIPPED_ISO_PS2game.zip
Started: 0
Skipped: 2
Failed: 0
Completed: 0
Elapsed time: 0:00:00

butnut@PAD /mnt/demo % mv games/*.bin games/*.cue hidefiles

butnut@PAD /mnt/demo % ls -AhgG games
total 3.7G
-rwxrwxrwx 1 2.8G Dec 24  1996 ISO_PS2game.iso
-rwxrwxrwx 1 978M Sep 20 10:15 ZIPPED_ISO_PS2game.zip

butnut@PAD /mnt/demo % tochd -X -s games
Files in queue: 2
Job 1     Skipped:      /mnt/demo/games/ISO_PS2game.iso
Job 2     Skipped:      /mnt/demo/games/ZIPPED_ISO_PS2game.zip
Started: 0
Skipped: 2
Failed: 0
Completed: 0
Elapsed time: 0:00:00   

System information:

butnut@PAD /mnt/demo % tochd --version
tochd v0.13
butnut@PAD /mnt/demo % uname -a
Linux PAD 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29 23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
butnut@PAD /mnt/demo % lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.5 LTS
Release:        22.04
Codename:       jammy

[thingsiplay]

This is indeed expected behaviour (although it's a workaround). It's an edge
case for a problem I could not solve otherwise.

The .cue file is basically a regular text file, which has reference to the .bin
and other files, such as .iso. Open it in the text editor and look. If you use
tochd or chdman to convert .cue file, it will automatically pick up .bin and .iso
files that belong to it. The resulting .chd file is correct.

If you now take the .iso file on its own and want to convert, then tochd has no
clue to what project it belongs to and how to convert. All these informations are
stored in the .cue file (or .gdi for Dreamcast). So you do not want to convert .iso
on its own. That is why it is ignored if a .cue file is found in same directory.

This is a dirty workaround from me and it works generally speaking. For your
provided example output I assume those files belong to each other. BTW you don't
even need to unpack the .zip file, as tochd can handle .zip, .rar and .7z files. It
will unpack and remove the temporary files afterwards.

My answer here assumes that BIN_PS2game.bin, BIN_PS2game.cue and
ISO_PS2game.iso belong together as one game and that you got these files from
unpacking ZIPPED_ISO_PS2game.zip .

Now in case you are 100% certain that the .cue and .iso files are totally different
games and you want them convert on their own, then the only way to do it would be
to move them in different directories. If the files belong together, then you only
want to convert .cue file, which references all needed files such as the .iso.

Edit: The intended behavior is actually ignoring .iso, not .cue.

[h1ghb1rd]

In the example BIN_PS2game.bin, BIN_PS2game.cue and ISO_PS2game.iso do NOT come from ZIPPED_ISO_PS2game.zip.

These are all 3 different games, one is a ISO in a ZIP, one is in ISO format and one has a CUE and a BIN file, as you can see by looking at the filesize of the ls command. I just named them all PS2game for copyright reasons.

butnut@PAD /mnt/demo % ls -AhgG games
total 4.3G
-rwxrwxrwx 1 587M Dec 24  1996 BIN_PS2game.bin
-rwxrwxrwx 1   74 Sep 20 12:49 BIN_PS2game.cue
-rwxrwxrwx 1 2.8G Dec 24  1996 ISO_PS2game.iso
-rwxrwxrwx 1 978M Sep 20 10:15 ZIPPED_ISO_PS2game.zip

I'm aware of the workaround you speak off from reading the readme, but it seems like it leads to unexpected side effects like I demonstrated above.

Ideally the workaround should look at the files and determine if they are even related to each other.

Currently it just assumes they are related, which might not be the case in an average users rom folder.

[thingsiplay]

I actually agree with you. I actually wanted to do this properly, but could not get it to work correctly when writing the script.

The best case would be to actually read the .cue files and analyzed the paths (which can be either Windows or POSIX/Linux paths BTW) and are formatted in different ways, because there are different .cue formats (and .gdi). And it needs to work with the temporary files too. Because I never needed this, I went with this (lazy) workaround and crossed the fingers.

So for now there is no quick fix for this unfortunately. I will look into it again, if this can be resolved. But it needs a bit more rewrite and can take time. It's definitely something I would like to see solved myself.