lr-pcsx-rearmed, certain titles not loading after m3u implementation.

windg

I can confirmed this.

Game is booting without problems if i create the .m3u file with .cue extentions instead of .cdx.

BreadPie

Same problem here.
Each disc will boot perfectly individually using bin and cue. But once the .m3u is introduced it fails to load.

BreadPie

To clarify: m3u files DO work if 1) the .cue files are kept as .cue files (rather than .CD1, .CD2, etc.) and listed as cue files in the m3u; or 2) when there is only one .bin file per disc then changing the .cue file to .CDX (for both filename and in the m3u) works. But, when there is more than one .bin file per disc, renaming the .cue files does not work with the m3u.

mitu

I think this has been reported a couple of times recently - looks like it's worth investigating. @BreadPie - what RetroPie version are you using ?

EDIT: can anyone provide a verbose log of running a .m3u consisting of .cdX cue files ?

windg

@mitu

I use the game: Lunar - Silver Star Story Complete (USA)

Verbose log (.m3u file with .CDx extensions) :
pastebin
Verbose log (.m3u file with .cue extensions):
pastebin

stoo

This post is deleted!

stoo

I can confirm exactly the same behaviour that @BreadPie and @windg are reporting.

.cue extensions in m3u = fine
.cdx extensions in m3u = broken

Does lr-pcsx-rearmed have special behaviour that it applies to .cue files but only if they actually use the extension?

mitu

OK, I see it now. @BreadPie's diagnostic is correct

But, when there is more than one .bin file per disc, renaming the .cue files does not work with the m3u.

When the .cue (or .cdX) file is a multi-track disc image, starting the game results in an error, but if the .cue is a single-track (data) disc, it works (i.e. tested with MGS, which has 2 single-track discs).

My suspicion is that pcsx_rearmed looks at filename.cdX file, doesn't know what it is, but tries to load filename.bin anyway. For multi-track discs, the data .bin is different than the .cue (it's usually filename (track 1).bin, 1st data track), so game is not loaded.
To confirm this, if I symlink-ed

'Lunar - Silver Star Story Complete (USA) (Disc 1) (Track 1).bin'

to

'Lunar - Silver Star Story Complete (USA) (Disc 1).bin'

then started the game with an .m3u file consisting of

Lunar - Silver Star Story Complete (USA) (Disc 1).cd1
Lunar - Silver Star Story Complete (USA) (Disc 2).cd2

and the game starts.

stoo

@mitu said in lr-pcsx-rearmed, certain titles not loading after m3u implementation.:

My suspicion is that pcsx_rearmed looks at filename.cdX file, doesn't know what it is

That is the key. We just need it to parse .cdx the same as it does for .cue, since .cue files work fine.

\pcsx_rearmed-master\libpcsxcore\cdriso.c

	if (numtracks == 0 && strlen(isofile) >= 4 &&
				strcmp(isofile + strlen(isofile) - 4, ".cue") == 0)
			{
				// user selected .cue as image file, use it's data track instead
				fclose(cdHandle);
				cdHandle = fopen(filepath, "rb");

I dunno if this is helpful, I'm not a programmer.

mitu

@stoo said in lr-pcsx-rearmed, certain titles not loading after m3u implementation.:

That is the key. We just need it to parse .cdx the same as it does for .cue, since .cue files work fine.

Not only that - it should work with .chd files at the same time.

The issue doesn't appear when using .chd (.cue + multiple .bin packed with chdman into a single disc file), so that may be a workaround before a solution can be found.

Rion

@mitu said in lr-pcsx-rearmed, certain titles not loading after m3u implementation.:

@stoo said in lr-pcsx-rearmed, certain titles not loading after m3u implementation.:

That is the key. We just need it to parse .cdx the same as it does for .cue, since .cue files work fine.

Not only that - it should work with .chd files at the same time.

The issue doesn't appear when using .chd (.cue + multiple .bin packed with chdman into a single disc file), so that may be a workaround before a solution can be found.

Plus you save a lot of space by converting your bin/cue files to .chd with chdman.

stoo

@Rion Yeah, CHD is better; I'm not saying loose bin/cue files are ideal, but if the docs say you can use them with an m3u, then that should probably be true. ;)

mitu

The issue should be solved now - if anyone wants to test (and hasn't converted their games to .chd yet). Just update lr-pcsx-rearmed from source and check if the game loads ok.

windg

I test it with Lunar - Silver Star Story and the game now loads fine. Thank you very much !

kcoconnor76

@mitu I'm noticing on the latest binary version of lr-pcsx-rearmed, my .m3u files that point to .CDx files are no longer working with RetroAchievements and had to be changed back to .CHD which puts them in the list of files in RetroPie. Is this the expected behavior now?

So, to get my .m3u files to work again with RetroAchievements, they went from this:

game_disc1.CD1
game_disc2.CD2
game_disc3.CD3

to this:

game_disc1.CHD
game_disc2.CHD
game_disc3.CHD

Now the .CHD files show in the menu in Emulation Station and the .m3u files work with RetroAchievements.

I suppose an interim solution would be to go back to .cue files as mentioned above with .bin files for the games and simply remove .bin and .cue from the es_systems.cfg file so they don't show up in the menu. Ideally though, I'd like to keep the .CHD files to reduce storage space on multi-disc games.

sleve_mcdichael

@kcoconnor76 you could also keep the CHD files in a separate location:

File: /home/pi/RetroPie/roms/psx/Final Fantasy VII (USA).m3u, content:

../psx_multi/Final Fantasy VII (USA) (Disc 1).chd
../psx_multi/Final Fantasy VII (USA) (Disc 2).chd
../psx_multi/Final Fantasy VII (USA) (Disc 3).chd

Then, since roms/psx_multi isn't associated with any system in es_systems.cfg, the CHD files stored there won't be displayed in ES's menu.

This is also what people do with lr-duckstation which doesn't support renaming CHD's at all.

kcoconnor76

@sleve_mcdichael Thanks for the idea! I'll try that!

kcoconnor76

@sleve_mcdichael I tried your suggestion for Dreamcast and Playstation and it worked perfectly. Thanks!