On Tue, 2011-02-08 at 13:50 +0100, Tolas Anon wrote:
> On Tue, Feb 8, 2011 at 1:35 PM, Ashley Sheridan
> <a...@ashleysheridan.co.uk> wrote:
> On Tue, 2011-02-08 at 13:24 +0100, Tolas Anon wrote:
> > Hi..
> > For a set of media import routines, i'm using a
> > method.
> > It seems longwinded, but it's designed to have different
> parts of the import
> > process run on different servers.
> > I'm stuck at getting curl_exec() to return the data of the
> final php_script
> > that does the importing.
> > The script itself runs fine, and i've recorded good details
> that curl_exec()
> > is supposed to catch with
> > json_encode($returnArray)), and from those debug-printouts
> it's just a few
> > tiny steps towards a cascade of "return" statements,
> followed by a
> > echo(json_encode($returnArray)) and a normal end to the
> php_script at the
> > end of the call chain.
> > However, curl_exec() seems to hang completely. I've added
> over a dozen
> > "debuginfo -> file on server" statements, and the one that
> should fire
> > straight after curl_exec() does not fire.
> > It does this only with large (1.8gb) video files, a smaller
> (60mb) video
> > file doesn't produce this problem and the entire import
> routines work fine
> > then.
> > I'd very much appreciate any tips you might have for me.
> Let me see if I've got this right.
> The windows.bat is processing the media file somehow, then
> calling a
> php_cli script which makes a cURL call to another web-based
> PHP script?
> Is this right? The final script I assume is getting sent some
> info from
> the cURL call and is using it somehow (in a DB maybe?) before
> some sort
> of message back to your curl call. What is the code then doing
> with it
> after that?
> oops, i missed a step (php_daemon_script) in the chain of calls;
> php_daemon_script -> curl_exec -> php_script
> of php_script via json files written to the server and thus display
> the status to the end-user..
> the windows.bat just starts up cli-php with admin privileges, which
> executes the php_daemon_script, which uses repetitive curl calls to
> the import-script ("php_script" at the end of my chain) that does all
> the work for a single item in the total upload/import queue; it does
> video conversion with exec(/path/to/ffmpeg), photo conversion with
> imagemagick, and updates the db with the php adodb library.
> php_script at the end of it's work returns a simple and short status
> array (json_encode()d) to the php_daemon_script via curl_exec, that
> dictates if the php_daemon_script should continue calling the (import)
> php_script more times.
> it's curl_exec that hangs/freezes, both with using
> CURLOPT_RETURNTRANSFER=1, or capturing output with ob_start() and
> ob_get_clean(). i've gathered that much from my custom debug logs.
I've done similar things with transcoders, and found that often the best
way is to send off the job to the transcoder and leave it. Don't poll
from your main app to see how it's getting along (it'll get annoyed
When the script responsible for transcoding is done though, it can
report back to the main app to let it know how it got on, and pass along
any details it needs that way.
This isn't great for getting things like transcode progress, but it will
reduce polling traffic, and transcodes can take a long time, especially
if more than once are running at the same time.