Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

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.

41

clrmame Discussion / Re: something to test

« on: 23 September 2014, 11:09 »

I'm currently rebuilding the entire TOSEC (main) collection uncompressed, using the standard TOSEC folder hierarchy, (for reasons I already mentioned in other thread) so this should be a good test. I'll feedback how it goes.

Full TOSEC (main) collection rebuild completed.

Using WIP 20140917 exe, rebuilding to uncompressed, rebuilding from uncompressed/RAR v5 mix of files.

No major problems experienced, except:
- CMP crashed on 'C64 - Games - [D64]' DAT when adding one missed file from previously rebuild run (but then this DAT does include around 100k small files/folders so not that surprised, might not have even been CMP fault)
- CMP *sometimes* left files in backup folder that it shouldn’t. These generally appear to be >260 path ones but not always (I think) and definitely not all of the >260 rebuilt. Was only a handful of files and could not notice any specific pattern. Stupidly I wasn’t paying enough attention at the time to be make a note of which files and 'how' I was rebuilding them.

42

clrmame Discussion / Re: something to test

« on: 18 September 2014, 09:44 »

Re 32k, so far so good. I'm currently rebuilding the entire TOSEC (main) collection uncompressed, using the standard TOSEC folder hierarchy,  (for reasons I already mentioned in other thread) so this should be a good test. I'll feedback how it goes.

Regarding \\?\, do you think it cleaner to have CMP prefix this internally to all paths by default rather than have end user specificity specify if needed? If it makes no difference I mean...

43

clrmame Discussion / Re: Is this possible?

« on: 18 September 2014, 06:41 »

Thanks... I will test this morning and feedback.

44

clrmame Discussion / Re: Is this possible?

« on: 17 September 2014, 17:00 »

http://redsplinter.com/tosec/%5bST%5d.rar

Here is the Atari ST DAT I was using + some files that are short and overlong.

I'm rebuilding/scanning everything uncompressed, no packer involved at all.

45

clrmame Discussion / Re: Is this possible?

« on: 17 September 2014, 16:47 »

Uncompressed... no packer.

46

clrmame Discussion / Re: Is this possible?

« on: 17 September 2014, 14:37 »

Hmmm... not all peaches and cream unfortunately.

It seems to rebuild OK (both Source and Destination I added \\?\) but when I go to scan, it throws up this 'fix' which it (unsurprisingly) cannot complete.





I've added \\?\ to the 1st ROM path.

47

clrmame Discussion / Re: Is this possible?

« on: 17 September 2014, 14:15 »

OK, let me swap them out now and continue...

48

clrmame Discussion / Re: Is this possible?

« on: 17 September 2014, 14:10 »

Testing 32k (with offical binary atm since all existing paths) and seems to work perfectly with uncompressed sets.

49

clrmame Discussion / Re: Is this possible?

« on: 17 September 2014, 09:00 »

Nah... no good. Think I'm going to have to give up on this plan.   

I was thinking on the way home last night that I don't think I will be able to get it to work anyway due to the mix of single ROM sets and multi ROM sets. Frustrating.

Thanks for checking though.

50

clrmame Discussion / Re: Is this possible?

« on: 16 September 2014, 13:30 »

OK, came up with a new idea…

Since I already have a 100% complete TOSEC collection in RAR format, which is organised as:
X:\TOSEC\Acorn\Applications
X:\TOSEC\Acorn\Demos
X:\TOSEC\Acorn\Games
blah blah

I thought I'd Dat2Dir the whole lot to make 1x custom DAT by pointing Dat2Dir at X:\TOSEC\ and enabling 'Set-Subfolder Mode' and disabling 'Keep Archives As Files'.

BUT can't seem to get it to play ball, it doesn't retain the paths in the DAT.

Any ideas of the magic toggling of options that I might be able to achieve this?

51

clrmame Discussion / Re: one more thing...

« on: 12 September 2014, 15:45 »

ok...while the 32k path support seems to work (wonder if anyone tested it yet)...

Not yet, but planning too... busy converting TBs of archives from RAR2.9 to RAR5.0!

52

clrmame Discussion / Re: Is this possible?

« on: 27 August 2014, 13:00 »

Hahaha... there you go then, put the snotty tissues in the bin and get find&replacing.   

53

clrmame Discussion / Re: Is this possible?

« on: 27 August 2014, 12:44 »

Thanks, that would be appreciated.

RE 32k, I know both WinRAR and 7-Zip can handle >260 paths no problem. Don't know about SDK though, I know you've said before how poor the 7-Zip SDK is in general.   

32k path support would be great.

54

clrmame Discussion / Re: Is this possible?

« on: 27 August 2014, 12:04 »

OK, I understand. Maybe something for the future...

Thanks for coming back to me so promptly anyway.

55

clrmame Discussion / Re: Is this possible?

« on: 27 August 2014, 11:32 »

Hmmm… I suspected as much. Is this something that you would consider adding for ROMs too, given it exists for CHD already?

Maybe if I explain WHY, rather than you thinking I don't know what the hell I'm doing…

I've started keeping a WIP mirror of the whole TOSEC (main) collection, in the same hierarchy but uncompressed. The reasons for this are many, but it's mainly so I can make high level changes, such as renaming/amending (then dir2dat) orphaned DATs, searching for duplicate ROMs, searching and amending specific publishers/flags…. all this kind of stuff.

Whilst there are some multi rom TOSEC DATs, in general it is overwhelmingly 1 rom per 1 set (single file) DATs. Therefore I have them organised as above, i.e. rom_path\rom1, rom2, rom3 unless they are multi rom per set were as obviously I have them arranged in the traditional MAME style. I've done this because: 1) I don't have to (manually) rename both a folder AND a file, 2) avoid over long path issues, 3) it makes identifying wrong extensions easier.

Now… this is all fine and 'setup', BUT once a new release is out I have to update all the DATs/ROMs which have submitted to me outside of the changes I have made to my mirror. MASSIVE pain in the ass doing this manually, AND easy to cock up if not paying attention.

I do appreciate that this is rather a specific issue to me, but if it is easy to implement it would be a huge help.

56

clrmame Discussion / Is this possible?

« on: 27 August 2014, 10:34 »

What I'm trying to do (I have reasons!):

I have a DAT with 1 rom per 1 set. I want to keep the roms uncompressed, and I want to keep them all in the root of the rom path, and have CMP able to scan them (rebuilder doesn't matter), i.e:

not like this:
rom_path\set1\rom1
rom_path\set2\rom2

but like this
rom_path\rom1
rom_path\rom2

This is akin to how you can choose to have CMP deal with CHDs, though on a DAT level rather than global.

Is this possible?

57

clrmame Discussion / Re: Problems with the latest TOSEC release

« on: 26 August 2014, 11:28 »

Dammit! I thought I was being so smart... hahaha

That's good news, and even speedier than normal.   

58

clrmame Discussion / Re: Problems with the latest TOSEC release

« on: 26 August 2014, 10:16 »

Hmmm... amendment to theory:

If a zip archive then CMP just reads CRC32 from zip header right? But if checking SHA-1/MD5 then it extracts to 'temp' folder and hashes the file? (I'm guessing)

I would wager the temp folder + filename is too long, wherever CMP is installed.

Anyway... enough interfering from me. Just thought I'd jump in since was reading board and caught my eye as the TOSEC guy. 

59

clrmame Discussion / Re: Problems with the latest TOSEC release

« on: 26 August 2014, 09:33 »

or the sha1 stated in the dat is wrong.

The CRC32/MD5/SHA-1 in the DAT is definitely correct. 

Since this particular image has a very long file name due to containing multiple software in one dump, I would guess that the whole path length issue is what is causing your problem.

60

clrmame Discussion / Re: Dir2Dat

« on: 10 July 2014, 09:09 »

Yup.... it pisses me right off prepping the next TOSEC release. LOL.

In reality it is not a big deal, most (all?) modern 'ROM' managers can handle either EOL type DAT, I just like to keep all the TOSEC DATs in Windows format rather than Unix for consistency, and therefore it's just ANOTHER thing to check when new DATs get submitted.

Though I guess it does serve a practical purpose when contributors are manualy checking/amending DATs, though I would hope they using something a bit more sophisticated than vanilla Notepad!