Off-Topic > SCM EXtensions

ripperX scm Bug Feedback

<< < (2/3) > >>

Jason W:
It is still working.  But be sure to select a writable target directory in the Config tab.

SamK:

--- Quote from: Jason W on April 23, 2012, 08:49:51 AM ---It is still working.  But be sure to select a writable target directory in the Config tab.

--- End quote ---
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.
Results
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.
 

Jason W:
Ok, I see it when using the same onboot.lst.

I will have time Wed. evening to look more into it.  I ran an ldd on the lame binary and library and nothing appeared to be missing in the extension, but evidently there is more to it.

Jason W:
Ripperx is wanting ncurses installed in the normal path, and is not working with a rebuilt one in the extension.  I will rebuild ripperx straight from source when I get a chance, and that will likely solve the issue.

SamK:
Thanks for the progress report.
   

Navigation

[0] Message Index

[#] Next page

[*] Previous page