The issue occurs with any file created with the LZMA2 compression method (No-Intro files, GoodMerged files, files not in either database, any file created using LZMA2 compression method.
If you have an entire GoodMerge set and the files are compressed using LZMA2, you will have issues
If you have an entire No-Intro set and the files are compressed using LZMA2, you will have issues
If you have an entire GoodMerge set and the files are compressed using LZMA, you will have no issues
If you have an entire No-Intro set and the files are compressed using LZMA, you will have no issues
GoodMerege or No-Intro - it's irrelevant. The file extension is also irrelevant. It all depends on the compression method used to compress your files wether or not QuickPlay generates the error.
Hope this helps.
Jason
QUickPlay error
-
butter100fly
- Posts: 278
- Joined: Fri Apr 29, 2016 8:13 am
Re: QUickPlay error
Sure I get you, thanks again, but I'm missing a use case for anything other than GoodMerge or NoIntro, and to know what to do now it would really help to understand all the use cases.
So I'm thinking:
* For CD/DVD systems the QuickPlay multiloader doesn't have this problem as it uses your own 7zip install
* sets like GameBase all use zip and not LZMA or LZMA2
* Mame still can use 7zip if you try hard, but the entire zip is passed to MAME and not examined or unpacked by QuickPlay, so the 7zip dll in QuickPlay doesn't get used at all.
So I was just wondering if you want to tell me, what other operations you do outside of GoodMerge or NoIntro sets, where you end up with LZMA2 7zips in your romlist, that you need to unpack using QuickPlay internally? Just a couple of examples will do....
So I'm thinking:
* For CD/DVD systems the QuickPlay multiloader doesn't have this problem as it uses your own 7zip install
* sets like GameBase all use zip and not LZMA or LZMA2
* Mame still can use 7zip if you try hard, but the entire zip is passed to MAME and not examined or unpacked by QuickPlay, so the 7zip dll in QuickPlay doesn't get used at all.
So I was just wondering if you want to tell me, what other operations you do outside of GoodMerge or NoIntro sets, where you end up with LZMA2 7zips in your romlist, that you need to unpack using QuickPlay internally? Just a couple of examples will do....
Re: QUickPlay error
That would be it for me. What other use case would there be? At least for me, that would be it. Thank you.
Last edited by jaw970 on Tue Feb 05, 2019 4:27 pm, edited 1 time in total.
Re: QUickPlay error
Interesting ... I just copied the file 7-zip32.dll from the 7-zip install folder over to the QuickPlay install folder and the 7z file loads fine, even when compressed with LZMA2.
So, the issue is with 7-zip32.dll file. Use the 7-zip32.dll that comes with 7-zip and there is no error.
So, the issue is with 7-zip32.dll file. Use the 7-zip32.dll that comes with 7-zip and there is no error.
-
butter100fly
- Posts: 278
- Joined: Fri Apr 29, 2016 8:13 am
Re: QUickPlay error
I wish that was the answer you were looking for, I really do. But its a great deal more technically and historically complicated than that.
When QuickPlay is told to do any operation to a 7z file, it will first query the 7-zip32.dll for the names of some of the operations it supported at the time John made the original 7zip code against an old japanese version of the 7zip library (these operations can be uncompressing to QuickPlay's temp directory, querying an archive for its files (to display the so-called goodmerge-folder-support), or even zipping operations from the archive tool).
The latest 7-zip32.dll is so different to the one originally coded for (look at the size of it for instance, or try opening it up with 7zip itself and see how different the directory structure is), that those operation lookups will fail if you just replace QuickPlay's version of the dll with the latest available. When that happens, QuickPlay will silently then refuse to perform any 7zip operation on the 7zip rom you're asking it to act on, and will instead pass the 7zip file itself to the emulator. A good indicator that this will happen is if you right click a rom and look at the command to run: QuickPlay will do this operation to check if it will be successful and will show you instead that the 7zip is going to get passed to the emulator. Another indicator that all is not well if you use the latest 7-zip32.dll, is the so-called goodmerge-folder-support itself: if you turn this on in a folder full of 7zips it should turn the romlist into a treeview where every archive is a node that can be opened up, allowing you to pick the file inside the zip that will be run. Doing this with the latest dll won't work: you just get the standard rom list - the dll is silently rejected.
Some emulators are more than happy to run 7zip files, for instance some RetroArch cores, and even if you pass them an archive of various roms (like a GoodMerge archive in fact), they will run one of the contained roms (it may not be the one you intended though). Perhaps what you are experiencing is this: your 7zip is getting passed to the emulator and working?
There is a solution here, I will find it, its a lot of work and may need to be quite cunning, but i'm keen to get this sorted out for you!
When QuickPlay is told to do any operation to a 7z file, it will first query the 7-zip32.dll for the names of some of the operations it supported at the time John made the original 7zip code against an old japanese version of the 7zip library (these operations can be uncompressing to QuickPlay's temp directory, querying an archive for its files (to display the so-called goodmerge-folder-support), or even zipping operations from the archive tool).
The latest 7-zip32.dll is so different to the one originally coded for (look at the size of it for instance, or try opening it up with 7zip itself and see how different the directory structure is), that those operation lookups will fail if you just replace QuickPlay's version of the dll with the latest available. When that happens, QuickPlay will silently then refuse to perform any 7zip operation on the 7zip rom you're asking it to act on, and will instead pass the 7zip file itself to the emulator. A good indicator that this will happen is if you right click a rom and look at the command to run: QuickPlay will do this operation to check if it will be successful and will show you instead that the 7zip is going to get passed to the emulator. Another indicator that all is not well if you use the latest 7-zip32.dll, is the so-called goodmerge-folder-support itself: if you turn this on in a folder full of 7zips it should turn the romlist into a treeview where every archive is a node that can be opened up, allowing you to pick the file inside the zip that will be run. Doing this with the latest dll won't work: you just get the standard rom list - the dll is silently rejected.
Some emulators are more than happy to run 7zip files, for instance some RetroArch cores, and even if you pass them an archive of various roms (like a GoodMerge archive in fact), they will run one of the contained roms (it may not be the one you intended though). Perhaps what you are experiencing is this: your 7zip is getting passed to the emulator and working?
There is a solution here, I will find it, its a lot of work and may need to be quite cunning, but i'm keen to get this sorted out for you!
Re: QUickPlay error
Thank you butter100fly. Please do not do any long, crazy work on my behalf. I have no problem with doing what I posted. When I said to just use 7-zip32.dll from the 7-Zip install, I was referring to me using that and not for the QuickPlay community. I really do appreciate the work that you put into QP. I want you to enjoy it and not feel like this is work. Please, address other issues and requests that may be more appealing to you. If this is one of those things that requires time and research, then so be it. It is not a show-stopper.
Thank you,
Jason
Thank you,
Jason
-
butter100fly
- Posts: 278
- Joined: Fri Apr 29, 2016 8:13 am
Re: QUickPlay error
Thanks Jason, very nice of you to say, but i'm not a quitter 
. I DO consider this a critical bug (as MarcoForce labelled it earlier in this thread). Why? Its an interesting conumdrum because lzma2 is not really making the things we do in this domain any better, but nevertheless Igor DID make lzma2 the default method of 7zip in 2012, and QuickPlay is very connected with 7zip. So QuickPlay has been effectively 'broken' for all this time, because as you say, if you compress any file to 7z using 7zip's defaults, and try and open it in QuickPlay, it won't work: and of course I agree with you that particular use cases are irrelevant given that single fact, there are a few reasons why this didn't become such a problem in many situations, but c'mon: 7 years broken! That's not acceptable.
Can you please test QuickPlay 4.6.6 that I just released, as I believe it enables lzma2 decompression support and therefore fixes your problem
let me know!
. I DO consider this a critical bug (as MarcoForce labelled it earlier in this thread). Why? Its an interesting conumdrum because lzma2 is not really making the things we do in this domain any better, but nevertheless Igor DID make lzma2 the default method of 7zip in 2012, and QuickPlay is very connected with 7zip. So QuickPlay has been effectively 'broken' for all this time, because as you say, if you compress any file to 7z using 7zip's defaults, and try and open it in QuickPlay, it won't work: and of course I agree with you that particular use cases are irrelevant given that single fact, there are a few reasons why this didn't become such a problem in many situations, but c'mon: 7 years broken! That's not acceptable.Can you please test QuickPlay 4.6.6 that I just released, as I believe it enables lzma2 decompression support and therefore fixes your problem
let me know!
Re: QUickPlay error
Thanks butter100fly. Much appreciated! So far, so good. No errors with LZMA2.. I think you can finally put this one to rest! 
I will let you know of any issues
Jason
I will let you know of any issuesJason
-
butter100fly
- Posts: 278
- Joined: Fri Apr 29, 2016 8:13 am
Re: QUickPlay error
Great: that was sure a priority.
And I totally agree you have also correctly highlighted No-Intro as another long-overdue priority, its not acceptable that QuickPlay has any issues displaying and launching No-Intro sets in 2019. If at all you could help me by posting a requirements list, the world will benefit!
And I totally agree you have also correctly highlighted No-Intro as another long-overdue priority, its not acceptable that QuickPlay has any issues displaying and launching No-Intro sets in 2019. If at all you could help me by posting a requirements list, the world will benefit!
Re: QUickPlay error
Hi I'm having this very issue. Didn't know at first what was going on but then I searched for the error in this forum and found this thread.
My old qp and new qp seem to behave similarly regarding this.
I opened some of my good merged roms to include some hacks I got later and then added them to the 7zip file with 7z and yeah, it's LZMA2 now which makes both qp unable to open it.
So if I extract that and re-add it to LZMA it seems to work.
The thing is... I added many hacks to different roms and it's kinda messy to be extracting and re-adding roms again. Even worse I don't even remember some of the roms I should change now.
So... any tips?
My old qp and new qp seem to behave similarly regarding this.
I opened some of my good merged roms to include some hacks I got later and then added them to the 7zip file with 7z and yeah, it's LZMA2 now which makes both qp unable to open it.
So if I extract that and re-add it to LZMA it seems to work.
The thing is... I added many hacks to different roms and it's kinda messy to be extracting and re-adding roms again. Even worse I don't even remember some of the roms I should change now.
So... any tips?