Didn't catch this on your first post, but MOUNT_DISK needs be a device name such as sda1, sdb1, or wherever
...did the same and it is working fine now, videos and pics on my usb key and I can see the thumbnails on the webpage. Thanks again.I have tried to find a post about this but couldnt find, so heres a question:
How do i make the pikrellcam so it saves the recorded media files to USB stick or NAS ?
The media_dir is configured in ~/.pikrellcam/pikrellcam.conf and you can have an automatic mount
enabled in ~/pikrellcam/scripts/startup.
For my setups, I leave the .pikrellcam.conf media_dir at its default of "media" and I edit the startup
script so that MOUNT_DISK=sda1
I have a USB stick plugged in which appears as /dev/sda so the startup script mounts /dev/sda1
on ~/pikrellcam/media and so all my video files are stored on the USB stick. This should work
the same for a NAS. If you want to mount the NAS or USB stick somewhere else, edit media_dir
as needed.
What do you get for space in /run? Run
Code: Select all
df -h /run
Code: Select all
ls -l /run/pikrellcam
It's been on my todo to add an audio trigger to start a motion video and it should be one of the next things I do. In your caseNestboxtech wrote: ↑Fri Dec 08, 2017 11:10 pmI was wondering if it would be possible to..
1) Capture audio event to an audio file format even if there is no movement detected?
2) Run an external script 'on audio event' (I couldnt see something like that in pikrellcam.conf)
The scenario I was considering is when I get a bird / squirrel having a go at the outside of the box, I dont have any way of recording that since there's no external camera. Being able to trigger recording of an audio file, e.g. audio over a certain threshold / or 'x' times per 'y' period would be interesting. I could also see an application for logging my Tawny owls night calling to each other where they regularly shout at each other near the nesting boxes without necessarily entering the box and triggering motion via the camera.
Maybe a video could play if the bitrate is changed, but I'm not sure. At least there would be a lot of places in the code that would needjbeale wrote: ↑Mon Dec 11, 2017 5:08 pmWould it be possible, in the event only an audio trigger starts the video, to temporarily select a lower frame rate and/or bitrate for the video recording? This would allow saving storage space in the case where audio events are less likely to result in interesting video. I'm not sure if changing frame rate on the fly like that might complicate things, if you have already recorded a video pre-buffer with different settings.
billw wrote: ↑Mon Dec 11, 2017 3:58 pmIt's been on my todo to add an audio trigger to start a motion video and it should be one of the next things I do. In your caseNestboxtech wrote: ↑Fri Dec 08, 2017 11:10 pmI was wondering if it would be possible to..
1) Capture audio event to an audio file format even if there is no movement detected?
2) Run an external script 'on audio event' (I couldnt see something like that in pikrellcam.conf)
The scenario I was considering is when I get a bird / squirrel having a go at the outside of the box, I dont have any way of recording that since there's no external camera. Being able to trigger recording of an audio file, e.g. audio over a certain threshold / or 'x' times per 'y' period would be interesting. I could also see an application for logging my Tawny owls night calling to each other where they regularly shout at each other near the nesting boxes without necessarily entering the box and triggering motion via the camera.
for night or audio out of video view you would get uninteresting video but have the audio you want. I'm inclined to do this rather than
have separate audio file only handling. Aside from the more complicated user interface to handle separate audio files, an audio
trigger needs to start a video in case there will be subsequent motion.
The existing on_motion_begin/on_motion_end would run, but I'll have a way for the begin script to know if it was an audio
trigger and the end script to know if there were only audio trigger events.
Would that be good enough for you?
The text is limited to the top by the mmal library layer because it is reusing an original camera debug feature that wasn't intended to be general purpose.Nestboxtech wrote: ↑Wed Dec 13, 2017 11:13 pmIs there a way to move the text overlay form the top to the bottom of the video?
I had thought only selected loop videos with motion would be worth archiving and not a full day of loop videos. But I can add it. I'll probably modify the existing archive_video script so it can archive videos from the media_dir or loop_dir and not have a separate archive_loop script.
The same thing is happening to me, no sound on the video when there isn't any movement.I have found the problem now, it isn't a bug in V4.1.1 but if you can advise how adjust to record the full mic recording up to the end in settings that would be great
Image
the mic records until the last motion event while the camera keeps recording to the end of the 'Hold' period in the screenshot the mic records until 1.02 then the video keeps going for another 44 seconds with no sound
It's not supposed to record to the end of the hold period (event_gap) but only through the post_capture time. So the audio length was actually OK and the bug was the video data was too long - should be fixed now.arnauld wrote: ↑Sun Dec 17, 2017 9:28 pmHello @Billw & @DaveDJThe same thing is happening to me, no sound on the video when there isn't any movement.the mic records until the last motion event while the camera keeps recording to the end of the 'Hold' period in the screenshot the mic records until 1.02 then the video keeps going for another 44 seconds with no sound
see my video, at 23secs the sound is off...https://youtu.be/O2yCjtKNX44
No rush on that one, I'm probably the only guy who ever tried a stereo mic with it. Hope you have a great holiday season and thanks again for all the amazing work you've done on PiKrellCam!
thank you.It's not supposed to record to the end of the hold period (event_gap) but only through the post_capture time. So the audio length was actually OK and the bug was the video data was too long - should be fixed now.
billw wrote: ↑Mon Dec 18, 2017 7:08 pm
It's not supposed to record to the end of the hold period (event_gap) but only through the post_capture time. So the audio length was actually OK and the bug was the video data was too long - should be fixed now.
Thanks for that Bill
Runs like clockwork, much appreciated
John, i have just ordered one to experiment with
