It freezes on "Busy" in various random times

[PicoPi]

May be there is issues in writing to SD card? I get the "Busy" on random occasions which makes the camera not record anymore.

[roberttidey]

I don't think there are generic issues in writing to SD card. Some of my cameras have been running for over 2 years without any attention other than an occasional software update. Of course, it is possible that you have some specific SD card issue. Some of the low cost cards can be problematic. Sandisk cards in general perform very well.

What do you mean by 'busy'? If that is a busy on thumbnails in the download page then that would indicate there is something going wrong with the MP4Box process that converts raw captures into mp4 files.

You need to give some more details. Look in scheduler log to see what activity there was around any freezes.

[PicoPi]

I think I'll reinstall Raspian and RPI_Cam_Web and see if the problem persists. God knows what I've installed on this Pi2B+. I am a noob to linux so its hard to get things done. A little knowledge is a dangerous thing :) will report back findings.

[mfraser]

I'm getting this on a Raspberry Pi ZeroW. Here is part of the log: {2018/02/19 07:40:38} Add /var/www/media/vi_0151_20180219_074031.mp4 to Box Queue at pos 23 {2018/02/19 07:40:38} Start boxing /var/www/media/vi_0151_20180219_074031.h264 to /var/www/media/vi_0151_20180219_074031.mp4 Queue pos 23 {2018/02/19 07:40:39} Finished boxing /var/www/media/vi_0151_20180219_074031.mp4 from Box Queue at pos 23 {2018/02/19 07:40:39} Removed item from Box Queue {2018/02/19 07:41:51} send smd 1 [2018/02/19 07:41:51] Start capture requested from Pipe [2018/02/19 07:41:51] Send ca 1 {2018/02/19 07:41:51} Error: Could not send buffers to port, h264 callback {2018/02/19 07:41:51} Executing macro /var/www/macros/error_hard.sh "Could not send buffers to port, h264 callback" {2018/02/19 07:41:56} RaspiMJPEG Version 5.8.06

[roberttidey]

The error Could not send buffers to port, h264 callback indicates a breakdown in the MMAL interface to the camera.

This can be caused by several things.

1) Marginal power supply. The camera does impose more load and glitches can affect the interface. It is important to have a decent power supply and a short good quality USB cable. Some USB cables do not have a low resistance.

2) Camera interface cable not well connected. Check both ends and press down the little ribbon on the camera module itself.

3) Slow speed writing the video data out not keeping up with video stream. This can be caused if you are writing to a network location rather than the SD card, particularly over wifi. There is a mode that allows writing the stream to the SD card but then boxing to the remote location which avoids this problem. Look in wiki for boxing_path

4) Raspberry Pi overloaded with other stuff. Not normally a problem but can happen if there other highly intensive apps running.

[PicoPi]

Hi Robert. update report: I reinstalled Raspbian on the Rpi2+ to see if your suggestion works. It did. It must've been mosquitto server, or tightvncserver. I've been keeping an eye on it. In the past 2 months, I noticed that, on 2 instances, the busy thingy came back, but this time, it opened the new recording and continued with a new file! and not stop recording by itself. I had to go back and delete that "Busy" thumbnail in the download section. I am running nothing else from a fresh raspbian. uname -a returns this: Linux RPI2 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l GNU/Linux any ideas?

[mfraser]

I've now added a USB stick to the PiZero and am recording to that instead of the SD card. RPi Cam is the only service running on the device. It has just happened again, this time it looks like a stop capture request was sent, but not received. {2018/03/08 09:27:21} send smd 1 [2018/03/08 09:27:21] Start capture requested from Pipe [2018/03/08 09:27:21] Send ca 1 {2018/03/08 09:27:21} Capturing started {2018/03/08 09:27:48} send smd 0 [2018/03/08 09:27:48] Stop capture requested [2018/03/08 09:27:48] Send ca 0

[PicoPi]

I've had the same problem as before. Even when I am just recording video without motion detection, I get a file that says busy! It also stops recording and the "Record video start" button becomes active. If I start again, I now get 2 files that says "Busy". If I continue, I'll get another file with the state of busy. I though maybe I should wait a few minutes to allow the SD card be written to. No such luck. There is something wrong and I don't know what it is. Can you fix it if I send you the log files (tell me which ones and where they are), and screen shots?

[roberttidey]

Have you checked all the hardware points mentioned in the post from 3 weeks ago?

You said that the problem had gone away with a clean install but recently happened again. Had you installed other software in the meantime and if so what. There may be some interaction.

[PicoPi]

Yeah I have a 2.5A genuine Raspberry foundation power supply. SD card is measured to have a write speed of 10.2 MB/s. I gave up on this. its just too unpredictable and unreliable to be of any use to me.

[tman32768]

I've got 3 raspi's running from B+ to 3B. They all eventually start crashing during motion recording events and I have to reboot to get the RasPis to get them to start working again. When it happens I get the "busy" label on the recording.

I am using "internal" motion and noir2 cameras, 2.5A power supplies, wired ethernet.

Attached below is my latest crash log

{2018/03/31 16:40:28} Capturing stopped {2018/03/31 16:40:28} Add /var/www/html/media/vi_0198_20180331_163944.mp4 to Box Queue at pos 16 {2018/03/31 16:40:29} Start boxing /var/www/html/media/vi_0198_20180331_163944.h264 to /var/www/html/media/vi_0198_20180331_163944.mp4 Queue pos 16 {2018/03/31 16:40:31} send smd 1 [2018/03/31 16:40:44] Start capture requested from Pipe [2018/03/31 16:40:44] Send ca 1 {2018/03/31 16:40:45} Copying vector data to /var/www/html/media/vi_0199_20180331_164045.mp4.dat {2018/03/31 16:40:45} Capturing started {2018/03/31 16:40:45} Finished boxing /var/www/html/media/vi_0198_20180331_163944.mp4 from Box Queue at pos 16 {2018/03/31 16:40:45} Removed item from Box Queue {2018/03/31 16:41:07} send smd 0 [2018/03/31 16:41:07] Stop capture requested [2018/03/31 16:41:07] Send ca 0 {2018/03/31 16:41:07} Capturing stopped {2018/03/31 16:41:07} Add /var/www/html/media/vi_0199_20180331_164045.mp4 to Box Queue at pos 17 {2018/03/31 16:41:08} Start boxing /var/www/html/media/vi_0199_20180331_164045.h264 to /var/www/html/media/vi_0199_20180331_164045.mp4 Queue pos 17 {2018/03/31 16:41:09} Finished boxing /var/www/html/media/vi_0199_20180331_164045.mp4 from Box Queue at pos 17 {2018/03/31 16:41:09} Removed item from Box Queue {2018/03/31 16:42:33} send smd 1 [2018/03/31 16:42:33] Start capture requested from Pipe [2018/03/31 16:42:33] Send ca 1 {2018/03/31 16:42:33} Copying vector data to /var/www/html/media/vi_0200_20180331_164233.mp4.dat {2018/03/31 16:42:33} Capturing started {2018/03/31 16:42:49} send smd 0 [2018/03/31 16:42:51] Stop capture requested [2018/03/31 16:42:51] Send ca 0

My observation is that it crashes more often when a lot of video motion events are occurring one after another. ie. windy sunny day with lots of moving shadows and tree branches. Masking and lowering sensitivity reduces the crashes. I'm guessing there's problems with caching as using faster/better SD cards reduces problems.

[roberttidey]

Your observation of rapid motion events is interesting. I will look into that area. My cameras are set up to give few false recordings so the number of recordings starting up very close together is limited, but they do happen sometimes (person approaches door, stops, and then moves away may sometimes cause 2 recordings). I see you are also capturing vector data. I don't think that is necessarily related but is that for debug purposes?

The other factor that might be interesting is the size of the video buffer in use as this does affect how captures start up. Are you using the buffer and what is its setting? If possible run for a few days with that off to see if that is a trigger.

[tman32768]

I just checked the saving vectors DAT file was accidental and only on one camera. I just turned it off.

The settings for the log file on the Pi3 are as follows: Internal Motion Detect Motion Vector Preview: OFF Noise level (1-255): 1010 Threshold (1-32000): 1100 Clipping factor (2-50) default 3: 0 Mask Image: yes Change Frames to start: 3 Still Frames to stop: 300 Save vectors to .dat : OFF Buffer: 0 The rest of the settings are pretty much the defaults.

PS I do get a lot of false motion events from moving tree shadows to bugs flying in front of the camera.

[roberttidey]

Thanks for the info. So it doesn't sound like the buffer is a reason.

The clip is not getting set to its default value. That is because it is wrong in the raspimjpeg default config file.

The clip factor is used to ignore small changes in an individual tile and can help reduce false triggers. Increasing this might help with your false motion events. It is good to put %c and %f in the annotation string when adjusting motion detection set up. %c gives the running change value. Values greater than the threshold increment the frame count (%f) and when this exceeds the start frame number then a motion detection has occurred.

Of course while this may help reduce triggers it does not explain why you get lock ups. I'll do some experiments to try to simulate rapid triggers to see what may be going on.

[davidtraver]

Use the button to "Motion Detection Stop" Click "Download Videos and Images" Click "Update"

Busy ends and you can download, etc.