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 - Pr3tty F1y

Pages: [1]
1
clrmamepro doesn't alter filter attributes to hidden anywhere.
There might be cases during a scan where rom/sample files/archives or files inside such archives get their file attributes altered. But only +a, -r.
Datfiles or settings files' file attributes aren't touched at all.

I'm not disputing you, but I literally just saw it happen. I Already had an older "Sega - Game Gear (20241203-185356).dat" that was not hidden in my datfiles directory. I drag'n dropped the attached updated dat file dated 20250320-141239 into the profiler:



I had the datfiles folder up on my second monitor and it was pulled in as a hidden file:





I'm not sure what else could be causing it, but extracting the dat file manually does not create a hidden file. I do see that the zip file has the Windows "block" attribute on it as it was a downloaded file. Any other thoughts?

2
I can't track down what specific process is causing this to occur, but I drag'n drop dats from No-Intro into the CLRMamePro profiler to update the dats and then do a scan (because it's usually multiple dats from the daily "Love Pack" from No-Intro, it ends up being a batch scan regardless). However, random dats continually end up being altered with a file attribute of 'hidden' but they're not going into CLRMamePro that way. So I'm thinking it's definitely CLRMamePro doing it and I'm not manually choosing to hide anything. It just seems to be occurring idiosyncratically. Thoughts?

3
clrmame Discussion / Re: clrmamepro 4.046a released
« on: 18 August 2022, 14:22 »
That fixed it. Thanks much!

4
clrmame Discussion / Re: clrmamepro 4.046a released
« on: 18 August 2022, 11:43 »
Sure thing.

Here is what CLRMamePro displays:
Code: [Select]
Discs [folder: Discs - size: 0]
unneeded diskimage: D:\Roms\Sony - PlayStation [T-En] Collection\Discs\iS - Internal Section (Japan) [T-En by GameHacking.org v1.02].chd [not fixed]
unneeded diskimage: D:\Roms\Sony - PlayStation [T-En] Collection\Discs\Langrisser IV (Japan) [T-En by Kil v1.3].chd [not fixed]
unneeded diskimage: D:\Roms\Sony - PlayStation [T-En] Collection\Discs\Policenauts (Japan) (Disc 1) [T-En by JunkerHQ v1.01].chd [not fixed]
unneeded diskimage: D:\Roms\Sony - PlayStation [T-En] Collection\Discs\PoPoLoCrois Monogatari II (Japan) (Disc 1) [T-En by LostOkina & Wyrdwad v0.3] [i].chd [not fixed]
unneeded diskimage: D:\Roms\Sony - PlayStation [T-En] Collection\Discs\PoPoLoCrois Monogatari II (Japan) (Disc 2) [T-En by LostOkina & Wyrdwad v0.3] [i].chd [not fixed]
unneeded diskimage: D:\Roms\Sony - PlayStation [T-En] Collection\Discs\PoPoLoCrois Monogatari II (Japan) (Disc 3) [T-En by LostOkina & Wyrdwad v0.3] [i].chd [not fixed]
unneeded diskimage: D:\Roms\Sony - PlayStation [T-En] Collection\Discs\Yutona Eiyuu Senki - TearRingSaga (Japan) [T-En by Aethin v1.04].chd [not fixed]




5
clrmame Discussion / Re: clrmamepro 4.046a released
« on: 17 August 2022, 20:54 »
I'm having an odd issue with a handful of CHDs from a *.dat file.

I verified that the CHDs have the correct internal SHA-1 via CHDMan. However, I don't think CLRMamePro 4.046a is even getting that far.

If the CHDs exists in the correct directory, they're flagged as unneeded. If removed from the directory, CLRMamePro states they are missing. The unneeded and missing exceptions do not occur concurrently. It's only one or the other.

File names are exact and I'm not picking up anything funky in the dat.

Out of a little over 100 chds, only like 6-7 are showing this issue and I can't find a systematic reason within the dat as to why that would be occurring and I'm not aware of any option in CLRMamePro that would allow me to see how it's interpreting the dat.

EDIT: Removing the CHD's from their sub-directory and into the base directory and enabling "Allow CHDs in ROMPath root' seems to be a temporary fix, although I do think this points to some sort of bug.

Pages: [1]

Page created in 0.066 seconds with 21 queries.