should function as intended. Unless someone can persuade me that I have misunderstood I will update the code to do that, it seems to work ok for far.
This is ok, but only if the timeout is above 1000 ms, otherwise 0 is passed and the function will not block (It ignores the 5th parameter when the 4th is 0).
But what are the chances someone will use a timeout of less than a second...
So thats probably ok.
I know that's what it looks like from the docs but (a) that wouldn't make sense as you couldn't select for less than a second and (b) from testing it uses the usec value even if the sec value is zero. So 0, 500000 will wait for 0.5 seconds. I think the docs assume the whole timeout setting when they say no timeout on zero.
Hmm, the problem is still present when I execute "create video" from event view.
Apache process (mod_php) execute a ffmpeg and waiting when it finish to work (about few minutes). But php session is still locked for all the time of creating the video! So every ajax request is blocked for session file lock and wait until it will be freed. I have a maxclients=10 setting in httpd.conf so apache processes very quickly come up to 10 and all other request to web-server will become in connecting... state for a long time.
Possible solutions:
First - Please read about session_write_close(). It's a common problem of session_start() locking. You need to decide where a session write is realy needed and make session_write_close immediately after this section.
Second - Creating a videos from apache process is not a good idea. More better is to create a queue of requests to ffmpeg and run a separate cron task (or daemon) to complete these requests.
Yes, generating video for long events via the web GUI is not a good idea. The functionality is there for convenience. The alternative is to create video via a backgrounded filter if you have a defined set of events you want to batch create for. Any videos created this way will show up in the 'video' view when you go to look later.
It's obviously easy to add a session_write_close call ahead of potentially long tasks like this though it would have to be on a case by case basis as there is no global scenario for when it would be safe to close the session.
