EMULAB Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

The new forum is online, hope you enjoy it!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - yeahimdukenukem

Pages: [1]
1
clrmame Discussion / Re: Split vs Merge
« on: 27 March 2021, 22:59 »
Sorry for the delay.
I have just tested and it seems to work fine now.
Explicitely set "Merge", but it did a "Split" as set in the dat file.

Thank you so much :D

2
clrmame Discussion / Re: Split vs Merge
« on: 25 March 2021, 02:00 »
Wow, you are just awesome :D

Thank you very very much.

3
clrmame Discussion / Re: Split vs Merge
« on: 24 March 2021, 17:21 »
That'd be great, thank you so much :D

4
clrmame Discussion / Re: Split vs Merge
« on: 24 March 2021, 13:43 »
I understand, you are right, from that perspective it is really expected.
What I would like to do is always merge as much as possible, that's why I chose Merge instead of "Per profile merge-options". Would it be possible to add a checkbox or something like "Respect forcemerging tags" even if "Per profile merge-options" is NOT selected? Or is there any other way to let it merge instead of split or non-merge when batch scanning? Maybe I'm just using it wrong.
Thank you so much for your great work, very much appreciated :)

5
clrmame Discussion / Split vs Merge
« on: 23 March 2021, 22:09 »
Hi Roman,

I have discovered a weird issue. Or at least it was an issue for me until I recognized:
The batch scanner seems to ignore forcemerging tags in dat files. So if I batch scan with merge mode on, it does a merge even if the dat file has "forcemerging split" set.
Now that I am aware of, I can circumvent the issue, but it's not what I expected.
So maybe an issue or maybe not :)

Thanks and best regards Duke

6
clrmame Discussion / Re: Hash collision (Bug?)
« on: 23 August 2018, 09:09 »
The running speed has not changed with your changes in my opinion.
HBMAME really has grown A LOT in the last few releases and scanning it as merged set really takes 5 times as long as before (or even longer). But I don't think this is related to Clrmamepro.

7
clrmame Discussion / Re: Hash collision (Bug?)
« on: 21 August 2018, 14:27 »
It just took a bit longer to run through the whole scan. It's not slower than before.
I just tried to verify that it works, without scanning the whole HBMAME dat again, because in the current version 0.200 it took more than 24 hours to scan ;)

But anyways thanks for the great hint, I haven't been aware of that dialog. I have been looking for a tool to explore sets for so long and it was there all the time :-D

8
clrmame Discussion / Re: Hash collision (Bug?)
« on: 20 August 2018, 11:46 »
It took very long to retest this, but I can confirm that it seems to work now.

Thank you man, you are the best. =)

9
clrmame Discussion / Re: Feature Request
« on: 20 August 2018, 06:30 »
Ok, this seems to work just fine now.

Thank you so much :)

10
clrmame Discussion / Re: Feature Request
« on: 08 August 2018, 14:49 »
Sadly I have just discovered another problem:
The batch creation of the HAVE list depends on the merge mode set in the profile itself (which is SPLIT by default) and ignores the setting of the batcher.
For example: Scanning a merged collection (without missings) with the batcher in MERGED mode results in missings in the HAVE list.
Have I explained this understandable? Sorry for my bad english :)

Many TIA and best regards,
Duke

11
clrmame Discussion / Re: Hash collision (Bug?)
« on: 08 August 2018, 05:56 »
First enjoy your holidays and have fun :-D

12
clrmame Discussion / Hash collision (Bug?)
« on: 07 August 2018, 07:39 »
Hi Roman,

I don't know if this is a bug or not, maybe I don't understand correctly.

Let me try to explain:
I have a problem on the newest HBMAME 0.200 dat.

In full merge mode, when detecting a hash collision, I assume the correct behaviour is to move the collided roms into subfolders with the name of the corresponding clone set. Is that right?

A hash collision is detected when there are two or more roms with the same name, but different CRCs, is this correct?

In this dat now I have two roms with the same name, same size AND same CRCs, but only different SHA-1 values. In this case it seems Clrmamepro does not detect the collision.
Am I understanding something wrong? Please correct me.

I can provide the roms for testing purposes if you need them, these are:
Code: [Select]
kov2p204s08/v204-32m-p08.rom
kov2p204s50/v204-32m-p08.rom
and
Code: [Select]
sfiii3nrs02/sfiii3s03-simm1.0
sfiii3nrs02/sfiii3s03-simm1.1
sfiii3nrs02/sfiii3s03-simm1.3
sfiii3nrs03/sfiii3s03-simm1.0
sfiii3nrs03/sfiii3s03-simm1.1
sfiii3nrs03/sfiii3s03-simm1.3

Thanks and best regards,
Duke

13
You are completely right.
It's just because of 2 reasons (especially for me):
1. Scanning is much faster on uncompressed ZIPs
2. Afterwards compression of all uncompressed ZIPs together into one 7z file gives a much higher compression

For now I just reuncompress all zips via script after scanning. It's just a matter of saving time for me and I thought it could be possible.

Thank you very much,
Duke

14
clrmame Discussion / ZIP without compression (new feature?)
« on: 01 August 2018, 06:19 »
Hi again,

Maybe this is already implemented, but I really cannot find it.
Please please tell me, is it possible to create zip files without any compression using Clrmamepro?
The Recreator (as well as the Scanner when it adds data) always compresses the data. For 7z and RAR it is possible to configure, but not for ZIP. Or I just couldn't find yet.

Thanks again so much for your awesome work,
Duke

15
clrmame Discussion / Re: Feature Request
« on: 26 June 2018, 12:52 »
I can confirm, both are fixed.
Thank you so much, you are the best :-D

16
clrmame Discussion / Re: Feature Request
« on: 25 June 2018, 09:25 »
Using this feature is so great, I want to thank you again :)

And another minor bug, I just recognized, but doesn't bother me:
Changing the directory to save the lists is only possible via the "..."-Button. Typing into the EditBox is ignored.

Thanks again for this excellent tool, your work is much appreciated.

17
clrmame Discussion / Re: Feature Request
« on: 13 June 2018, 11:34 »
Awesome man  :D
Seems to work great.
Just a minor bug report:
If I select to only save the HAVE list, it also saves the MISS list.

Despite from that, thank you so very much, you are the best. =)

18
clrmame Discussion / Re: Feature Request
« on: 07 June 2018, 15:09 »
...question is if the output is good enough to use....and question is where to store it automatically...so maybe a folder has to be specified, too...
Well, for me it is really good, as I'm only using it on complete sets.
And you are right, sorry, someone would have to specify a path, I forgot that.
I put it on the request list.....but don't expect anything anytime soon....there are requests on the list which are decades old...and some are implemented directely....
I know, there are more important things to do, but I'm happy that you have it on your list now.
Thank you so much. Awesome guy, awesome tool =)

19
clrmame Discussion / Re: Feature Request
« on: 07 June 2018, 14:44 »
Yes, exactly that setname list, which can already be manually created.
I know, it's not accurate. I'm just using it as a human readable well looking content list for easy searching.
Is it much work to trigger the creation on batch scanning?
I just mean the same way as logs and fixdats can be created on batch scanning.
Sry for my bad english, I hope I could describe my wish :)

20
clrmame Discussion / Feature Request
« on: 07 June 2018, 08:13 »
Hi Roman.

First thanks for your awesome work.
I just would like to sugggest one little feature that would me a huge amount of time:
For every scanned dat file, I let Clrmamepro create a HAVE-list text file, just for the style of my collections and later searching purposes.
Would it be possible to add a checkbox or something to let Clrmamepro batch create those HAVE lists alongside the batch scanning?
That would be so great.

Many Thanks in advance.

Pages: [1]

Page created in 0.066 seconds with 14 queries.