Just a little update, in case it helps. I've tried this on a machine
that only imports as uncompressed WAV files and the same thing occurs.
Nothing in the logs pertinent to it and when run from console everything
is clean.
What I found watching the /tmp directory is when RDLibrary goes to rip
from the CD, it places the audio in /tmp/rdlibrary_rip.wav. Once it
completes ripping, it's moving it to /var/snd with the name as it
should, but it's also creating a new directory in /tmp in the format
/tmp/rivenedell?????? and moving the rdlibrary_rip.wav file to that
newly created sub-directory. The '?' are 6 random mixed-case
alpha-numeric characters a-z. For instance, the full directory-file
would be /tmp/rivendellSt2Hlm/rdlibrary_rip.wav. This is, of course,
placed in the /tmp of the computer being used to rip as it would be with
a temp file and not on the server (unless I'm ripping on the server,
that is). Now, when the whole rip process is complete, that new
sub-directory and file are not getting deleted and wind up eating up HD
space. It does this for each song on a CD, so if you have 22 songs, it
has 22 temp directories when it's complete with the wav file in it. In
the log, it does show RDLibrary unlinking the final file in /var/snd,
but never shows anything for the /tmp stuff. One last note, the file
being put in the subdirectory is the full uncompressed WAV file, even if
you're using MP2.
All 3 systems I've tried this on are all running the same versions and
are all broadcast appliance boxes with all updates applied and all have
the same outcome. The OS is showing CentOS 6.9 and rivendell 2.15.3.
I've only perused cdripper.cpp so far, but haven't found anything. I'm
going to try rdexport.cgi and see if something there is doing it. I'm
assuming if this is happening to others, most won't find it until it
actually fills the partition holding /tmp. Which on my small production
250Gb hard drive didn't take long. I'm not saying 100% it's a RD thing,
but if it is, if folks look in the the /tmp directory they may be
surprised at how many rivendell????? sub-directories they find in there.
One last thing, someone commented earlier they didn't notice it with
rdimport. I haven't tried it with rdimport, but might give that a shot
to see if it narrows down where this may lie. All mine rips have been
done with RDLibrary and the CD Ripper in there.
Tim
On 4/7/17 1:04 AM, Tim Elwell wrote:
Hey Fred and all....
I'm wondering if this is just me or if anyone else has come across
this. I updated a client/server applicance (CentOS 6.9) test setup I
have to 2.15.3 for testing before updating anything important. It's
been running for about 5 days since the update and I've really
starting loading music to it by ripping cd's with RDLibrary. All the
sudden tonight I hit a brick wall. It comes up with an error and says
there's no more space available (in RDLibrary CD Ripper on the
client). After a lot of playing and searching, what I found is it
doesn't look like RDLibrary (or whichever process is responsible for
this) isn't clearing the /tmp directory on the client machine being
used for ripping. I also ripped on the server machine and the same
situation exists. The client I use as the production machine only has
a 250gb hard drive since all it's doing is moving music to the server
(dual 1TB raid mirror). The server usage for /var only shows 11% used
and it rips fine when using the server, but still leaves the files in
/tmp on the server when ripping from the server.
_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
