It is still working. But be sure to select a writable target directory in the Config tab.
I am confident it is not a rights issue as otherwise the wav, ogg and flac files would not be written as they all use the same location.
As a double check, the scm and md5 files were deleted together with /home/tc/.ripperXrc. The scm was then freshly downloaded from ibiblio. The md5 verified OK. The only packages installed other than ripperX are the tczs in onboot.lst as described in reply #4. The ripper target directory was pointed to /home/tc to exclude any writing issues.
Successfully rips to wav
Successfully rips to wav and successfully encodes to flac
Successfully rips to wav and successfully encodes to ogg
Successfully rips to wav but fails to encode to mp3
The matter seems to be in some way related to the encoding of the mp3 from the ripped wav. RipperX does not run this part of the cycle when creating an mp3. An mp3 file is always produced but it is always invalid always having a file size of 2k irrespective of the size of the input file. The wav, flac, and ogg files always produce correct files with an appropriate file size in each case.
To verify that it is encoding the mp3 that is the problem, lame.tcz was then installed. In this state ripperX successfully rips to wav and successfully encodes to mp3.
This pattern is consistent using different machines and different downloads of the scm and different input sources.
Could we agree to run TC with the same packages loaded (onboot tczs and scms) on each of our respective machines? (something similar to the way cloud mode is used to test tcz creation). I would favour something very minimal and also clean downloads of scms from the same repo rather than relying on local copies. This will hopefully eliminate as many variables as possible. Can you see an alternative way forward?
It might also be helpful if another member might test and report their findings.