|
Post by dmommen on Oct 13, 2021 13:57:54 GMT -8
Hi Taim,
I too am running a Model 3 A+ based WS and wondered how your time lapses had been going? I implemented your changes on my units without any change in outcome for the 4KB MP4.
Thanks,
Dustin
|
|
taim
New Member
Posts: 32
|
Post by taim on Oct 14, 2021 0:08:25 GMT -8
Hi Dustin, yes, in my case (Pi zero w) it is working as it should for about two weeks now.
The only thing I have done is to change the -preset option from veryfast to ultrafast and restarting the SkyWeather2.py
To be honest, I have no idea why it is suddenly working. It has been always working using the testPictureManagement.py though, have you tested this as well? What is the output there?
Sorry that I have no further explanation.
Greetings, Timo
Attachments:
|
|
|
Post by dmommen on Oct 14, 2021 4:35:19 GMT -8
That's great to hear! What is the frequency of the photos? (I believe the default setting in SkyWeather2.JSON is 60 second) Did you modify their resolution from the default 1080P setting applied?
|
|
|
Post by SDL on Oct 15, 2021 9:49:17 GMT -8
I've added "-preset veryfast -crf 23" to my Raspberry Pi A+ test unit and we will see if that does it! I'll report later.
Line 208 of PictureManagement.py now looks like this:
command ="/usr/bin/ffmpeg -r 20 -i %s -c:v libx264 -preset veryfast -crf 23 %s " % (inputFiles, outputFile)
BP
|
|
taim
New Member
Posts: 32
|
Post by taim on Oct 23, 2021 3:03:12 GMT -8
That's great to hear! What is the frequency of the photos? (I believe the default setting in SkyWeather2.JSON is 60 second) Did you modify their resolution from the default 1080P setting applied? Yes, I've changed the frequency to 600s = 10min in the "WeatherSTEM / WeatherUnderGround Configuration Tab" using the SkyWeatherConfigure.py procedure. I don't know whether this changes the global frequency or only the upload frequency to WS/WU?! However, in my case, the "BuildTimeLapse" folder contains 143 .jpeg files in total.
I did nothing to the resolution of the pictures.
|
|
|
Post by dmommen on Oct 23, 2021 10:11:44 GMT -8
Thanks for this!
I wonder if you could share the free memory statistics of your Pi just before and after testPictureManagement.py of a successful run:
free -m
Much appreciated!
|
|
taim
New Member
Posts: 32
|
Post by taim on Oct 25, 2021 6:44:23 GMT -8
Thanks for this! I wonder if you could share the free memory statistics of your Pi just before and after testPictureManagement.py of a successful run: free -m Much appreciated!
Before testPictureManagement.py total used free shared buff/cache available Mem: 366 159 46 1 160 156 Swap: 99 2 97
After successful testPictureManagement.py run (runtime approx. 3-5 minutes) total used free shared buff/cache available Mem: 366 146 93 1 127 170 Swap: 99 18 81
So, actually, no significant before/after difference there.
|
|
|
Post by SDL on Oct 25, 2021 10:32:36 GMT -8
I'm not surprised about their being no real difference. The process should give it all back.
If you would, open up another window and run "top" while you run the testPictureManagement.py in the other window
That will show you what the process is eating up.
You can run free in a different window too during the testPictureManagement.py run.
BP
|
|
taim
New Member
Posts: 32
|
Post by taim on Oct 25, 2021 23:32:23 GMT -8
I'm not surprised about their being no real difference. The process should give it all back. If you would, open up another window and run "top" while you run the testPictureManagement.py in the other window That will show you what the process is eating up. You can run free in a different window too during the testPictureManagement.py run. BP Yeah, that makes sense. I just did what Justin requested without thinking too much
|
|
|
Post by dmommen on Oct 26, 2021 1:36:46 GMT -8
Thanks for the update here. My Pi's have considerably less free/available memory (< 20mb) when attempting to generate the time lapses which is a function of also needing to run the Sixfab LTE user agent.
Do you think you could try as BP suggests to active/actual memory consumption by running 'top' from a second SSH instance while the time lapse is being generated? This will tell us an indication of the rough amount of memory the process consumes to complete the action successfully.
Thanks!
|
|
taim
New Member
Posts: 32
|
Post by taim on Oct 26, 2021 11:39:07 GMT -8
Before testPicturemangement.py
total used free shared buff/cache available Mem: 366 137 47 3 181 175 Swap: 99 49 50 During testPicturemangement.py
total used free shared buff/cache available Mem: 366 177 60 3 128 136 Swap: 99 59 40
|
|
|
Post by SDL on Oct 26, 2021 14:21:38 GMT -8
Remind me again what Raspberry Pi are you using?
BP
|
|
taim
New Member
Posts: 32
|
Post by taim on Oct 26, 2021 22:28:02 GMT -8
Remind me again what Raspberry Pi are you using? BP Pi Zero W
|
|
|
Post by SDL on Oct 28, 2021 7:01:01 GMT -8
Do you have a PI4B you could try? I'm still thinking it's a memory problem. running "free" didn't show much because it is a snapshot. And my guess it gets worse and worse as we head towards the end.
BP
|
|
taim
New Member
Posts: 32
|
Post by taim on Oct 29, 2021 0:29:49 GMT -8
Do you have a PI4B you could try? I'm still thinking it's a memory problem. running "free" didn't show much because it is a snapshot. And my guess it gets worse and worse as we head towards the end. BP No, sorry, I do not have a Pi4B.
Also, I think there may be some misunderstanding. Timelapses are running fine now on my pi zero with the changed commands (see above). However, they don't on Dustin's (dmommen) A+. He asked me for my "free -m" output.
|
|