Infinite loop via FileOptimizer since 0.9.2

[ObiWanCeleri]

I'm a big user of FileOptimizer that calls up ECT as part of a chain.
So lately (as of version 16 of FileOptimizer) ECT has been going into an infite loop at random, usually after processing 10-15 files (by infinite loop I mean ECT is running, using computer cycles and yet never seems to complete it's task).
As per the joined screenshot, when in this loop ECT hovers at one thread and 11Mb of ram. I've tried to kill processes and liberate ram to no avail.
I've also reproduced the issue via a batchfile, called via a console with admin rights, using the following command line :
FOR /f "tokens=*" %%G IN ('dir *.PNG /b') DO (ECT.exe --mt-deflate --mt-file --allfilters -strip -90032 "%%G" >> ECT.LOG)
With the batch file it did take longer to hit a snag (122 files) but it did choke again.
This is a wild guess but I'm thinking here ECT is dynamically reducing the ressources to adapt to whatever other programs are running simultanously but seems to have an issue clawing back the ressources when they are available again. Although I have plenty ram and threads to go when the issue happens.
This might also be CPU-specific.
I can send you a pack with 150 of the PNGs I was using during this test so you can compare apples to apples.
Tried with ECT 0.9.4 and the same behavior is present.
I'm unable to go any further since ECT doesn't spit out an error message. It just runs forever.
The logfile doesn't yield any further information.
I'm more than willing to give you more information if needed.

Here are my specs:
AMD Ryzen 5 2400G with Radeon Vega Graphics (integrated graphics disabled because of PCI-e video card)
4GB NVIDIA GeForce GTX 1650 SUPER, latest gaming drivers
TUF B450M-PLUS GAMING (Latest BIOS) ()
Windows 10 pro 64 bits (French) (11.789.19041.0)
32,0 Go Dual-Channel (tested with Memtest86+) (Re-size BAR enabled)
System is rock-solid so it's not a BIOS configuration issue / bad ram.

[ObiWanCeleri]

Note : Using ECT 0.9.1 in FileOptimizer actually resolves the issue so this is likely an issue with ECT

[fhanau]

I can't think of anything specific that might be causing this – it might be a multithreading issue, but ECT doesn't do anything specific to adopt to system load, that's handled by the OS.

Can you try to provide a minimal reproducible example? That will make this easier to track down, for example try if the issue still happens without --allfilters, without setting a custom mode, without the multithreading flags, when tested on a subset of files...

[ObiWanCeleri]

The command line is not my doing; it's been crafted by the FileOptimizer team.
I will however try to isolate the problem as per your instructions. This might take some time since the problem seems to be random. Lastly, since ECT goes into an infinite loop there is no actual error number to report.

[ObiWanCeleri]

Will be doing a test tonight. Since the issue occurs on what seems like random files (never the same one), I've elected to test the same files (there's 3375 of them so there's no lack different types). Note : they are all Mame screenshots to be more precise.

[ObiWanCeleri]

Sorry I was a bit busy. I'm running the batch files now. Will post the results tomorrow.
Here's the (DOS) batch file for the first run :

@Echo off
REM ECT but without --allfilters
SET count=1
FOR /F %%G in ('dir *.PNG /b') DO (CALL :Fonction "%%G")
Exit

:Fonction
Echo ==== %count% : %1% ====
Echo ==== %count% : %1% ==== >> ECT.LOG
ECT.exe --mt-deflate --mt-file -strip -90032 %1% >> ECT.LOG
set /a count+=1

Other batch files will use variations on line #10 as per your request

[ObiWanCeleri]

Note : Batch file identifies filename because ECT doesn't. Might I suggest a "-verbose n" switch?

[ObiWanCeleri]

Preliminary results, out of a set of 3375 .PNG files generated by MAME (Titles)

Original command line
--mt-deflate --mt-file --allfilters -strip -90032

removing the --allfilters argument
--mt-deflate --mt-file -strip -90032
--> Stopped at file #1177

removing the -90032 custom argument
--mt-deflate --mt-file --allfilters -strip
--> Completed all 3375 files, very quickly

Removing the --mt-deflate argument is a killer for speed. I will post the results as soon as possible.

So far the -90032 argument seems to be the issue; I'm assuming it means "compress level 9, repeat 32 times"?

[fhanau]

So far the -90032 argument seems to be the issue; I'm assuming it means "compress level 9, repeat 32 times"?

It does not, among other things it causes data to be re-compressed 9 times to optimize block splitting, which is very slow and not recommended for most use cases. Removing multithreading is bound to be slow with these options.

Based on the above it sounds like you don't think it's caused by any specific file, but can you check if it hangs when just running on file #1177?

Otherwise, try running with the -9 flag, if that works the feature mentioned above may be responsible for the issues you are encountering.

[ObiWanCeleri]

All tests done with ECT 0.9.4 BTW
Ok finished testing.

Removing the --mt-deflate and --mt-file arguments
--allfilters -strip -90032
--> Stopped at file #149

The culprit is -90032 fer sure.
Please note ... it was working fine in 0.9.1 but doesn't as of 0.9.2 (I will double-check that too)

Tell you what. I'm going to do the same tests with ECT 0.9.1 just to make sure.
I'll post the results here.

BTW I am keeping a log but I get no error message. When ECT goes off the rails, it keeps on eating cycles but doesn't output any result (that I can see).

QUESTIONS :
1 : I looked at the documentation and it says "consult performance.html" which is nowhere to be found?
2 : There is no mention in the documentation of the --mt-file switch. What does it do?
3 : If -90032 repeats 9 times what is the 0032 for?

[krishty]

FWIW, I noticed ECT hanging on two PNGs of mine as well, and this problem surfaced last summer. I too use high optimization settings with multiple block-splitting passes (-30060).

I found one of the affected PNG and I’m trying to reproduce the hang right now with the latest build. If successful, I will attach the image tomorrow.

[ObiWanCeleri]

Testing ECT 091 now with the following batch file :

@Echo off
REM ECT original command line from FileCompressor
SET count=1
FOR /F %%G in ('dir *.PNG /b') DO (CALL :Fonction "%%G")
Exit

:Fonction
Echo ==== %count% : %1% ====
Echo ==== %count% : %1% ==== >> ECT.LOG
Echo [%DATE%  %TIME:~0,8%]
Echo [%DATE%  %TIME:~0,8%] >> ECT.LOG
ECT091.exe --mt-deflate --mt-file --allfilters -strip -90032 %1% >> ECT.LOG
set /a count+=1

This will at least tell you where the issue IS NOT.

[ObiWanCeleri]

I'm confirming here I had an infinite loop with ECT 0.92
Same 3375 .PNG files
This one went into an infinite loop on file # 23

[ObiWanCeleri]

So far ECT 0.91 is going strong, up to file 314 of 3375. It's going to take a while. Will let the program run the night.

[krishty]

Sorry, can’t reproduce my earlier issues. I clearly remember ECT 0.9.3 being stuck on the files for 20+ days without even reaching genetic filtering, but now both 0.9.3 and 0.9.4 complete the files within half an hour. Please disregard my report.

[ObiWanCeleri]

ECT 0.91 processed all 3375 files with no issue.
Using command line ECT091.exe --mt-deflate --mt-file --allfilters -strip -90032 %1%

So let's recap :
Symptom : recent versions of ECT will eventually try to compress the same file forever, requiring a break. It seems to happen randomly and is not caused by one specific file.

• Issue affects ECT 092, ECT 093 and ECT 094
• Seems to affect specific people so might be CPU-dependent (I'm using an AMD Ryzen 5 2400G CPU)
• Caused by the customization string (switch with only numbers) (-90032)
• ECT 091 works absolutely fine so temporary solution is to go back to that version
• Not caused by FileOptimzer since all my current tests are done with a DOS batchfile
• Not caused by multi-threading
• Not caused by the --alfilters switch
• Tested on a pack of 3375 files so results are pretty definitve.
• Machine used to test is rock solid, ram tested with Memtest86+ so it's not a ram issue
• ECT never outputs an error message so ECT doesn't crash per se.
• Test system has 32GB of ram and 8 threads which should be plenty
• No thermal issues and system is water cooled

@fhanau Let me know if there anything I can do on my side to help narrow down the issue even further. I'm available if you want me to run some code and output some extra info in a log file. At this point, this is in your hands.