QUickPlay error

[jaw970]

Hello,

I've added an emulator, PC Engine to my Quick Play list of emulators. ROMs are in 7-zip format. I've added two games to my PC Engine game list. When I launch the games, I get this:

---------------------------
Error
---------------------------
An unknown error occurred - The command sent to the DLL was:
e "D:\Emu\TG16\Neutopia.7z" -aoa -o"D:\QuickPlay\temp" *.* -hide

Press CTRL+C to copy this error to clipboard.
---------------------------
OK
---------------------------

I have quite a few other systems with 7-zip compression and have no problem running those. It's just with this newly added system. Am I missing something?

Thank you,
Jason

[butter100fly]

Hi Jason

Do you mean you added an emulator for PC Engine from one of the existing efinds, or did you add it yourself? Which emulator is it? (and how is that emulator being called - is it through some other prog? What does quickplay call?)

I'm not familiar with that error message, it doesn't seem to be from quickplay....

[jaw970]

Hey Butterfly,

Thanks for the reply. The error is something with 7-Zip. I compressed the files with another programs and they run fine now, thanks.

Jason

[MarcoForce]

Open your file with 7-zip Manager and scroll to the right. If you can read "lzma2:" you file is not compatible with QuickPlay.

Solution:
1. Install 7-zip (if you don't have it) and extract your compressed files in a directory with the same name of the *.7z file (for example: if your file's name is "Neutopia.7z", the files must be extracted in the "Neutopia" directory). The number of the created folders must be the same of the *.7z files with the respective names.

2. Backup and delete the original *.7z files.

3. Create a file with Notepad and paste the following command text:
for /D %%A in (*) do "C:\Program Files\7-Zip\7z.exe" a -t7z -m0=lzma -mfb=273 -md=1024m -mx9 -mmt2 "%%A.7z" -xr!*.bat ".\%%A\*"

Note: "C:\Program Files\7-Zip\7z.exe" is the default location of 7-zip installed program. You can change this if you install 7-zip in other location.

3. Save the text file and rename the *.txt extension to *.bat extension.

4. Put the *.bat file in the same location of the directories.

5. Select the *.bat file and press Enter.

6. Wait until the console windows is closed.

7. Check if the number of the new generated *.7z files are the same of the folders.

8. If all is right, you can delete the folders and now your packaged roms are 100% compatibles with QuickPlay.


Now, this is the description of the error:

Unfortunately, QuickPlay is not compatible with LZMA2. LZMA is the algorithm used for compression in 7-zip. Another problem is GoodMerge. That tool don't specific the LZMA version used in the compression. As a result, if you have an updated version of 7-zip different from 9.20 the default option is LZMA 2. So, this is the problem with the new GoodSets "merged" with new versions of 7-zip.

For now, this manual command line method is a solution but the problem is the extra work for organize your folders (yes, a harder work). So, I conluded that this as a BUG: QuickPlay don't support LZMA2.

I wait this information is useful.

PSD: Sorry if my english is not good.

[butter100fly]

Hi MarcoForce- thanks for this, clearly this needs to be addressed - I did try to update the 7-zip32.dll that QuickPlay uses a few months back but when I did so I ran into many issues with existing Goodmerged sets. QuickPlay is using an older version of that dll and in theory its very easy to upgrade it. Do you suspect this is the problem?

I think the answer is probably yes, I had this existing feature request, so i've upped the priority and turned it into a bug:
https://sourceforge.net/p/quickplay/bugs/37/

if anyone has any ideas why the lastest dll might refuse to load some zips please let me know as it will help to get this fixed. If anyone wants to actively help me - look at that bug ticket and see that i've put the dll that i tried to use in the ticket - backup your current dll in the quickplay folder and temporarily put that one there and see what problems you have and let me know - to help with testing: from memory just one of the errors I had with the newer dll was that I was trying to run a rom that had been encoded as part of the SNES 3.14 Goodmerge, and I got similar messages to the below. Think GBA roms too had a lot of issues.

It took some searching to find that updated 32bit dll so if anyone has a better or moreupdated canonical source also that would also massively help?

Also MarcoForce some links or other info to help troubleshoot issues would be great?

[butter100fly]

I'll continue the conversation here rather than the ticket in the hope that one of you might help

What i've found so far:
* The version of the 32-bit full 7zip dll that was last posted by the Japanese guy who maintained it IS the one I put in the bug ticket
https://sourceforge.net/p/quickplay/bugs/37/ - its from 7zip version 922.01
* The 7Zip packages own identically-named 7-zip32.dll is NOT the same as this DLL - its a 32bit interface for the 64-bit 7zip dll (and the dlls interlink anyhow hence the 7zip-dll isn't easily usable for us either). We need that japanese guy's final dll at the moment (unless anyone knows otherwise?)
* Marcoforce you said: [MarcoForce][if you have an updated version of 7-zip different from 9.20 the default option is LZMA 2]
So this version IS > than 9.20 so should work right?
* Like I said you can help me test by just downloading the new latest dll from my ticket there, and renaming the existing z-zip32.dll in the root quickplay directory and pasting it in there
* My memory was pretty much right: a quick test shows every goodmerge set I have works fine with this dll, excepts SNES (goodmerge 204), GBA(3.14) and Atari LYNX (201), none of which work AT ALL.

So if someone else could test their versions of these goodmerge sets, and test the newer goodmerge sets with this dll and let us know, that would seriously help.....

[jaw970]

Hello,

Hate to resurrect a thread more than two years old but the issue is still ongoing. Has any progress been made as to why QuickPlay does not like LZMA2 compressed files? Also, why are we still making outdated tools such as GoodMerge a priority to support? Can't we move on to No-Intro? I'm no programmer so I have no idea what makes these decisions so maybe I'm talking out my posterior.

Thank you,
Jason

[butter100fly]

Hi

Good thoughts!

On LZMA2:

Firstly when this was first raised I looked into the matter in what I thought was some detail, but only with regards to goodmerge, as I thought the issue was only about goodmerge romsets. I found that it appeared to have been an error on someone's part to compress a goodmerge set with LZMA2 as people at the time had other problems with Goodmerge and LZMA2

But you've just taught me that the issue is something much more general, could you elaborate as much as possible on what sets/roms you're trying to use that have been compressed with LZMA2 - is this now the default compression with 7zip or something like that? ie: can you explain to me why its such a problem please? What can't you do that you'd like to do?

QuickPlay's internal version of 7zip is only upgradable to the version i've talked about below in this thread, it has the problems mentioned below which i'd need to understand, I could still do with someone else's help to help me work out what effect the upgrade has on LZMA2 and otherwise - I saved the dll file to use with instructions in the bug ticket - could you see what effect it has for you?: https://sourceforge.net/p/quickplay/bugs/37/

If it doesn't affect the LZMA2 issue (I seem to recall the dll being just on the border of LZMA2 support so it might have some effect, one thing I have wanted to do for a while is replace QuickPlay's own 7zip library with calls to the users own installed version of 7zip. We already do this if you use the multiloader for CD/DVD based systems (so if you have those compressed with LZMA2 it shouldn't be a problem at all), but not for zipped roms. It would definitely fix your problem, the first job to do would be to investigate how difficult that would actually be given the codebase, and experiment with how it would affecct things.


NoIntro

I'm totally up for making QuickPlay work with NoIntro soon as I can. I'm no expert in no-intro though, - it sounds a bit like you're asssuming I know the things that would need to be done to facilitate NoIntro support! If you wanted to help what would really help me is (in a new thread) just a list of requirements with screenshots or whatever else helps - so like a list as long as you can make of statements like "I have a no-intro set and this is what I would expect to happen when i do X in QuickPlay, but what actually happens is Y (and a screenshot of Y, maybe with what X would look like drawn on or something). I think this is quite related to the LZMA2 fix too though, since I'd need to know what 7zip would need to do for NoIntro, in order to know whether extracting 7zip calls out to an external call is a workable idea.....

[jaw970]

Wait, this is the Internet ... do people assume things here?

I assume nothing and certainly not that you know anything about No-Intro. Like I said, I have no idea what's involved in these decisions so please forgive me if I have come across that way as that was not my intent.

Regarding 7-Zip, I downloaded the dll files in the link and followed the instructions. I am still getting the same error. This error occurs on any file that I compress using 7-Zip and LZMA2 compression method, regardless of what system. It's with any .7z file using LZMA2 as the compression method. If I unzip the file and the rezip it using LZMA as the compression method, QuickPlay is happy and loads the game with no issue. It's only with .7z files compressed using LZMA2 compression.

- Install 7-Zip (At some point, 7-Zip changed the default compression method from LZMA to LZMA2. This is when the trouble with QuickPlay began).
- In the 7-Zip configuration manager, in the options, I have set 7-Zip integrated into the right-click shell
- Right-Click on a file to compress and select 7-Zip --> Add to archive
- In the add to archive dialog box, compression method is set to LZMA2 by default. Change this to LZMA
- Load the newly created 7z file in QuickPlay and it loads with no issue

If you do not change this method to LZMA, LZMA2 will be used and QuickPlay will generate an error

At whatever point 7zip changed the default compression method to LZMA2, that is the issue. When creating bulk 7z files, the compression method will be LZMA2 and QuickPlay won't like those file and error out. So far, I have not yet found a way to make LZMA the default when creating bulk 7z files. If you compress one at a time using the "add to archive" option, LZMA is the used and not LZMA2. Once you manually change the compression method, the option you select is the default, but only when creating one at-a-time files, not bulk files.

Many people use ZIP files and not 7z files, so the majority of folks using QuickPlay will not see this error. It only impacts those that use 7z files.

I hope that you find this information useful.

Jason

[butter100fly]

Excellent thanks so much! Perfect: Totally understood. Is it just NoIntro (and possibly goodmerge) sets you are having a problem with LZMA support, or other things?

So the best option I have right now, without somewhat-radical changes!, is to stop doing internal dll calls to the old dll and start looking to the users 7zip installation for any zipping needs.

https://sourceforge.net/p/quickplay/fea ... quests/58/

For goodmerge this might be an issue, since we'd need to call out to 7zip for every 7zipped rom in a romlist, it could take a while if doing cmd calls, my first step needs to be to trial what happens there when doing cmd calls.

As I said, it will also totally be a deciding factor to know what 7zip needs to do for NoIntro sets, so if you could fill me in i'd really appreciate it For instance it may be possible to have one path that still uses the old dll for legacy goodmerge sets and another for NoIntro (and other things?!?!)