[m3u] NEW Disk Control Interface v1.0 bug reports and discussions

[negativeExponent]

Now, its easier to see disk labels instead of indexes

@jdgleaver

[Darknior]

Excellent it will really help users :D Thanks a lot

[jdgleaver]

@negativeExponent Nice!

This is what I did for the P-UAE core: https://github.com/libretro/libretro-uae/pull/223

It allows custom labels, which I've found to be quite useful. Would it be worth adding something similar here?

[negativeExponent]

but doesn't this break the .m3u specs though by adding | after each line? in anycase maybe you can help out in that area coz im prettry much clueless with strings. ill send the PR in awhile...

[jdgleaver]

but doesn't this break the .m3u specs though by adding | after each line?

Indeed it does, but it's an optional core-specific extension to the format, so I see no harm in it :)

(and | isn't a valid file path character, so you won't get a false match from a file name)

in anycase maybe you can help out in that area coz im prettry much clueless with strings.

Sure, no problem! It will probably be next week, though - I want to add disk control v1 support to the PSX cores and Flycast first, so we get some good coverage of 'popular' systems.

[negativeExponent]

bah, this should be better now...

granada (1990)(wolf team)(disk 1 of 3).dim
granada (1990)(wolf team)(disk 2 of 3).dim
granada (1990)(wolf team)(disk 3 of 3).dim

Street Fighter II Champion Edition (1993)(SPS)(Disk 1 of 4)(System).dim|SYSTEM
Street Fighter II Champion Edition (1993)(SPS)(Disk 2 of 4)(Disk 1).dim|DISK 1
Street Fighter II Champion Edition (1993)(SPS)(Disk 3 of 4)(Disk 2).dim|DISK 2
Street Fighter II Champion Edition (1993)(SPS)(Disk 4 of 4)(Disk 3).dim|DISK 3

[negativeExponent]

absolute paths should probably work now, though i dont understand why anyone would need to use one (maybe network path's?)

anyways its just linux tested. it should work with windows as well but who knows, core is tricky in some parts...

[Darknior]

We always use relative path because like this our game set can be use on different systems. My gamelist works fine on Batocera and an old Retropie. I don't use absolute path because the rom directory is mount in two different directories, but and relative path works fine ;) But it's a good idea for some other users ;)

Street Fighter II Champion Edition (1993)(SPS)(Disk 1 of 4)(System).dim|SYSTEM

I don't really understand ? Do you put a "|" after the file type to name the disk in the menu ? Because if i detect and launch ".dim" and when to use your system it will not work for me :( And Batocera users for exemple ...

Why don't you detect "[ ]" in name file and use them ? Like this :

Street Fighter II Champion Edition (1993)(SPS)(Disk 1 of 4)[System].dim

Thanks

[negativeExponent]

@Darknior to keep it short, first, the delimiter "'|" is based on specs of the new disk control interface, so that should be followed 2nd your example suggests having to rename the files. aside from that we have to do a lot more checking on the strings than needed.

the delimiter | is not yet merged, hence it probably fails. im waiting for buildbot to clear up before i can merge it. if you are able to compile, you can test out the pending PR.

thanks for testing and feedback.

[Darknior]

It will compiled if the future Batocera build, almost all the 15 days lol I understand your disk control interface can read it, for sure. I speak about the external launcher that launch games in Batocera, Retroarch, Recallbox, Launchbox, etc ... They don't know this file type and will not show and launch it. We will not use this option, impossible for us.

Rename games ... yes lol for my part all are renamed from a long time i don't like the original names. But maybe i made a mistake to do it ...

thanks for your answer

[jdgleaver]

@negativeExponent Very nice!

Just a couple of things:

• Rather than manually setting disk.dci_version to 1, it's probably better to explicitly check whether the frontend supports the new disk control interface - i.e. something like:

disk.dci_version = 0;
environ_cb(RETRO_ENVIRONMENT_GET_DISK_CONTROL_INTERFACE_VERSION, &disk.dci_version);

• If you're not using the disk_set_initial_image() functionality (I guess it's not relevant for this core, same as with P-UAE), you should leave it out entirely and just set dskcb_ext.set_initial_image to NULL (otherwise the frontend will complain that it can't set the initial index almost every time you load an M3U file)

[negativeExponent]

disk.dci_version = 0;
environ_cb(RETRO_ENVIRONMENT_GET_DISK_CONTROL_INTERFACE_VERSION, &disk.dci_version);

there is already pending PR to correct this, im just waiting for a go signal to merge it since buildbot is bz with other stuff

[jdgleaver]

Oh right! Sorry, I just checked out a copy of master and grepped. I should have looked at the PRs as well. :)

Good work!

[bslenul]

Hey!

Whenever I load a .m3u file I get a "Failed to set last used disc..." notification, but the game actually works perfectly fine as far as I can tell.

My m3u:

Akumajou Dracula (1993)(Konami)(Disk 1 of 2).dim|Disk 1
Akumajou Dracula (1993)(Konami)(Disk 2 of 2).dim|Disk 2

Also tried without the |Disk X part (really love that feature btw), same result. And content of the .ldci:

{
  "version": "1.0",
  "image_index": 0,
  "image_path": ""
}

I tried deleting it so it recreates a proper new one just in case but nope, path stays empty. If I switch disks through the Disc Control menu the file still looks like that, even the index is not being updated.

Tested on both Windows 10 and a Linux Mint VM with latest RA and core nightlies.

edit: Hope this is fine using this thread, I can create a new issue if you guys prefer.

[jdgleaver]

Ah, I think I can see why that happens - the core assigns a set_initial_image() function, so the frontend thinks this functionality is supported - but it's actually not supported at all in the underlying code (and shouldn't be, since floppy-based systems always start from the first disk).

If this line:

https://github.com/libretro/px68k-libretro/blob/415dd30665f92d86a08630d2a25d58b89c60bc80/libretro.c#L293

is changed to:

dskcb_ext.set_initial_image = NULL;

...it should get rid of the notification.

[bslenul]

Yup that worked, no notification and no more .ldci file being created! Thanks 👍

It was harmless but I saw a couple people being confused by it, thinking they did something wrong :p

[jdgleaver]

Thanks for testing :)

@negativeExponent Would you like to push the above change? Or I can make a PR if you prefer.

[negativeExponent]

sorry late reply. bad internet. merged the changes. thanks for reporting and suggesting fix.

[jdgleaver]

@negativeExponent Thanks very much for merging the change! :heart:

[Darknior]

Now it works perfectly for me Why no one close this issue ?

[negativeExponent]

it appears that there has been no reported issue about this anymore. so ill close it.