- The initial-run wizard did some things, but I'm not sure exactly what it accomplished, since I had to go and do other kinds of scans later too.
- The MAME options dialog wants me to tell it where the extras folder is; can't it find out by looking at my MAME installation, since MAME itself knows and uses it?
- Additionally, when I point it to the extras folder, it complains that it is "not a valid extras folder". This assessment seems to be based on the icons being in a .zip rather than a folder. Creating an icons folder in there makes it stop complaining. Shouldn't QP be able to use the .zip instead, just as MAME itself does? As well, shouldn't the presence of extras be optional?
- The dialog also tells me to go and download a MAME .xml file from its releases page. Can't it simply run to get it automatically?
Code: Select all
mame.exe -listxml - Doing a scan for ROMs always dies partway through with an error saying that a random .dat file in QP's data folder can't be created because it is in use by another process (despite showing in Resource Monitor as being heavily written to for a long time first). Dismissing the error doesn't kill QP entirely, though, and the ROM list shows a bunch of results, albeit nowhere near complete. Starting the ROM scan again does much the same thing all over again, and leaving more results added to the list. However, quitting and restarting QP loses all the results.
Newcomer here, hello
Newcomer here, hello
Hi, I'm trying out Quickplay and I'm seeing some issues as I go. My situation is that I have a preexisting fully-working installation of MAME 0.242, and a full (merged, also 0.242) set of ROMs, CHDs, Software List ROMs, Software List CHDs, Extras, and Multimedia — of the Pleasuredome-sourced variety, which are left undisturbed just as they are distributed. This is under Windows 7 Ultimate.
-
butter100fly
- Posts: 278
- Joined: Fri Apr 29, 2016 8:13 am
Re: Newcomer here, hello
Hi there! Sorry for the late reply, you got tagged as a spammer and I didn't see your request until now
* The initial-run wizard did some things, but I'm not sure exactly what it accomplished, since I had to go and do other kinds of scans later too.
The first run wizard would probably have found your MAME executables as part of its Emulator finding section, I didn't consider the first run wizard when writing the MAME guide as the guide assumes you aren't starting QuickPlay for the very first time, I'll try to remember to add a clause to the MAME user guide in case of that
* The MAME options dialog wants me to tell it where the extras folder is; can't it find out by looking at my MAME installation, since MAME itself knows and uses it?
I don't think MAME has a setting for the extras folder, its a convention - have a look at your mame.ini and note that its only each asset that has a filepath, and many of those happen to have been set to be in an extras folder
* Additionally, when I point it to the extras folder, it complains that it is "not a valid extras folder". This assessment seems to be based on the icons being in a .zip rather than a folder. Creating an icons folder in there makes it stop complaining. Shouldn't QP be able to use the .zip instead, just as MAME itself does? As well, shouldn't the presence of extras be optional?
a good point, initially the check for validity of the extras folder was there due to the critical need to rely on some of the extras to complete a rom scan, but its badly implemented and was no alterantive to robust error handling in the list processing code (which i added later). It needs to be reviewed. One thing I would say is that leaving those large asset folders zipped up will make it very slow to traverse your romlist in QuickPlay, that's probably why I unzipped it and forgot it could ever be zipped. Needs reviewing
* The dialog also tells me to go and download a MAME .xml file from its releases page. Can't it simply run mame.exe -listxml to get it automatically?
IIRC I think the sheer volume of work to do to get the initial launch of the mame functionality made me decide to ask you to download the relevant xml, since simply running that command isn't enough: its actually inter-process-communication between two programming languages PLUS a call to a third program's API to generate the file - we need to do error handling in case MAME can't generate the file, and once we generate the file we then need to make lifecycle file handling code: error handling in case there's a problem with the file generation, and invalidation code to handle the new file we would ask Mame to generate. Also I think I was thinking of end-user support also: if the input to the MAME code is a url that both you and I can download and get the same file irrespective of what versions of MAME we're using at the time, its easier to help you troubleshoot as that's one less variable to have to confirm is ok. Again this change could be done though: perhaps you would like to make a ticket to cover your points: https://sourceforge.net/p/quickplay/feature-requests/
* Doing a scan for ROMs always dies partway through with an error saying that a random .dat file in QP's data folder can't be created because it is in use by another process (despite showing in Resource Monitor as being heavily written to for a long time first). Dismissing the error doesn't kill QP entirely, though, and the ROM list shows a bunch of results, albeit nowhere near complete. Starting the ROM scan again does much the same thing all over again, and leaving more results added to the list. However, quitting and restarting QP loses all the results.
This is NOT typical behaviour and is the first time anyone has posted anything like this. I think the 'random' .dat file will be the MAME romdata.dat you're trying to generate and QuickPlay is synchronously writing to this text file. If QuickPlay succesfully wrote data/mame.json when it did your mame scan, it should be able to write data/[the name you gave your mame dats folder]/romdata.dat. Maybe its the .dat suffix vs the .json suffix: disable any active scanning on anti-virus software or anything else you can think of that might stop an apps disk access? Try on another PC? Post a screenshot of the error message?
* The initial-run wizard did some things, but I'm not sure exactly what it accomplished, since I had to go and do other kinds of scans later too.
The first run wizard would probably have found your MAME executables as part of its Emulator finding section, I didn't consider the first run wizard when writing the MAME guide as the guide assumes you aren't starting QuickPlay for the very first time, I'll try to remember to add a clause to the MAME user guide in case of that
* The MAME options dialog wants me to tell it where the extras folder is; can't it find out by looking at my MAME installation, since MAME itself knows and uses it?
I don't think MAME has a setting for the extras folder, its a convention - have a look at your mame.ini and note that its only each asset that has a filepath, and many of those happen to have been set to be in an extras folder
* Additionally, when I point it to the extras folder, it complains that it is "not a valid extras folder". This assessment seems to be based on the icons being in a .zip rather than a folder. Creating an icons folder in there makes it stop complaining. Shouldn't QP be able to use the .zip instead, just as MAME itself does? As well, shouldn't the presence of extras be optional?
a good point, initially the check for validity of the extras folder was there due to the critical need to rely on some of the extras to complete a rom scan, but its badly implemented and was no alterantive to robust error handling in the list processing code (which i added later). It needs to be reviewed. One thing I would say is that leaving those large asset folders zipped up will make it very slow to traverse your romlist in QuickPlay, that's probably why I unzipped it and forgot it could ever be zipped. Needs reviewing
* The dialog also tells me to go and download a MAME .xml file from its releases page. Can't it simply run mame.exe -listxml to get it automatically?
IIRC I think the sheer volume of work to do to get the initial launch of the mame functionality made me decide to ask you to download the relevant xml, since simply running that command isn't enough: its actually inter-process-communication between two programming languages PLUS a call to a third program's API to generate the file - we need to do error handling in case MAME can't generate the file, and once we generate the file we then need to make lifecycle file handling code: error handling in case there's a problem with the file generation, and invalidation code to handle the new file we would ask Mame to generate. Also I think I was thinking of end-user support also: if the input to the MAME code is a url that both you and I can download and get the same file irrespective of what versions of MAME we're using at the time, its easier to help you troubleshoot as that's one less variable to have to confirm is ok. Again this change could be done though: perhaps you would like to make a ticket to cover your points: https://sourceforge.net/p/quickplay/feature-requests/
* Doing a scan for ROMs always dies partway through with an error saying that a random .dat file in QP's data folder can't be created because it is in use by another process (despite showing in Resource Monitor as being heavily written to for a long time first). Dismissing the error doesn't kill QP entirely, though, and the ROM list shows a bunch of results, albeit nowhere near complete. Starting the ROM scan again does much the same thing all over again, and leaving more results added to the list. However, quitting and restarting QP loses all the results.
This is NOT typical behaviour and is the first time anyone has posted anything like this. I think the 'random' .dat file will be the MAME romdata.dat you're trying to generate and QuickPlay is synchronously writing to this text file. If QuickPlay succesfully wrote data/mame.json when it did your mame scan, it should be able to write data/[the name you gave your mame dats folder]/romdata.dat. Maybe its the .dat suffix vs the .json suffix: disable any active scanning on anti-virus software or anything else you can think of that might stop an apps disk access? Try on another PC? Post a screenshot of the error message?