Write /tmp files to tmpfs

[Phaeton]

It would be good to minimize the writes to disk, by writing the /tmp files to ram instead. I have tested the below for a few hours now without any issues. The key here is the tmpfs: block. I also added /var/log. If this works well for others, I can submit a PR to update the default docker-compose.yml config.

  birdcage_backend:
    image: "mmcc73/birdcage_backend:latest"
    ports:
      - "7007:7007"
    environment:
      DATABASE_FILE: /db/birdcage.db
      API_SERVER_PORT: 7007
      TEMP_DIR_NAME: tmp
      ANALYZE_SERVER: 192.168.1.75
      ANALYZE_PORT: 7667
      DETECTION_DIR_NAME: detections
      CORS_ORIGINS: http://192.168.1.75:7008
      REDIS_SERVER: redis
      REDIS_PORT: 6379
    tmpfs:
      - /tmp:exec,size=16M
      - /var/log
    volumes:
#      - "./birdcage/tmp:/tmp"
      - "./birdcage/detections:/detections"
      - "./birdcage/db:/db"
      - "/etc/localtime:/etc/localtime:ro"
      - "/etc/timezone:/etc/timezone:ro"
    depends_on:
      - redis

[mmcc-xx]

Sounds like a good idea. I personally don’t have a lot of ram to spare so I’ll have to look into how a tmpfs works. But I’d be happy to put it in the docker-compose with some comments about when to use it.

But now that you mention it I’m at least going to map tmp to spinning media.

[matthew73210]

Maybe an option would be to choose if you want the recordings on not? and how many per bird (i.e the latest one). I myself only need the ones on rare birds to verify if the bird in question was actually that bird.

[Phaeton]

Agree that would be a great option to have. My note above though is specific to the /tmp folder where the stream is currently recorded every x seconds in chunks. It’s a repetitive and constant write to disk, even if nothing is detected. There’s no need to write to disk unless something is detected, and then, only to the detections folder. For detections, limiting the recordings to recent/best only would be great!

[mmcc-xx]

The hard part of saving detections selectively is coming up with a system to decide which to keep and which to pitch. My first inclination is to get the list of bird species most to least likely for a given lat/long and week of year and letting the user decide which to leave out. That gets a little complicated because the list changes over the year - maybe I don’t care about red winged blackbirds in the summer but I like to know when they first start singing in the spring. Or maybe just keep the best X per day where X is a preference setting?

[Phaeton]

Yes, that does sound complicated. What about keeping the last "x" days/weeks/months of each bird, up to a user defined max #. Then within or in addition to the user defined max, keep the best confidence recording. Then, if someone really has a strong dislike of red winged blackbirds, have a block-list. My rationale for this approach is that it would always be nice to have at least one recording for each bird. And, you can always query the DB or have a view of first seen/last seen for identified birds.

[matthew73210]

I think the best option is as you said : recording wise just keep the last x days of said birds and keep a memory purge option. And let the user do the rest in the db as you said.