Running igir multiple times removes roms from the output directory

[IDmedia]

Paste the command

igir.exe move extract test clean report --dat .\dats --input .\input --output .\output\roms{batocera} --clean-backup .\trash --report-output report.csv --only-retail --no-unlicensed --no-bios --single --prefer-revision "newer" --prefer-region "USA,WORLD,EUR,JPN"

Describe the bug

Not sure if this is a bug or not, but at least I don't understand why this should be happening. I run the above command and get this:

√ Scanning for DATs ··············· | 4 DATs found
√ Scanning for ROMs ··············· | 6 802 files found
√ Nintendo - Game Boy ············· | 1 048/1 071 retail releases written
√ Nintendo - Game Boy Color ······· | 933/933 retail releases written
√ Deleting moved files ············ | 11 moved files deleted
√ Cleaning output directory ······· | 38 files recycled
√ Generating report ··············· | C:\Users\neoid\Desktop\batocera\app\bin\report.csv

If I run the exact command ones more:

√ Scanning for DATs ··············· | 4 DATs found
√ Scanning for ROMs ··············· | 6 782 files found
√ Nintendo - Game Boy ············· | 1 039/1 071 retail releases written
√ Nintendo - Game Boy Color ······· | 930/933 retail releases written
√ Deleting moved files ············ | 7 moved files deleted
√ Cleaning output directory ······· | 19 files recycled
√ Generating report ··············· | C:\Users\neoid\Desktop\batocera\app\bin\report.csv

...and again:

√ Scanning for DATs ··············· | 4 DATs found
√ Scanning for ROMs ··············· | 6 775 files found
√ Nintendo - Game Boy ············· | 1 039/1 071 retail releases written
√ Nintendo - Game Boy Color ······· | 925/933 retail releases written
√ Deleting moved files ············ | 2 moved files deleted
√ Cleaning output directory ······· | 7 files recycled
√ Generating report ··············· | C:\Users\neoid\Desktop\batocera\app\bin\report.csv

The numer of GBC roms keeps on decreasing on every run. Is there some behaviour I don't understand? Any reason why it should delete files from the output directory if the dat file doesn't change?

Expected behavior

I expected that running the same command multiple times would yield the same result.

A) I don't expect that running the same command multiple times removes some roms from the output directory

B) The output should list all dats found and their current state. Currently it only lists the dats that have roms in the "input" directory. It would be nice to have a summary for all dats in the "dats" directory, not just those who have roms in the "input" directory. That way it would be quick and easy to figure out what romsets are incomplete.

Debug logs

On this run it removed these three roms:

• Trip World DX (World) (Limited Run Games)
• UEFA 2000 (Europe) (En,Fr,De,Es,It,Nl)
• Visiteurs, Les (France) (GB Compatible)

igir_removing_roms.txt

DAT(s) used

Nintendo - Game Boy Color (Parent-Clone) (20240831-005749).dat

igir version

v3.0.0

Node.js version

N/A

Operating system

Windows 11 64-bit

Additional context

No response

[emmercm]

@IDmedia do you happen to have the three different reports that were generated?

[emmercm]

@IDmedia I think it's because you're not supplying --input '.\output\roms'. What's happening is 1G1R rules are being applied based on only the ROMs found in your --input <path>s, so after file moving, the files left behind in .\input are the non-preferred copies. Running the same command again will prefer the next-preferred copies from .\input, which will delete the previously-preferred copies from .\output\roms.

[IDmedia]

Thanks a lot for the clarification! I thought that logic would be handled internally, but it makes sense :)

[emmercm]

No problem @IDmedia! I realized the documentation was weak in this area, so I tried to clarify it in #1338.

[github-actions]

🔒 Inactive issue lock

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Comment generated by the GitHub Lock Issues workflow.