Local UI not working, but Camect running

[Dolf Starreveld]

I tried to bring up my camect UI, first through the home.camect.com route. It displayed some of the page (mostly header), but kept spinning to produce camera views. This tells me there is connectivity (otherwise it would be an empty or timed-out page), but something is wrong.

I then tried via the local access route with the same result. Subsequently I access that counters page, which worked without any problem. Note that the prior login did apparently complete the authorization part and stored the necessary token.

So this appears to be a case where the device is running (blue light is on too, and light on my coral unit is on too), but the camera UI does not want to appear.

Clicking on the camect icon in the top-left brought me to home page which claims my one "hub", but with 0 cameras. Eventually that then displays "WebRTC failed".

Any thoughts?

[Will Stillwell]

I would start with rebooting the Camect box.  If the UI won't load for you to even get to settings to restart services you don't have a lot of other options.  Unless there is a magic URL that we haven't been told about that triggers a service restart when hit. (hint hint Camect this wouldn't be a bad idea)  

  Oh wait, I just re-read your thing.  Looks like you can get into settings for your hub.  Do that, do a report Bug  and then restart services in that UI  

  

Hopefully that will bring it back to life.  If not I'd look at connectivity between it and the cameras.   Maybe the cameras updated?  what kind of cameras?

~Will

--
You received this message because you are subscribed to the Google Groups "Camect User Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to forum+un...@camect.com.
To view this discussion on the web visit https://groups.google.com/a/camect.com/d/msgid/forum/fd6023dc-a20d-411b-9610-7130bdce707fn%40camect.com.

[Dolf Starreveld]

I cannot get to settings, but some UI loads, therefore the box itself is not stopped as the web server portion of it runs, but clearly parts of the UI app don't. Frankly I suspect it is mostly running but somehow doesn't know/see the cameras. Cameras themselves have not had an update in about two years and are functioning fine (can see with other app), so no networking issues with cameras either.

Also cannot report bug ("Not connected to home yet"). I suspect there is a clue in that message.

The main point of this report is to make Camect aware since I cannot report any other way and in case they want me to do something I will wait a few more hours to power/down/up the unit itself (I have another security system recording anyway).

[Arup Mukherjee]

Dolf ... Your device appears to be online, connected to our cloud, and functional to the extent that we can tell. Are you getting alerts from it? 

Also, have you tried clearing the cache and restarting your browser, or have you tried connecting from a different browser? 

If that fails too, try accessing via the IP address of the hub directly (i.e. via local.home.camect.com), and, assuming you get stuck at the spinner, let us know the time at which you tried and we'll see if we can learn anything from our end. 

Thanks, 

Arup

To view this discussion on the web visit https://groups.google.com/a/camect.com/d/msgid/forum/90f73ce5-097f-4c87-9ff3-8cc3f313ea9dn%40camect.com.

[Dolf Starreveld]

The plot thickens…

• I am getting alerts.
• Performance counters are updating regularly (so that part of the UI works fine).
• The encode_video.nano.secs counters for all 4 cameras are updating making me believe that at least part of the machinery knows about the four cameras and is processing their streams.
• Ditto motion_detector counters
• syncfs-/var/camect/home/mnt/dev_sdb1/var/camect/home/output seems to not be incrementing
• write_video_packets is incrementing
• none of the sys_sdax and sys.sdbx counters seem to be incrementing so it appears no disk IO is happening
• Logging in with another browser (Chrome instead of Safari) asked me to login with google first (expected) and then reproduced the same behavior of 0 cameras. I conclude it is not a browser or browser cache issue.
• After all this I tried local.camect.com (in Safari again) and…. it worked where it did not before. I made no changes. The time was 15:56 PDT
• Ditto with the cloud version (home.camect.com)
• Checking revealed that streams had been recorded while all the problems were happening.

To summarize, I did nothing to the unit, did not power cycle etc. It failed 10 minutes ago, in both browsers. The only thing I can think of is that the google authentication that happened when I tried chrome somehow changed something.

I am submitting a bug report with logs anyway, in case they may be helpful.

[Dolf Starreveld]

So I am back in this state. I noticed about 12 minutes ago Camect UI was unresponsive (spinning, no cameras). I power cycled and tried to “Report Bug” at the highest level as suggested previously in this thread. I could not:

When I submitted the above I got a transparent overlay message that said something like “Could not report bug, Camect is not connected yet”. I verified that Camect is actually running:

• I can ping the device
• The counter page displays and is updating
• It shows this for main page:
• 

Clicking on the camect icon in top left, brings me to:

Which is exactly as I described.

Used third party app to confirm all four cameras are online and operational.

Tried both cloud and local connects with no success.

THen…. Restarted Safari and all is well.

So I am coming to the conclusion that there is some interaction between Safari and Camect that gets resolved on a Safari restart. Yet, I don’t think this is just about Safari. Last time I tried with Chrome as well and it also had the problem (after a fresh start). It seems that only the restart resolves the problem. I suspect it finally closes some (WebRTC?) connection that is somehow stuck on the Camect end (as well?).

What is also odd is the telegram message about just one camera coming online (out of 4), but inspecting its recorded video reveals no gaps (so was it really off-line?). Perhaps it makes these messages after a restart, but then I would have expected it for all 4 cameras.

Looking back at recorded video there seems to have been no interruption which also seems to confirm that Camect was not “dead” but just some UI problem.

[CamectChao]

Hi Dolf,

I think what you described after rebooting is just that the system is starting up.

When you noticed that the UI was spinning before you rebooted the device, did you try to restart Safari? There is a bug in the browser's WebRTC implementation that can cause such behavior.

If restarting Safaric doesn't help the next time, please let's know before you reboot the device. We'll take a look ASAP.  There might be something stuck there. If you reboot it, we won't be able to find.

[Dolf Starreveld]

Hi,

I thought I had described this pretty precisely, but your response seems to indicate that is not the case:

1. Discovered the problem (randomly) when I went to the Camect page
• So there was not a long open page
• There were also no other open windows with Camect
2. Saw the spinner, wondered what was going on
• Recognized this as similar state previously described
• Tried a few things like reloading page etc. No good.
3. Power cycled Camect
• Camera online reported within a minute
• Interface still spinning after 1, 3, 5, 7, and 10 minutes
• Confirmed Camect was running (again) during this time by inspecting the counters page and verifying ping working
4. Finally decided to restart Safari which then appeared to solve the problem

I do not believe, in particular after 5, 7 or 10 minutes the device was still “starting up”. Don’t know how long it should typically take, but I would assume much less than 5 minutes.

Me still seeing the spinner after this much time after a reboot seems to suggest, along with your remark about a Safari WebRTC issue, that once the issue develops, it stays, even across a reboot of the remote end of the connection (Camect). In other words, Safari’s internal WebRTC state must be messed up permanently. I find this somewhat odd, even if all windows that potentially use WebRTC are closed, but OK, so be it.

Next time around I will:

1. Confirm counters page still working (i.e. Camect still working)
2. Restart Safari
3. If now working: Chalk it up as a Safari bug (do you know if this is being worked on by Apple?)
4. If not working: I will try to contact you asap so you can inspect without me rebooting.
1. If counters are working, I can wait for your response because things are being recorded,
2. Otherwise, depending on time of day and whether I am home or not, there is a limit to how long I can wait without rebooting (I can do this remotely)

[CamectChao]

(Sorry for slow response).

I think you confirmed that it's Safari's issue in another thread (by mistake?). 

We don't know what's exactly going on. The bug guess is based on our experiences. We cannot find anyway to repro it.

We initially noticed this bizaare and rare browser issue on Chrome, probably 2 years before.

However, I believe Google have fixed it at some time as I haven't seen it for a while.

Unfortunately, the same thing starts to show up in Safari. We have at least another user reporting it.

Safari reuses WebRTC code from Chrome. I think this is why they are having the same bug.

I'll see whether we can bring it up to the Sarafi / WebRTC team. However, don't give much hope to it: We cannot repro it. The latest Chrome doesn't have the issue.

[J.C. Wren]

I'm now running into this issue. It was working fine on the local UI the other day on my PC w/ Chrome (Windows 7 64-bit), tried to log in with my Android 12 phone, and got the spinner. Went back to the PC w/ local UI, got the spinner. Went to the cloud, got the spinner, but was able to bring up the control page. Told it to reboot, still have the same issue. Tried clearing Chrome's cache, still doing it.  

[J.C. Wren]

I meant to add to that previous message that I'm still getting Telegram and email notifications of motion detection while the spinner is occuring. Probably a Javascript issue :(

[J.C. Wren]

And one more addition... It's working under Microsoft Edge.

[J.C. Wren]

Perhaps this is helpful.  This is from the Chrome developers console.

2021/12/16 19:47:53.214 Browser time zones: Array(11)
camera_list.min.js.225fed2af7073d0d496104d72af0a33f:274 Use ngRoute
camera_list.min.js.225fed2af7073d0d496104d72af0a33f:274 2021/12/16 19:47:53.219 Detected browser as  chrome / 96
camera_list.min.js.225fed2af7073d0d496104d72af0a33f:274 2021/12/16 19:47:53.219 User agent is  Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36
camera_list.min.js.225fed2af7073d0d496104d72af0a33f:274 2021/12/16 19:47:53.220 Detected that chrome browser is really chromium.
camera_list.min.js.225fed2af7073d0d496104d72af0a33f:274 2021/12/16 19:47:53.511 Start connecting to
camera_list.min.js.225fed2af7073d0d496104d72af0a33f:274 2021/12/16 19:47:53.513 Using viewport (1856x916 sep=10)
camera_list.min.js.225fed2af7073d0d496104d72af0a33f:274 2021/12/16 19:47:53.535 Using plan-b.
VM14:275 Uncaught DOMException: Failed to construct 'RTCPeerConnection': Plan B SDP semantics is a legacy version of the Session Description Protocol that has severe compatibility issues on modern browsers and is no longer supported. See https://www.chromestatus.com/feature/5823036655665152 for more details, including the possibility of registering for a Deprecation Trial in order to extend the Plan B deprecation deadline for a limited amount of time.
    at new WrappedRTCPeerConnection (<anonymous>:275:28)
    at EB (https://camect.private.com/js/camera_list.min.js.225fed2af7073d0d496104d72af0a33f:902:393)
    at https://camect.private.com/js/camera_list.min.js.225fed2af7073d0d496104d72af0a33f:899:152
    at rr (https://camect.private.com/js/camera_list.min.js.225fed2af7073d0d496104d72af0a33f:372:56)
    at iq.<anonymous> (https://camect.private.com/js/camera_list.min.js.225fed2af7073d0d496104d72af0a33f:373:336)
    at Up (https://camect.private.com/js/camera_list.min.js.225fed2af7073d0d496104d72af0a33f:329:371)
    at Tp (https://camect.private.com/js/camera_list.min.js.225fed2af7073d0d496104d72af0a33f:328:320)
    at uq (https://camect.private.com/js/camera_list.min.js.225fed2af7073d0d496104d72af0a33f:340:28)
    at iq.g.Rt (https://camect.private.com/js/camera_list.min.js.225fed2af7073d0d496104d72af0a33f:338:86)
    at iq.g.Mo (https://camect.private.com/js/camera_list.min.js.225fed2af7073d0d496104d72af0a33f:338:63)
camera_list.min.js.225fed2af7073d0d496104d72af0a33f:274 2021/12/16 19:47:53.558 Received message from unexpected orgin "chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj"(!="https://camect.private.com")!
camera_list.min.js.225fed2af7073d0d496104d72af0a33f:274 ServiceWorker registration failed:  DOMException: Failed to register a ServiceWorker for scope ('https://camect.private.com/') with script ('https://camect.private.com/service_worker.js'): An SSL certificate error occurred when fetching the script.
manifest.json:1 Failed to load resource: the server responded with a status of 401 (Unauthorized)

[CamectChao]

It's caused by Google removed plan-b support from Chrome recently, seems only on Windows for now.

We have made changes accordingly to make it work on home.camect.com

The local web UI will work after the next software releas.