New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
timelapse ends before print ends (rasperry pi) #425
Comments
Found the problem: If someone downloads the timelapse video file before it is completely "done"/ moved / rendered the video ends right there when someone tried to download it. Could the download option be made inactive until the file is completely finished? |
I'm a bit surprised by that tbh, wouldn't have expected reading access to a file being rendered to be a problem... |
You are right, it is not the problem i was so happy i got i full timelapse i jumped the gun. :( i just hade another failed timelapse for a 3hour print. So i have no idea what is causing it. any tips on what i could monitor or test? |
It might be interesting to know if there are any error messages in the log |
Hi, I just did a 1:30 hour print and got 709 sequential files (noting missing in the series) ending with "tmp_00708.jpg" same as before it stops after the first layers. The log "~/.octoprint/logs/octoprint.log" from today. No errors today I also change power supply today to a 2A apple original iPad charger. Previously 1A Apple iPhone charger. But same results as above. Is there some way to monitor if the connection to the webcam is lost. It seems that webcam (usb) is lost during the print. Because my preview/stream under "control" also stopped working after the print. Probably has been this way also for my previous prints. Or monitor if the mjpeg script crashes for some reason since OctoPrint-"the printing part" is running smoothly only the images stop coming in. If i look at top -c now after the print everything looks normal noting is currently eating resources. ideas? |
Did a new print run with some changes;
and this time i got an error in the log: I do not think this was related to my short timelaspe issue since the server crashed when i tried to upload a new gcode file after a successful print with failed timelapse. |
That last one rather looks like for whatever reason the server ran out of memory while you tried to upload the file -- how big was it? Regarding your timelapse issue, please try the following.
This should render the movie locally directly in the shell. Might take a while, but should give you output regarding what it does. The whole output of the command might be interesting, so please capture that (=> pastebin or gist). For comparison, I get something like that for a quick test timelapse on my devel machine:
|
Regarding the upload sitenote: I did first an ls and then your command the video looks like this |
Should help debugging issue #425 and any future problems in that area.
Hm... Looking at that I think I agree with you that it has something to do with OctoPrint not being able to capture any images from the webcam anymore after the first ~1000. I just pushed a change to the |
I am now at Branch: devel, Commit: 1a7a468 i did 4 prints today: the last print (4) was successful and had these images and the total log so far from today lookes like this: So much better results but i still can not see in the log why the camera stops working. |
Hm... I honestly don't get why there are no error log entries, there should be if capturing fails, which it obviously does because otherwise you'd have some pictures. Just to make sure that the update actually got "applied", could you make sure that What camera are you using there btw, and is |
Hi, I had an incorrect timezone so i switched to Sweden and did a new pull and got a new update: I also have some errors but they can be related to other hardware issues because i did not use a powered usb hub when i got them and did a couple of reboots during the time. I will run a few prints now with the powered usb hub to see what happens in the logs and report back what happens. |
Hi again, so now i have done one failed print and one successful print this afternoon but no time lapse on either one. I did a reboot at "2014-04-05 16:00:15,161" before my second print but still no timelpse From 11:01:13 i have had a powered usb hub but nothing in the logs about any problems but i got no new time lapse |
Does mjpg-streamer run when you don't get a timelapse? It appears from the |
Hi, Today i tried with a raspicam but everything went bad. I lost connection with the printer 4 times and have had no succesfull prints today. But I got 1 timelaspe of a print that stops on the first line 9sec in to the print. :( The log is here: I have to take a step back now and try to figure out why everything started crashing and remove the raspicam. |
Back on track. I have a theory that my prints i causing electrical distrubances. With the raspicam i get a black line across the video. if i move the usb cables the line/distrubance changes. example where the timelapse worked but with disturbance that disappear when moving cables: Since the logs never gave any answer this might the problem all along that the electrical disturbances caused the usb webcam to loos connection, maybe? I will google for some tips on removing electrical disturbance over usb and see if this gives any better results. I think we can close this issue for now. what do you think? |
I've been having this issue for a while. To the point where I pretty much stop using the timelapse function. I am not running on a RPi. I am using a UDOO Quad (udoo.org) with a Logitech 9000 Pro (http://www.logitech.com/en-gb/support/quickcam-vision-pro-9000-mac) running Debian but it is using the RPi ver. of mjpg-streamer and on the current build of the devel branch. in my logs I get... Ignoring empty buffer ... then mjpg-stream crashes. It's annoying to have anywhere from 30% to 85% of the print. Or sometimes one frame. In the beginning I would restart the daemon if I caught it. Like I said, It's gotten to the point where I don't even use it anymore. |
@ymilord does that webcam work fine under linux in general? Because that above reads like something is seriously off there. @LangBalthazar it might be electrical interference (at least I highly suspect the raspicam acting out being caused by this, the cable isn't really shielded at all), I'd suggest keeping the cables short, not crossing them with anything carrying large currents (e.g. motor wiring!) and trying to exchange them if that doesn't help. However, it also still might be some incompatibility between your webcam and mjpg-streamer/linux. I had similar issues with a Microsoft Lifecam Studio in the past, it just stopped working after a time and crashed the mjpg-streamer process. Switching to a different webcam (in my case a Logitech C270) solved the problem completely. And last but not least, there's always the question of power consumption. I run the webcam + wifi dongle off of a powered USB hub that also powers the Pi itself, this way the two most power hungry appliances connected to the Pi don't get fed via the USB port of the Pi but by the power supply of the hub. That has proven to make things more stable for me. |
Well it seems to crash only when a job is running. |
I have been running with the raspicam now for 10-ish prints and the timelapse works without any problems. My power setup looks like this: Examples of fully functional. So i belive that my issue was related to electrical interferance that caused the usb camera to loose connection and not octoprint. Thank you for all your support and this great software. |
From my side we can close thus issue |
I truly love OctoPrint!
I am using the latest linked image image and have done an update for master and then moved to devel with same results.
The timelapse video stops after the first couple of layers.
I have tried switching resolution from 1280 to 640 and frame rate from 25 to 10.
I have tried Zchange and timed on 30s, 2s, 1s
I have tried with camera directly to rpi and via a 2.5A usb hub. same result
But still the timelapse video cuts out after a few layers (not sure if it is the same amount of layers every time but i could be)
example of timed, the print was a 10hour succesfull print
the file was 49.0MB
http://youtu.be/jKv7U1dg9hw
30min bolt print that had a short timelapse
the file was 2.8MB
http://youtu.be/X8PsTNHz48c
I have so far done 11 prints with timelapse and all have been cut before the print was done
Could it be the Trust webcam that sucks or is there something that might help in the settings?
Any ideas on how to test what is causing this_
Best regards
Balthazar Lang
The text was updated successfully, but these errors were encountered: