Open oliversturm opened 5 years ago
Please provide the script, or at least the complete command-line that you are passing in to raspivid.
Right... well, surely the main point is that the same command has worked correctly for years and now it doesn't. But here you go:
/usr/bin/raspivid -n -vf -hf -awb auto -md 2 -t 0 -sg 60000 -ex auto -drc high -br 60 -co 10 -o ./vid%06d.h264
The request was because there are so many other options that you could have combined with -sg 60000
. eg Had you tweaked the intra-I period or any of the other parameters affecting the actual H264 stream?
Do you know when your installation had been previously updated so we can have a rough idea of when it failed?
Is this straight after boot? There was an issue where the timestamping was being done based on the system clock, so if NTP updated it you got strange behaviour. Should have been fixed via https://github.com/raspberrypi/userland/pull/520. Based on your commit version of 7cbfbd38d982 (12th Dec 2018 based on https://github.com/raspberrypi/userland/commits/master) you don't have that fix. Please try downloading and building userland yourself. Raspbian is never on the absolute bleeding edge as stability is the main criteria. It generally gets a bump of the firmware and userland every 2-3 months when things have been stable for a while.
Previously, the installation was running jessie, but I doubt that it was on the latest state of that. I think it was probably about 18 months ago that the latest updates were installed. Before then, segment creation had always worked correctly.
The issue does not have to do with how long the pi has been running. The script runs the process based on a motion sensor and kills recording when motion has not been detected for a while. As far as I can see, the run-away behavior happens completely randomly - sometimes a complete motion timeframe (~20 minutes minimum) is recorded without any problems. Sometimes the 12th segment "runs away". Sometimes even the first segment "runs away". This random behavior continues at least after a few days of uptime (that's how long I've had it running after my updates so far).
That's interesting about the raspbian version - I received another update of libraspberrypi-bin just yesterday or the day before, so I was assuming I'd be quite current at this time. I'll try to build myself asap, but I don't have time to do it right away.
This may have something to do with an overflow bug just reported in the latest version, and fixed with #535. This has been merged, so should appear in an update in the nr future. In the meantime you can build it yourself from the userland tree very easily and see if it fixes the issue.
Yes, I can confirm the bug is reported by @oliversturm
Hi, any updates on this?
I am experiencing this on my Pi Zero W where randomly it will stop segmenting and create a huge file.
Can anyone confirm it's fixed in the latest version?
I recently updated my Pi Zero W and the raspivid version is being reported as (commit 7cbfbd38d982).
Anyone know if this is still happening? I'm still using older versions of RaspiVid to avoid this bug.
@comeradealexi This is believed to be fixed by #535 (as already noted). The simplest thing is for you to update and confirm for yourself.
I have used a script for several years now that runs raspivid with
-sg 60000
to create minute-long segments for the recording. Now I have updated the system (raspbian) on this pi and I have raspivid showing this version:(commit 7cbfbd38d982 Tainted)
.Segmentation doesn't work reliably anymore. Most of the time I see a number of segments created correctly, sometimes up to ~20, and then suddenly the next segment "runs away" and just keeps recording indefinitely into the same file. On two occasions I have seen this behavior with the very first segment created.
This is very inconvenient because it makes it much more difficult to analyze the recorded video files. Any ideas?