Thank you for this, needed to convert several hundred .flacs to .ogg on my CentOS (release 5.3) running Subsonic, this did it flawlessly!!

Cheers

Ab
Back to top

glad it was of use, I use this one all the time myself as well, and it 'just works', which is what I want.
Back to top

I forgot about this thread, etique's suggestions for cleaning directories was a good one, not sure why that never got done, maybe it was because I thought 3.0 would be coming soon, heh. That's now implemented with the new --clean option. Use with --test option first to make sure nothing unexpected happens!!

Note that acxi 3.0 uses File::Find for all file and directory syncing, which allows for much better and more granular control.

Some items get adjusted, ` is removed, though I'm not sure it needs to be anymore with the new syntax. I should have checked that for the new acxi.

Anyway, 3.0 is very much cleaner than 2.9 was, it's similar internally to inxi, which was also rewritten in 2018 to Perl 5, so I wanted their styles to be similar internally.

Note that acxi now uses Perl builtins for cp/copy, find, and mkdir. And it would also use native Perl features for rm if that was added. The goal is that the only subshells used are the direct lame, oggenc, and metaflac that acxi uses to encode the compressed files. That way acxi will be cross-platform without any further work.

I still use acxi all the time, heh.
Back to top

I've iimproved the --clean option to now double verify all deletions, I have stuff in my compressed directory that is not in my source directory, so I realized it can't just blindly delete, now it will confirm first the directories, then the files, as 2 groups, you can exit that, and probably should, if you see something you were not expecting to see happen. Automatic deletions are very dangerous, so i decided that a double confirm coupled with a listing of files/directories to be deleted would be an absolute requirement. This feature can also be used with the --test option, though you will see what is going to happen before you confirm it no matter what.

The forking item is interesting but I'm not sure I'll do that for this 3.0.0 release, if there is real interest, maybe I will do it for the 3.1.0 release, if that ever happens.
Back to top

FYI and sorry for the thread necro, but I updated this forking approach to the most recent version of acxi on github and it seems to work well. Happy to share if interested.
Back to top

Can I see the code?

I'd be curious about forking logic and code.
Back to top

Sure thing, here's a link to the modified file:

[link]

(I am assuming its best not to paste all the code here on the forum).

Its still making use of that forking Perl module and I've hard coded the number of cores (7) in the line:
my $pm = new Parallel::ForkManager(7);

But as the original poster said this can be added as an option in the config file.
Back to top

that looks pretty doable. Having the module load be dynamically tested is not a problem, it would simply exit on failure to load if forked was requested but not present on the system.

I don't see any real reason not to add this logic to acxi, with extra tests etc to make sure module is available, thanks for posting this.

What happens if you request too many forks, more than the system can handle? or is that not how it works? Is the fork max directly connected to the thread max, say, for a multithreaded cpu like recent intel or amd ryzen, the thread count is 2xcore count.

I guess I can find out by testing it.

This will make a nice 3.2.0, though I also had something else in mind, but I'm too lazy to make, heh.
Back to top

tested this, very impressive.

without forking, converting a test flac directory with 15 files on this cpu:









and just to see how it works with > number of cpu threads:



so pretty impressive.

I'll have this on github later today, thanks.

This uses the new config value $FORK, defaults to 1, so no fork, tests user data, tests module presence if $FORK > 1, exits.

Haven't updated the man page, will do that later.

I didn't realize the speedup would be so big, that's very impressive, glad you posted, thanks.

I've pushed 3.1.4 with forking stuff just so it can be checked etc, I'll do a bigger test on it on my main music system, but that one is only dual core so it won't be a huge speedup.
Back to top

Note that there's an oddity which is somewhat expected in terms of the output/return values of each fork, for debugging purposes those would be nice to get resolved, but not a huge deal.
Back to top