Motion - Feature Request 2005x 04x 01x 193531

Feature Request: Nicer handling of writing out snapshot files


I've got many cameras, each set up to write a "thumb.jpg" each second which provides the current picture. I've done this by using the following config options.

snapshot_interval 1
snapshot_filename thumb

My only problem is if I access this thumb.jpg at a rate slower than motion rewrites it (in the case of access the thumb.jpg via Apache over a DSL line) the chances are very high that I'll get a corrupt download/picture.. This happens, of course, if the browser can not complete the image before motion wipes it out and rewrites it. My request is to instead write the new image to a temporary filename, swap the files, and then purge the old. I believe this will allow the OS (Linux) to keep the old inode (old file) open and allow any downloads to complete from it while allowing new opens to happen on the new file.

This is a pretty basic Unix/Comp-Sci problem and I know it has been covered and solved many times. I hope this might improve the process by which motion runs smile

-- PeterS - 01 Apr 2005

Follow up

This request is rejected. But don't worry. It is because.

  • The feature is easily made with the functions already in Motion.
  • What you are trying to do can be done in a much easier way.

Let me explain further

  • The snapshot feature was never made to create a new file every second. It was more thought of to be once per minute or once per 15 minutes. It is for people that want to show a recent picture on their home page.
    • You are actually overwriting the same file of approx. the same size all the time. It probably means that you physically write on the harddisk the same place once per second, In practical Linux may not commit the write all the time but keep it in RAM. You can see on your harddisk if it flashes once per second. If we implement your proposal you will actually do several disk access actions for each jpeg. The disk activity will multiply. It is not be very effective.
    • You load your entire server pretty much by forcing generating a jpg picture every second for each camera.

  • If you really insist to do it anyway or you use a RAM drive you can implement what you want by using the onsave feature.

  • You should consider implementing what you are trying to do in an alternative way which will be much more efficient. I had a similar need. I wanted an always up2date webcam image. When a user looked at a still picture from any of my webcams it should be max 0.5 second old. Here is how I did it and how I propose you do it. Enable the webcam feature on Motion if you haven't done so already. Then go to the related project that I did called MjpegProxyGrab. It is the mj-grab program that you need. The MjpegProxyGrab gives you all the info you need to install it. It works like this.
    • The webpage you have has an image tag which instead of pointing to your thumb.jpg points to the cgi program.
    • Apache runs the cgi program which connects to the Motion webcam port, fetches the first mjpeg picture (which is a jpeg image in itself) and sends it directly to the browser.
    • The result is that your user sees the latest and greatest picture.
    • You can make a client pull system this way. You let the browser fetch a fresh picture frame once per second. And the npi-mjgrab is run once per second. Make sure your Motion webcam rate is set much higher. Make at 5 fps.
    • There is a load on the system doing this but the load is not larger than saving a thumb on the disk. And the load is only there when a person is looking at the picture.

Hope this gets you doing what you want.


Topic revision: r2 - 02 Apr 2005, KennethLavrsen
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Please do not email Kenneth for support questions (read why). Use the Support Requests page or join the Mailing List.
This website only use harmless session cookies. See Cookie Policy for details. By using this website you accept the use of these cookies.