Closed jlpoolen closed 4 years ago
To make certain the problem is not a permissions issue, I did the following to the directory tree moonfire-nvr would be working in:
ares /usr/local/src/moonfire # chown -R moonfire-nvr: /usr/local/src/moonfire ares /usr/local/src/moonfire # chown -R moonfire-nvr: /var/lib/moonfire-nvr/ ares /usr/local/src/moonfire # chown -R moonfire-nvr: /var/tmp/video/
I then reran:
ares /usr/local/src/moonfire # date; ./moonfire-nvr/scripts/run_server.sh Wed May 27 21:35:24 PDT 2020
and checked the urls:
http://ares:8080/ (constant "loading")
http://ares:8081/ (unable to connect)
I also have Moonfire-nvr running on a Dell laptop running Gentoo, that instance is working:
Ouch! The instance on ares had the Recording Display - Max Video Duration set to "Infinite". When I change that value to 1 hour, then lots of rows appeared!
The UI doesn't have proper error handling yet. Did/can you look in the Javascript console? I'd expect it to say something interesting. Chrome Developer Tools has a "Network" tab that also probably will show an error response to some requests.
I process the logs and remove two common error messages; the log is at: https://pastebin.com/zucCVNCQ (1 month duration)
The garage_east
camera seems pretty broken, but on a quick skim I don't see anything in that log that I'd expect to cause this stuck UI.
Also, if I try a URL (http://ares:8082/) for an individual camera, , Firefox tells me: Firefox can’t establish a connection to the server at ares:8082
What URL for an individual camera? Moonfire NVR only runs on a single port; so I'm not sure what you're saying about the :8081 and :8082.
I recall mention of RUST debug modes, but I am assuming that is for the build process. Is there a way to trigger deeper debugging output?
If you do a debug build and set the environmental variable MOONFIRE_LOG=moonfire_nvr=debug,moonfire_db=debug,info
before running the process, you'll get a fair bit of debug output on the server. The release builds have this compiled out. (Or you can change that by removing the release_max_level_info
from Cargo.toml
.)
Ouch! The instance on ares had the Recording Display - Max Video Duration set to "Infinite". When I change that value to 1 hour, then lots of rows appeared!
Strange! That's definitely not working as intended.
My error re: url of ares:8082.
I'm also working with the motion-project and that server runs on 8080, as well, and has each video feed on an incremented number from 8080, e.g. camera 2 can be on 8081, camera 3 on 8082 &etc. Sorry. When i get gated on one project, I jump into the other and this back and forth caused me to think Moonfirst-nvr had separate pages for each camera as an option to all cameras on one page.
Further; problem occurs in Firefox (77.0.1), does not occur in Google Chrome.
Firefox Web developer console has: `09:29:59.254 Password fields present on an insecure (http://) page. This is a security risk that allows user login credentials to be stolen. 192.168.1.192:8080 09:29:59.343 API: http://localhost:8080/api/ MoonfireAPI.js:61:12 09:29:59.344 The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol. 192.168.1.192:8080 09:29:59.428 Stream garage_west-main enabled StreamView.js:85:12 09:29:59.429 Stream garage_west-sub disabled StreamView.js:85:12 09:29:59.445 New range: 2020-06-08 - 2020-06-08 CalendarView.js:302:14 09:29:59.447 Fetching> 2020-06-08T00:00:00:00000-07:00 to 2020-06-09T00:00:00:00000-07:00 NVRApplication.js:166:10 09:29:59.451 Loaded: 2 stream views NVRApplication.js:318:10 09:29:59.466 /api/cameras/f3305758-9805-49fd-8649-6217e8fb85b5/main/recordings?startTime90k=143243964000000&endTime90k=143251740000000&split90k=infinite load failed: error : Bad Request NVRApplication.js:209:18 09:29:59.546 /api/cameras/f3305758-9805-49fd-8649-6217e8fb85b5/sub/recordings?startTime90k=143243964000000&endTime90k=143251740000000&split90k=infinite load failed: error : Bad Request NVRApplication.js:209:18
? `
Ahh. That split90k=infinite
is incorrect. Looks like a bug in ui-src/lib/views/NVRSettingsView.js
, introduced in 58152e8. In particular, it doesn't handle infinite
being selected when the page is loaded. This never happened on Chrome, but Firefox apparently remembers the previous selection across reloads.
I'll fix it shortly.
I am running moonfire-nvr from its target directory in the build tree, /usr/local/src/moonfire/moonfire-nvr
I launched Moonfire-nvr from /usr/local/src/moonfire using a run script (run_server.sh) and the web page appears to be stuck in "loading" mode. There is no error and this condition persists for the length of the Moonfire-nvr run, i.e. 2-5 minutes, I even let it run for several hours.
Below is the screenshot of the Web UI showing "loading" mode and which doesn't change:
Also, if I try a URL (http://ares:8082/) for an individual camera, , Firefox tells me: Firefox can’t establish a connection to the server at ares:8082
I confirmed through the ncurses configurator that all four cameras are marked with "record" and files are being populated in the target holding directories.
I process the logs and remove two common error messages; the log is at: https://pastebin.com/zucCVNCQ (1 month duration)
To reduce the size of the log, I removed from the log the following line types using the script clean_log.pl
rtsp @ 0x7f47681faa80] RTP: PT=60: bad cseq 44c0 expected=7e7c
[h264 @ 0x7f476821db90] concealing 12874 DC, 12874 AC, 12874 MV errors in Pframe
The Web UI had been working. The capture of video streams is populating the specified directories, there are approximately 1800 files among the four subdirectories:
I recall mention of RUST debug modes, but I am assuming that is for the build process. Is there a way to trigger deeper debugging output? And for purposes of this issue, is the removal of the line types above okay, or would they be a factor in the Web UI not finalizing? The log file was about 50 Mbs for a 3 hours run and my log reducing script brought the size down to 250k.