BUG: Higher 'gap' values in motion.conf break the framerate of the first event movie
I'm using a motion client (i.e. mpeg4 recorder) together with a motion webcam server (i.e. webcam picture provider) on two different PCs on the same network, both running x64 Kubuntu on a 3.14.2-031402-generic kernel. A Logitech C525 webcam is attached to the server.
After rebooting the server, motion on the client immediately reconnects to motion on the server, then the movie of the first recorded event gets recorded at 2 fps instead of the usual 30.
Lowering the 'gap' value to '1' in the motion.conf file on the client (recorder) side seems to resolve the issue, setting higher 'gap' values seems to increase the probability of setting off the bug, with a value of 15 almost guaranteeing it.
Any subsequent events after the first one always get recorded with the correct frame rate.
After several days of extensive testing, I concluded that the various codec, framebuffer and http related settings either on client or server side don't affect the bug, but it's always the 'gap' setting on the client that matters.
The bug DOES NOT occur if the webcam had enough time to initialize after server boot before the incoming connection from the client kicks in, but there's no option to tell the client first to probe the URL then wait for N milliseconds before restarting picture acquisition.
Killing and restarting motion on the server while keeping motion on the client alive reproduces this bug without rebooting the server.
It seems that the bug occurs if the client-side motion connects to the server-side motion immediately after the server-side motion started.
Paste in your error messages, config settings, terminal window output etc in this text field.
| Motion version:
| ffmpeg version:
|| libavcodec 6:9.11-2ubuntu2
| Shared libraries:
|| ffmpeg, mysql, postgresql
| Server OS:
|| Kubuntu x64 14.04 / 3.14.2-031402-generic
- 06 May 2014