MotionEye / Motion / Cameras just stop working #1582
Comments
|
Same for me. |
|
Do you save media files remotely? Please attach all of your logs, since they all might contain useful information as to why your system hangs. |
|
Yes, I am storing the captures on SMB. |
@ccrisan Yes I do, I have a 3rd Raspberry Pi (Pi 3) running as a central hub with 4TB attached hard drive. I have NOT yet updated the hub. That's currently on motionEyeOS 20180602 Logs attached. I've prepended them cam1_ and cam2_ (and appended .log to messages file) cam_1dmesg.log cam2_boot.log |
|
Here are my logs: |
|
me with release 27062018 I had many problems, with release 28062018 and last pre release 12072018 everything is fine |
|
Guys, the problem here is that the SMB protocol version has recently changed. Some users are fine with the old version, while others are fine with the new one. I personally don't know what to do about it. |
|
@ccrisan hmmm interesting. Did the logs indicate what actually happens? Does the SMB protocol go to sleep or "crash"? My 2 cameras lasted about 55 hours this time, before they both rebooted. At least this time they did reboot without getting stuck in limbo so that's something I guess. Perhaps I should go back to the older version. |
|
I'm having the same issue since updating to motionEyeOS 20180627 |
|
install release 20180712 |
|
same problem here except only saving locally no smb used. Pi zero w, working fine before update to 20180627. Using a generic usb cam. |
|
Guys, the latest nightly-dev includes an option to manually choose SMB protocol version. Please test it and see if it fixes your problems. To upgrade to latest nightly-build, use |
|
Thanks, will give this a try and report back... EDIT, @ccrisan - could you clarify please what was the "Old" version from previous stable release, and what is the "new version" in the latest stable release. I'm assuming the previous stable release was version 1.0 but only guessing
|
|
I tried the nightly build and had the same issue, I'm going to try to fall back to 0602 on my pi zero W. I've literally replaced all the hardware. It just seems to die after a few days |
|
I have the Samba server turned off and I'm storing the files locally. I did install the latest nightly and I'm still having the same issues on my Pi Zero W's. I didn't change the samba version because I'm storing locally and don't have the option to change samba versions unless I change it to a network share. Looking at my logs I still see smb mounts stopping and starting, but why would they if I have the samba service turned off? |
|
@matucker your issue is then not related to SMB itself so you can safely ignore the SMB-related comments. Judging form your logs, lines like |
|
I know it's been a while now, but just to report back and say no matter what SMB protocol I choose, I still have the same problem, it just seems to be random with it's timing. Worth noting though - and this is what actually makes this a real problem for me, is that once it does freeze up so to speak - I can't reboot it remotely. It "hangs". Reboot and Reboot -f do absolutely nothing. There's no way to reboot it, I've tried stopping the motioneye services etc etc before rebooting but nope - still won't work. I have to go and pull the plug - which is a huge pita when it's supposed to be a remote cctv unit :( I could live with rebooting it every so often and not be too concerned about the issue - if only the reboot command worked |
|
Idem for me, command reboot ssh not reboot pi zero also gui web is blocked |
|
Same thing for me this morning. Suddenly, the GUI of motioneye show nothing, and can't login anymore. :-( |
|
I have the Pi Zero W problem where it no longer shows up a camera. |
|
Not sure if I'm having a similar issue or not. I have two zero w set up as fast cameras and a 3b set as the server. Every few hours the second zero loses the camera connection. I can still log in to reboot it to get the image back. The first zero hasn't skipped a beat. |
|
with the release 20181008 it seems that the problem has been solved at least for me on my pizero w no longer freezes. |
|
Just tried that @tigernero79, it still failed a few hours later. |
|
For me I switched the wifi channel on my router, the one I was using was
very congested and all these problems went away.
…On Fri, Nov 2, 2018 at 7:03 AM quantum8 ***@***.***> wrote:
Just tried that @tigernero79 <https://github.com/tigernero79>, it still
failed a few hours later.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1582 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AbQuzrHN88_sExcFc3cdyAmqXY9mc6-Nks5urFDAgaJpZM4VMZvd>
.
|
|
I have the 'loss of camera as of' error on 20180627 on RPi3B. Happens to a USB attached camera. Doesn't matter where the files are being saved (local or network) I tried to update to dev20181126 but during install, it downloads, unpacks, then tries to apply, but runs out of space on the partition. (8GB SD Card). File system is trashed afterwards. Goes into a reboot loop. Unable to recover data. |
|
@starbasessd I'm sorry for your inconvenience, but the partition layout has been recently changed. You'll need to write the new OS image from scratch. See https://github.com/ccrisan/motioneyeos/releases/tag/20181129. |
|
@ccrisan I think there's a way to support fwupdate from old partition layout to the new one. The data partition is created by S00datapart if the partition does not exist.
Re-doing the data partition could be worth it. We could use it to support doing factory reset. Factory reset + "bring up wifi AP if not configured" will greatly improve the user experience. Aim is to minimize the need for users to reflash SD card. What do you think? |
|
motioneye.zip I am having the same exact problem described many times above. I start the raspberry Pi and MotionEye, and all is well. I can view the camera, and it records motion when detected. Randomly it loses the camera image. I can still access the web interface, and change and apply settings. The only way to get the camera working again is to reboot the Pi. It will work again for an undetermined time before it loses the camera again. I have used 2 different Raspberry Pi 3 B+'s, and two different Class 10 32 gig Micro SD cards. (I installed from scratch, and did not just use the same SD card in the 2nd Pi.) Specs: MotionEye Log is attached |
|
@ccrisan ok, after being up for some time, a good week or so I think actually, it's just "died" again. Rebooting remotely also refuses to work. I can however access it via SSH / SFTP - so, before I battle my way to yanking the plug out of the bloody thing - what log files would you like? I'll download then via SFTP whilst it's in it's purgatory state of being useless and refusing to reboot. I believe my versions are still the same as my original post: motionEye Version | 0.39.2 Is there a way to double check those via terminal or the log files? Just the usual? Eg: boot.log Any others? |
|
@IAmOrion I simply cannot tell what's going on in this case. Rebooting should especially never fail since the first thing it does is to kill the watchdog feeder. Is this something 100% reproducible? |
@ccrisan It happens frequently, but I couldn't tell you how to specifically reproduce it on cue so to speak. But every time the image from my camera "dies" (So I get the static no image picture) I can no longer reboot. I did discover literally the other day, that, bizarrely, if I restart the router (thus killing wifi temporarily) it sometimes restarts - I presume the watchdog does it... but I just can't figure out what's preventing it manually (eg by me typing it in terminal in remote ssh window) SSH/SFTP still works, and I can practically do everything else remotely still APART from reboot. It's very odd |
|
@IAmOrion when you find your unit in this bad state, could you please run the internal commands contained by This is what If anyone can spot a problem with this script, I'd be happy to address it. |
|
@ccrisan Sure thing! I'll hold off updating this particular unit (I've updated a couple last night) because it will happen eventually! I'll report back when it does, thanks |
|
I've got similar stability issues on a new install (one day old). Right now the web interface works, the camera image does not show (but opening the URL to the IP cam feed in another tab works), and ssh hangs when trying to connect to the Pi. |
|
And now half an hour after rebooting it doesn't capture videos anymore, although the video feed still works in the web gui. |
|
@ir-fuel what OS version? |
|
20180627
On 27 Jan 2019, at 18:40, Calin Crisan <notifications@github.com<mailto:notifications@github.com>> wrote:
@ir-fuel<https://github.com/ir-fuel> what OS version?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#1582 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABgDUxev_duVTS7kLIs6qEW0xThQbwfrks5vHeR0gaJpZM4VMZvd>.
|
|
@ir-fuel see if 20190119 fixes this problem for you. |
|
Installing the latest version in the prerelease list right now. It worked fine for 2 days and right now the system was blocked (no web server, no video uploads). I could SSH into the Raspberry Pi though. I'll let you know my findings. |
|
@ir-fuel please make sure you installed 20190119 and not some dev nightly build. |
|
How do I do this? If I only allow official releases it tells me I am on the latest version, and if I toggle to prerelease it shows me 20190130 as build to install. |
|
Ok got it: note: do not attempt to update to this version automatically! Due to the different partition layout, you'll need to rewrite the OS image from scratch. Using the automatic update mechanism will, at best, fail with an error message. I'll wipe my sd card and install it. |
|
FYI It's still running since I upgraded the version. Will see if it stays like this. |
|
@ccrisan (@jasaw) unbelievably even on 20190119 pre-release, this STILL causes me problems! I wonder if the reboot is failing because of writing buffers to disc part - which perhaps is stuck because Samba has died or something??
I tried to change Samba version, but when I clicked "Apply" it just got stuck and I get the standard browser error that the url is not responding
I can still connect via SSH, but can't reboot. Following your response re: the shut down script, this is what happened:
It froze after the bin/sync (I say froze, I can press enter and any other keys for that matter, but nothing ever happens.) If I quit and reopen terminal, I can connect again and follow up the next set, but again, after the busybox reboot command, it freezes and never does anything more.
It'll sit like that forever if I let it! can't ctrl+c out of it or anything. I just end up quitting Terminal (And I could reconnect fine if I wanted). In this particular instance, the busybox reboot DID seem to complete (as you can see I'm on a new line in terminal) - but it never reboots. Log files (in case they're of use) or individually: boot.log Samba Logs: |
|
@IAmOrion I can't tell if this particular problem can be caused by SMB, but you could temporarily disable SMB usage on your system and see if that's the cause. I would go with SD card change first, though. |
|
FWIW I am noob to the Pi and this is only my second project. I am having the same problem. I set it up earlier today and was successfully sending images to my NAS (using SMB 2.0) for a few hours but decided to rebuild and relocate it, and since then (and further rebuilds) the camera just drifts off after a while - and I've not even got to the point of using my NAS, so it's all local. I'm using it headless, just accessing through the browser and I can report that the power off button works OK. I have tried three different SD cards (brand and size) and it continues to be a problem, I have another new Zero here so will try that tomorrow. I'm using motioneyeos-raspberrypi-20190119 and would be happy to assist with any logs as required. btw having said that it looks like a perfect product with the ability to do just what I need. |
|
Further to my post above, I had only successfully built a working ca,era 1 time out of maybe 15 times. So I took everything really slowly and documented each step with the idea that I might isolate which particular piece of config was breaking it, And of course it worked. It worked for a full day then I powered off overnight, and at next power on I have no camera. I did backup the config so I will re-create the card with the software, and if that is working just reload my config. And I do now have the ability to put it on a monitor to see what's happening, if that might assist you. |
|
dear friends of motioneyeos, greetings |
|
@Joseph-Muc It is expected not to be able to kill it but it's definitely not normal that it runs for long periods of time. Please try replacing the SD card with a new/faster one and see if the problem persists. |
|
I am having an issue similar to this. MotionEye version is 20190427 It was working then had it powered down for a bit. I plugged it back in and connected to the web interface but the raspberry pi camera just spins and never loads. Running on a raspberry pi zero w
|
|
Please confirm your OS, browser, etc. If Chrome browser version ...100,
confirm it works in another browser. Also, do a change user in the Chrome
browser even if you change back to admin, and confirm you get black windows
for the camera(s)
…On Fri, Aug 16, 2019 at 9:16 AM Jacob T Lusco ***@***.***> wrote:
I am having an issue similar to this.
MotionEye version is 20190427
It was working then had it powered down for a bit. I plugged it back in
and connected to the web interface but the raspberry pi camera just spins
and never loads.
[image: image]
<https://user-images.githubusercontent.com/41247230/63170027-8de50500-bff5-11e9-802a-fbf88282adaf.png>
motion.log
<https://github.com/ccrisan/motioneyeos/files/3509733/motion.log>
motioneye.log
<https://github.com/ccrisan/motioneyeos/files/3509734/motioneye.log>
messages.log
<https://github.com/ccrisan/motioneyeos/files/3509735/messages.log>
boot.log <https://github.com/ccrisan/motioneyeos/files/3509736/boot.log>
dmesg.log <https://github.com/ccrisan/motioneyeos/files/3509737/dmesg.log>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1582>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEZTUHK7NQBF3WIOGWSLLOTQE2SEFANCNFSM4FJRTPOQ>
.
--
Thanks
Kevin Shumaker
N38° 19' 56.52"
W85° 45' 8.56"
Semper Gumby
“Don't tell people how to do things. Tell them what to do and let them
surprise you with their results.” - G.S. Patton, Gen. USA
Ethics are what we do when no one else is looking.
Quis custodiet ipsos custodes?
You know we're sitting on four million pounds of fuel, one nuclear weapon
and a thing that has 270,000 moving parts built by the lowest bidder. Makes
you feel good, doesn't it?
|
|
@starbasessd Thank you for the information. It works in Firefox. Was not aware of an issue with Chrome. |
|
Yes, it seems to have been a Chrome issue, popping up in mobile, too. on
my Android Chrome ...111 works, but Win10 & Android Chrome 100 and the
previous version are broken still. More than likely, a Chrome update broke
it.
…On Fri, Aug 16, 2019 at 10:01 AM Jacob T Lusco ***@***.***> wrote:
@starbasessd <https://github.com/starbasessd> Thank you for the
information. It works in Firefox. Was not aware of an issue with Chrome.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1582>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEZTUHLYTTKT5YLTW23AEPTQE2XL5ANCNFSM4FJRTPOQ>
.
--
Thanks
Kevin Shumaker
N38° 19' 56.52"
W85° 45' 8.56"
Semper Gumby
“Don't tell people how to do things. Tell them what to do and let them
surprise you with their results.” - G.S. Patton, Gen. USA
Ethics are what we do when no one else is looking.
Quis custodiet ipsos custodes?
You know we're sitting on four million pounds of fuel, one nuclear weapon
and a thing that has 270,000 moving parts built by the lowest bidder. Makes
you feel good, doesn't it?
|
|
Fixed in recent nightly builds. |
Preliminary Docs
I confirm that I have read the CONTRIBUTING guide before opening this issue. (YES)
I confirm that I have read the FAQ before opening this issue. (YES)
motionEyeOS Version
I am running motionEyeOS version: (insert your version here, e.g. 20180314).
motionEye Version | 0.39.2
Motion Version | 4.1.1
OS Version | motionEyeOS 20180627
Board Model
RPi Zero W
Camera
MMAL
Network Connection
WiFi
Peripherals
Log Files
Very odd, but my cameras had been working fine for a while now, running and recording 24/7.
I updated the newest stable release (20180627) and now for some reason, everything "freezes". I can access the Web UI, and via SSH, but the camera image won't show, it's no longer recording and even running reboot in ssh does nothing (well, it just hangs so to speak) meaning I have to physically unplug and re plug in the device.
I currently have 2 devices - identical RPi Zero W with the same RPi Cameras. (As mentioned, they have been working fine for ages without trouble) ... this morning, as coincidental as it is, they BOTH stopped at 7:15am. BOTH!! What are the chances of them both stopping within 30 seconds of each other?
What logs would help in this instance?
The text was updated successfully, but these errors were encountered: