When you log in to the Pi via ssh (this can be done with BitVise or by plugging in a keyboard and monitor into the Pi), you should enter sudo suwhich will switch you to the super user (rather than root). If you then type `ls`, you should be able to see the contents of the super user's home folder, which is where the video files are saved.
Post by joshnelson_MNSGC on Jul 20, 2017 14:01:25 GMT -7
Thanks for the quick reply!
I just tried looking in the home directory as a super user, and the only thing in there was the pi directory. After a little more digging, I noticed that the pi only has 1.7 GB of memory full out of 55GB, so I suspect that the video files aren't being saved in the first place.
So now the question is, does anyone know why the pi wouldn't be saving the video files?
I don't know if this is the source of the problem, but the line I have in crontab is the following, which is slightly different than yours.
@reboot python /home/pi/bin/python/auto_record/repeat_10m.py I also would check that the process is running, by rebooting, entering 'ps aux' and looking for the python process in the right-hand column
Interestingly enough, I just discovered that the videos are not in the home directory, but in the /root/ directory of Pi (still under super user). Switch to super user and enter `cd ..` to go up a level. Entering `pwd` will tell you which folder you are currently in.
Post by Austin MnSGC on Jul 21, 2017 6:20:21 GMT -7
Irowe is right, your line shouldn't have the "cd" in it, it should say "python" to execute the program, not change directory.
If that doesn't work, just looking at repeat_10m.py, I see this:
def ten_minute_record_os(): timestr = time.strftime("%d%m%Y-%H%M%S") print timestr system("/opt/stream/bin/ffmpeg -i rtsp://127.0.0.1:8554/ -vcodec copy -acodec none -f mp4 " + timestr + ".mp4 &") #ffmpeg takes about 2 seconds to start recording #so for a 10 min chuck 2 more seconds are added. time.sleep(602) system("killall ffmpeg" This gets called repeatedly, and it appears to record a 602 second video. From this, I would guess it would be located in /opt/stream/bin/, with a file name "start time".mp4, or it's not being saved.
Post by Skylar MSGC on Jul 21, 2017 10:27:55 GMT -7
So since you are using the root crontab to start the repeat_10m.py on reboot the video file will be saved to the root directory for the root user.
This is because the root crontab default directory is the /root/ directory and when the root crontab is running it will usually save the videos in that location. To get to the files you should be able to do
sudo su <- will make you root user cd <- will go to the default directory for the root user which is /root/
once there you can use ftp, scp, or some gui to pull the video files.
The python script is currently making 10 minute videos and chunking each one up. If you don't have a RTC (real time clock) installed on your RPi it will be labeled with a date from 1969 (most likely)
When you reboot your RPi you can check to make sure that the python script is running by typing in
ps aux | grep repeat_10m.py
Which will show 2 lines of response if the python script is running. If it is not you will only see 1 line of response which will be the command that you typed in.
We tried going into the /root/ directory, but there were no video files. Here is a list of files in the root directory (viewed as a superuser):
.bash_aliases .bash_history .bashrc bin .npm .pip .profile .selected_editor .tmux.conf .vim .vimrc (bin, .npm, .pip, and .vim and directories, but I couldn't find videos in any of these directories either.)
Running ps aux as Skylar suggested shows 2 lines, one of them being repeat_10m.py.
I am convinced that the repeat_10m program is running (which as I understand it, is the program that is actually supposed to save the video files), but not that the video files are actually being saved. We haven't cleared the memory on this Raspberry pi in at least a month, over which time we've captured hours of video from several flights and nearly daily testing, but we have only used 1.7GB of memory, which seems very low to me. To show disk usage, I did:
and it showed 1.7GB used and 54GB available in /dev/root, along with much smaller memory usages in other filesystems.
Does it make sense that video files aren't being saved?
We are having the same problem as described by joshnelson. Our auto-record shows up on ps aux, but the video files are not being saved out. We had success with this in the past, this problem is new as of today.
Post by icebergphil on Aug 15, 2017 22:52:43 GMT -7
Colleague of WY Katie here... We probably spent 5 hours today trying to troubleshoot this odd issue. We were working directly within the Pi, not through Bitvise. Bottom line: everything seemed to be working/running correctly, but the video files were not showing up in /root. I can't say for certain that they were not being saved, but if they were it was somewhere else without our knowledge.
1. We checked crontab, no typos. It reads "@reboot python /home/pi/bin/python/auto_record/repeat_10m.py" 2. "repeat_10m.py" is indeed running upon reboot according to ps aux. This was the case on all reboots we did. 3. We checked "ps aux | grep raspivid" as well, there are two lines... one for the camera (with the string of commands for video width, height, bitrate, etc) and one for the grep. 4. We even switched out the Pi camera to see if a different one would work, but no still no .mp4 files in /root.
For what it's worth, one thing we tried just for kicks was manually running the start_recording.sh script in /home/pi/bin/, and that DID work briefly... and started saving a .mp4 in the /root directory. But once we CTRL -C it and then restarted the script, it would not save to a new file, even if we deleted the first one.
Lastly, we tried all this (unsuccessfully) with BOTH the 6/7/17 update and the 8/1/17 update (2 different SD cards), and even re-imaged the cards to make sure they weren't corrupt. We had the 6/7/17 version working just fine as recently as last Friday, saving 10-min video to /root.
We did replace this Pi since the last launch, so maybe there is an issue with the new Pi we're using??? Yet, it still confounds us that it worked late last week. As far as I know, no changes were made since then.
I know we're getting close to the last minute, but any thoughts would be appreciated.