Open steveschow opened 9 years ago
I too run on OSX these days and the latest code works fine across the network (I'm mounting an NFS share).
Can you tell me a little more about the environment in which this is running? eg. what version of OSX? What version of perl? What sort of network share you're using?
R.
I submitted a pull request to github with the one line fix
Mavericks using afp protocol to a Linux based has file server.
I believe the problem is that when system calls lame it is unable to unit the file because perl already has the file open.
Sent from my iPhone
On Dec 22, 2014, at 4:19 PM, Robin Bowes notifications@github.com wrote:
I too run on OSX these days and the latest code works fine across the network (I'm mounting an NFS share).
Can you tell me a little more about the environment in which this is running? eg. what version of OSX? What version of perl? What sort of network share you're using?
R.
— Reply to this email directly or view it on GitHub.
trying this on OSX and going across to a network file src and dest, there is an error code 65280, unable to init the temp file. After some debugging sessions myself and googling around the net, I was able to figure out the solution, its a one line fix. At line 701, where you call the system($convert_command), insert a line before that to remove the tempfile before calling flac and lame:
It seems the temp file creation system in perl hangs on to some open status of that temp file when created such that when you call the system() call, any forked process with lame being called is unable to init that file. its possible that on some OS, the version of lame or whatever, it might work. But I can confirm your script does not work on OSX, particularly when the tempfile is on a network file share. In any case, at this point in the script there is nothing in the file, there is no harm to remove it and let lame recreate it again. The perl temp file mechanism still works to clean it up later.