Timelapse rendering goes over 100% #4153
Comments
|
This is most likely an issue with the output the ffmpeg binary produces. I'll need some information from you in order to (hopefully) proceed here. First of all, SSH into your OctoPi instance. Then run the following commands and share the output here:
For reference, this is what should be returned on OctoPi 0.18.0 (which according to your system info bundle you have): Also please set the logger |
foosel
added
the
needs information
|
Hi! |
|
Regarding the debug logging, I will provide it as soon as possible |
|
octoprint (1).log |
|
I have the exact same versions and cannot reproduce. |
foosel
added
bug
|
To give you more data, I too have seen the same thing. I'm running a very under powered Raspberry Pi v1 256mb, and I stupidly changed the camera settings to record at HD resolution to give me a better image for monitoring, forgetting this would also mean the timelaspe was also HD, so the video render took over 3 days (lesson learned) .
The results of the commands for me My octoprint,log is I have set the timelapse debug logger and will try to get you the logs when I next print something. |
|
Interestingly... I have just noticed that my above image taken whilst rendering (and shortly before it finally finished) showed the file size as 820.1Mb, and when the file completed it is seen here as 500.3Mb |
|
Hi all, same issue with OctoPrint .1.6.1 on OctoPi 0.17.0 (I haven't done a full upgrade from scratch). In my case it goes well over 160%, but I'm not sure of the final value. ffmpeg config as requested: I'll add a full log as soon as I have it. |
|
Tried it with @foosel I'm wondering if we can change to using frame counts, instead of the durations, in https://github.com/OctoPrint/OctoPrint/blob/master/src/octoprint/timelapse.py#L1096 . But take it with a grain of salt since I can't reproduce the problem. |
|
Recently had discussion on Discord about this. Seems @The-EG was also having it and was collecting data to see if he can easily reproduce. |
|
My guess is that this is happening because ffmpeg is estimating a duration that does not match the actual movie duration when the output FPS is not 25FPS. I saved a set of snapshots out and manually ran ffmpeg to produce the timelapse using the same arguments that OctoPrint would use: ffmpeg_stderr.txt Here it says it will be 4 seconds long: This timelapse had 100 snapshots, and at 25fps that would be correct. But, I didn't choose 25fps, I used 15fps instead, which it does recognize for the output and would be 6 seconds: The time reported during encoding is quite odd...it seems to work up to 4 seconds and then jump to over 6, meaning the final render percentage shown would have been about 161%: edit: I also double checked the output video and it is indeed just over 6 seconds long: I think this is likely more pronounced and noticeable on much longer timelapses. Just as a test, I reran the above but used an output fps of 25. This time, the expected duration was still 4seconds, but the actual duration was also 4 seconds so everything lines up. The last progress from encoding: |
|
I stumbled across something while looking through ffmpeg docs; I think this can be resolved by using TL/DR: set the default ffmpeg command to be According to the docs:
Note the last two sentences. When I specify the framerate with With With |
|
Has any of the people reporting this issue been able to test out @The-EG's suggestion of setting the ffmpeg command to the following? |
In timelapse settings, use -framerate instead of -r. This addresses OctoPrint#4153 for new installations.
In timelapse settings, use -framerate instead of -r. This addresses OctoPrint#4153 for new installations.
In timelapse settings, use -framerate instead of -r. This addresses OctoPrint#4153 for new installations.
In timelapse settings, use -framerate instead of -r. This addresses #4153 for new installations.
|
Well, we still don't know if @The-EG 's suggestion solves the issue for affected users (Hey @jollino, @eduszesz, @DAveShillito some feedback would be lovely! 😅), but it'll now be how 1.8.0 ships thanks to @The-EG sending in PR #4344. So maybe this is fixed, but we don't know without anyone who can actually reproduce this confirming. |
foosel
added
needs testing
|
Hi there, unfortunately I’ve put any and all printing on hold due to some personal issues. I’m afraid I won’t be able to help much for a while, but I’ll be sure to keep an eye on this as soon as I have a chance. Thank you all for working on this!
(edited to clean up the answer, as I had originally sent this as an email reply)
|
|
Hi guys! |
|
Sorry, I've been using my new Prusa without Octoprint for the last few months. I printed a calibration cube and the timelapse finished displaying at 164% Was that the correct method to test the change, or do I need to compile the file or setup a complete dev environement? in which case can someone point me at instructions as to what I need to do to test the change. |
|
I think the proper way to test would be to change the software update settings (gear icon in top right) to Github Commit and use
|
|
The timelapse command is directly editable in the timelapse settings, probably under 'advanced' or similar. |
OMG I had never noticed the advanced options for the timelapse. I shall revert my file changes and try again making the change in those advance settings.
And this is very useful for me to know in the future, thanks |
|
I changed the timelapse advanced options to have the FFMPEG command line of
Ran the same test print and this time the timelapse completed at 100%. So it does look like, for me, that change has fixed the issue. |
|
1.8.0 has been released 🎉 |
The problem
I'm using Octoprint through Octopi in a raspberry pi 3B. I'm using an old smartphone as a webcam to stream video and to capture time-lapses with the standard Octoprint feature.
After the print job is completed, the time-lapse rendering process goes over 100% (103%, 111%, 230%, for example), and most of the times it actually does not finish and the Rpi freezes.
Did the issue persist even in safe mode?
Yes, it did persist
If you could not test in safe mode, please state why
No response
Version of OctoPrint
1.6.1
Operating system running OctoPrint
OctoPi 0.18
Printer model & used firmware incl. version
reprap i3; marlin 1.1.9
Browser and version of browser, operating system running browser
Chrome 91.0.4472.77
Checklist of files to include below
Additional information & file uploads
octoprint-systeminfo-20210531205603.zip
The text was updated successfully, but these errors were encountered: