PSX shows RetroArch Quick Menu

[Subtixx]

I tried the PSX emulation and all I get when the game is finished loading is the quick menu from retroarch:

[XanderStrike]

I think the PSX emulator doesn't support archives even though the frontend does. It happily plays iso and bin files for me but does that for zips.

[Subtixx]

That's strange since the default extension in frontend is zip and not iso nor bin. Hopefully this gets fixed.

[thelamer]

I highly recommend CHD for all CD based systems. It is the highest compression and will just work.

for i in *.cue; do chdman createcd -i "$i" -o "${i%.*}.chd"; done

chdman is in the container if you don't have it sys level just exec in and convert away.

[XanderStrike]

Holy crap you weren't kidding about compression, it even slightly edges out 7zip for 1435 PSX roms:

It also happily handled multi-track bins that didn't work before which is awesome. Definitely switching to this going forward, seems to work with every game I try now.

One downside, I just let it run for 19 hours compressing my bins to CHDs, and now the scan script is extracting (and in some cases using binmerge to further split) all of them. This means the scan takes ages. Is there any reason we can't hash the whole CHD?

[thelamer]

@XanderStrike yeah it sucks, in general the rom identification I use shas and reference no-intro and redump.org. And depending on the system I need to use know specific track shas for what is inside the CHD, just summing the whole file would not be effective as it can produce different results depending on compression level and underlying system. So you actually need the raw tracks and the only way to do that is to extract the CHD image and sum the contents inside of it. For zipped roms we can potentially use the CRC references as that is stored as meta data in the zip itself see: https://github.com/linuxserver/emulatorjs/issues/36 But all our database is referenced of sha1 sums so would need to convert them over and the users zips would need to be clean (which I am finding is rarely the case as releases usually have readmes or nfos of some kind in them) Also you take stuff like NES roms they need to have their header stripped away to reference no-intro db entries. I am down with improving speed and reducing the burden of scanning in roms, but in general leaning more towards lower code maintenance vs high optimized scanning options.

[ltomes]

If you move to CRC, would it be incremental/start with a flag or setting to allow 'fast' scanning?

Maybe something like:

metadata/crc_<plaform>.json Direct mapping of a crc hash, to a uuid entry in <platform>.json metadata/sha1_<plaform>.json Direct mapping of a sha1 hash, to a uuid entry in <platform>.json metadata/<plaform>.json Same as now, but keys are a uuid instead of sha1

Would result in one more direct lookup/reasonable complexity, but a pretty maintainable structure.

Edit: I suppose a hashes_<platform>.json that is a mapping of a uuid, to a json object with a crc and sha1 is just as reasonable.

[Xeddius]

I'd love for emulatorjs to have a setting/toggle so it doesn't scan files that it already has an existing checksum for.

[ltomes]

I'd love for emulatorjs to have a setting/toggle so it doesn't scan files that it already has an existing checksum for.

I believe that exists if you "Scan for new Items", at least to me it looks like it skips files it already scanned.

This was very helpful once a non 0 exit happens, I can then move the problem archive, and resume where I left off.

Edit: Oh that's hilarious (what #59 fixes) happens if you scan an 'invalid' archive, and then you can't get to the "Scan for new Items" button and have to redo everything.

[Xeddius]

@ltomes I see, thank you, I hadn't realized it was there.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue is locked due to inactivity