EAC3TO Requests and General Discussion

[oniiz86]

Thanks for that @Rocky @Curly, it's much appreciated, I'll let them know.

[Rocky]

You're welcome and thank you.

[skull]

I've had a busy summer myself, but just want to also say thank you to @Curly. Best of luck with any health or medical issues! May you be happy and free from suffering good sir. <3

[Curly]

Thank you, sir! And same to you.

I'm thinking of adding skip first/skip last to eac3to. That will take care of one of our open issues.

[oniiz86]

Hey @Curly I was wondering if you may be able to tackle that DTS-HD DialNorm removal bug that I had brought up about a year ago as I see you were working on @aron7awol's THD DialNorm removal issue, has that been resolved? Will you be able to tackle some of the main eac3to bugs on the "To-Do list" like PGS subtitles crashing with MKVs & LPCM 1.0 Mono tracks crashing eac3to?

[Curly]

yeh i no
tell me again
linux sucks all the O2
what to do

[Levi]

DGIndexNV (linux)
dream

[Curly]

sure

[oniiz86]

@Curly Sorry was your above post in response to my post above, it wasn't quite clear, it's a bit odd that @aron7awol has not responded in regards to his THD DialNorm removal issue.

[Curly]

That was a sarcastic reply to Levi.

I'll try to get time on our machines ASAP to address your matters. Sorry for the delays.

BTW, aron7awol wants me to simply remove dn completely for THD and EAC3 because formally it breaks the streams, not sure about DTS.

[oniiz86]

No problem at all, it is a bit of an anomaly that DTS-HD HR/MA tracks with DialNorm cannot be removed so easily as it is with lossy DTS, hopefully you'll be able to squash that one.

[Curly]

i'll do my best

[Superb]

The last 5 files matching "log*.txt" are retained.

Would it be possible to add an option disable that behavior? I keep losing log files because of this.

I also think that log files for failed operations/help are not useful in most scenarios (perhaps only if you can't read the command line output at all).

It's also problematic, because log*.txt is a very generic name, it can remove other programs' files. And it doesn't warn the user in any way.

[n_m_n_n_sc_o]

The last 5 files matching "log*.txt" are retained.

Would it be possible to add an option disable that behavior? I keep losing log files because of this.

Please! I use the filename format "log*.txt" for many things, and this puts completely unrelated files at risk of deletion without warning.

[AYColumbia]

Just use the -nolog option in the .ini file and then specify your own log file in the command. That's what I do and it works great.

[Superb]

Just use the -nolog option in the .ini file and then specify your own log file in the command. That's what I do and it works great.

It'a hassle to do that every time though...

[AYColumbia]

Just use the -nolog option in the .ini file and then specify your own log file in the command. That's what I do and it works great.

It'a hassle to do that every time though...

Consider writing a simple wrapper that moves the default log files. In Windows I'd use a cmd file for example. Otherwise request a new feature to add a .ini setting that can use something like -disableLogCleanup or the like.

[Curly]

i cud make a slipstream that changes the default name to elog*.txt
wud that be useful to you guys?

[AYColumbia]

i cud make a slipstream that changes the default name to elog*.txt
wud that be useful to you guys?

I'm good with how it is now so whatever others need.

[Curly]

hehe
new avatar?
cudn't identify it with google lens
ill change to elog.* then
thanks mister

[AYColumbia]

hehe
new avatar?
cudn't identify it with google lens
...

LOL...whew!

[Superb]

I don't think that solves the issue, the log files can still get overwritten if you run too many commands, even if they error. I would love to just disable that behavior entirely.

[n_m_n_n_sc_o]

ill change to elog.* then

log.* is fine (either is fine really) but could you just not have it delete any files?

When I am running operations (sometimes many back-to-back) it is difficult to keep track of how many log files I've created, for what, and which I need to keep. It is trivial for me to go back afterward and clean up/delete anything I no longer need; however, it is sometimes completely devastating to realize that I did one thing too many without intervening to protect my log files and have inadvertently deleted an important log file(s) and must now repeat my entire sequence of operations to reconstruct things.

[AYColumbia]

I'm not sure how most deal with log files, but speaking for myself, I don't like any tools that automatically create logs in the file system so, for me, I love the -nolog option. Same goes for whether log files should be kept indefinitely and managed by the users. Another issue mentioned is some get overwritten which makes sense PIDs aren't going to be unique all the time.

I'd humbly ask for two changes in logging that I think can help:
- change the naming to use logYYYYMMDDHHmmssttt (where HH is 24hr fmt & ttt is the milliseconds). This would help with sorting too having the date/time stamp to the ms.
- add an .ini option like -keepLogFiles that would NOT delete at all (not having this setting would use default TTL behavior).

Thanks for the consideration.

[Curly]

Thanks, AY. It's hard because everybody's asking for different behavior. I'll review it all and try to come up with something that satisfies everyone.