iEvgeny / cctv-viewer

CCTV Viewer - viewer and mounter video streams.
GNU General Public License v3.0
135 stars 19 forks source link

Loading fails November 1 #66

Closed Barry-IA closed 1 year ago

Barry-IA commented 1 year ago

Hi!

Basically this morning (Nov. 1st) CCTV_Viewer fails to load. Literally worked fine until this morning. Original installation on a Raspberry Pi 4 running 32-bit Buster (oops! EOL!); thought that was the problem so did a test installation with Bullseye 64-bit – receiving the same errors:

barry@raspberrypi:~ $ cctv-viewer ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored. /snap/cctv-viewer/1146/usr/bin/cctv-viewer: error while loading shared libraries: libpulsecommon-15.99.so: cannot open shared object file: No such file or directory

The problem appears “${PLATFORM}” isn’t being filled in to the variables. I tried a quick test script to load:

``` #!/bin/sh # PLATFORM Options: # aarch64 # v6l # v7l # v8l PLATFORM=aarch64 export DISPLAY=:0 && /snap/bin/cctv-viewer -geometry 1275x730+5+875 ``` Still empty. Suggestions? Noted there was a new update yesterday (October 31st) – did the Halloween Trick-or-Treat goblins do a trick? TIA! Barry
iEvgeny commented 1 year ago

Hi! As a temporary solution, I rolled back the changes in the stable channel for architectures other than amd64. Please reinstall the application.

A version with support for hardware acceleration of video decoding has been released, but unfortunately the "desktop helper" had to be dropped when building the Snap package, which is probably the reason.

I will make the necessary configuration changes shortly and get back with a response.

Barry-IA commented 1 year ago

(Looks like I didn’t use the correct reply option as I don’t see it here.) The rollback worked. Even more simple as it pretty much fixed itself. I wasn’t certain how to refresh a snap, found instructions but also saw ‘snaps are refreshed up to four times per day’. Put in the command used at boot to Terminal; magically worked!!

iEvgeny commented 1 year ago

Necessary changes have been made and are available. Update the package with sudo snap refresh cctv-viewer or just wait as you did before. Use snap info cctv-viewer to check the update results. If you don't mind, please give feedback.

Barry-IA commented 1 year ago

Argh! I'm doing something wrong as my replies are not posting here -- trying to do the easy way via e-mail. Copying in from mail save:


Nov. 5: pi@raspberrypi:~ $ sudo snap refresh cctv-viewer error: snap "cctv-viewer" has "auto-refresh" change in progress

I'll wait until tomorrow and get back to you with the new-and-improved results!


Nov. 6 (today)at 06:54 CST (Chicago's time zone): Runs properly; :) As mentioned, last night received a message of update in progress but no issues this morning: shut down cctv-viewer, reload to start - ta-da!

Let me know if any other experimentation I can help you with.


Later today at 09:36 CST: I am getting an odd video freeze but could be due to an oddball configuration here. I use Motion as the video source, Raspberry Pi 4's as the computer hardware, WiFi 5 GHz. Every so often random glitches which are usually taken care of by restarting Motion or in more extreme cases rebooting the Pi.

This morning noted about two of the three video streams were frozen at approximately 01:30 -- there are automated events occurring around that time; Motion recorded the activity following. I has exited cctv-viewer to install the new version around 06:45.

Noted later one video streams had frozen. Was one of the streams with the frozen video issue from earlier. Restarted Motion on that Pi; no change. Exited and restarted cctv-viewer; corrected the problem.

I have noticed sometimes an issue doesn't always get fully fixed the first time. ...That's not phrased correctly and I don't know how to rephrase it. Sometimes a computer needs to be rebooted/restarted a few times for the update to fully take effect -- more the computer's fault than the software's. So the video freezing issue(s) I had may not be your upgrade but rather a quirk in the way things are processed. Will let you know if any additional quirks noted. Any logging you'd like to see, or should we wait to see if the video freeze quirk occurs again?


Same freeze issue a few times later -- didn't post a comment. Same source. The first two times noted when checking the video feed via a third computer the frozen image almost immediately started to play properly. Around 17:10 restarted Motion (on the first computer, CCTV-Viewer is on the second) and things have been working -- so far about 2.5 hours.

iEvgeny commented 1 year ago

CCTV Viewer is based on FFmpeg. A good practice to detect regressions would be to try to play the target stream with same FFmpeg options using ffplay.

Barry-IA commented 1 year ago

(re: ffplay) OK thanks -- will look into that.

Barry-IA commented 1 year ago

Hi! Not ignoring you, just everything is working properly. (Hopefully didn't just jinx!)

Barry-IA commented 1 year ago

Hi!

I’m not sure how to question this one… Recap history: CCTV-Viewer is looking at three local sources, the sources being Raspberry Pi 4’s running Motion. 5G WiFi LAN – nothing goes outside the house, even local storage.

So this morning Camera 3 is stuck at 01:13:59 – the other two cameras are running normally. I ssh’d in, restarted Motion, and that fixed the stream. Motion wasn’t ‘stuck’: there are recordings.

I didn’t see anything in the logs of the RPi running Camera 3 nor the RPi running CCTV at/around 01:10. No swap being used per ‘free’. Before the Motion restart I ran your ffmpeg suggestion and the stream recorded fine. Any ideas for me of what to check?

Thanks! Barry

iEvgeny commented 1 year ago

What type of stream are you playing RTSP or some other? What FFmpeg options are used for the stream?

Barry-IA commented 1 year ago

Hi!

I’m going to admit I don’t know what stream is being used – it’s the ‘magic’ part of the hobby! The command I use is: ffmpeg -i http://192.168.4.221:8081/1 /mnt/ramdisk/output.mp4

...OK: I think I have a partial answer: https://motion-project.github.io/motion_guide.html The URL connection string to enter is specific to the camera and is usually provided by the manufacturer. The connection string is the same as what would be used by other video playing software such as VLC. If the camera does not stream via RTSP and instead uses a MJPEG, then Motion can also view that format. See the option netcam_url for additional options.

MJPEG sounds familiar. The recording format is .mkv. Again, apologies for not knowing the answer.

Barry

iEvgeny commented 1 year ago

I can't say anything on this information. Provide the output of the command ffprobe -i <your_url>

By URL I mean what you set in CCTV Viewer for the problem viewport.

Barry-IA commented 1 year ago

$ ffprobe -i http://192.168.4.221:8081/1 ffprobe version 4.4.2-0ubuntu0.22.04.1+esm2 Copyright (c) 2007-2021 the FFmpeg developers built with gcc 11 (Ubuntu 11.4.0-1ubuntu1~22.04) configuration: --prefix=/usr --extra-version=0ubuntu0.22.04.1+esm2 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --enable-pocketsphinx --enable-librsvg --enable-libmfx --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared WARNING: library configuration mismatch avcodec configuration: --prefix=/usr --extra-version=0ubuntu0.22.04.1+esm2 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --enable-pocketsphinx --enable-librsvg --enable-libmfx --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared --enable-version3 --disable-doc --disable-programs --enable-libaribb24 --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libtesseract --enable-libvo_amrwbenc --enable-libsmbclient libavutil 56. 70.100 / 56. 70.100 libavcodec 58.134.100 / 58.134.100 libavformat 58. 76.100 / 58. 76.100 libavdevice 58. 13.100 / 58. 13.100 libavfilter 7.110.100 / 7.110.100 libswscale 5. 9.100 / 5. 9.100 libswresample 3. 9.100 / 3. 9.100 libpostproc 55. 9.100 / 55. 9.100 Input #0, mpjpeg, from 'http://192.168.4.221:8081/1': Duration: N/A, bitrate: N/A Stream #0:0: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 1280x720 [SAR 1:1 DAR 16:9], 25 tbr, 25 tbn, 25 tbc

iEvgeny commented 1 year ago

Try add option -timeout 30000000 (in microseconds) in FFmpeg options field for problematic stream.

Barry-IA commented 1 year ago

OK, thanks! actually all three have been misbehaving (just not at the same time) so (accidentally) added to the general configuration.

Thanks again! Barry

Barry-IA commented 1 year ago

Well, so far so good: all three cameras are being displayed properly. Trouble is, they're inconsistent: will work fine for a day or two and then act up. Will keep you informed. Barry

Barry-IA commented 1 year ago

Looks like adding the timeout command did the trick! Has been several days since adding that and cctv-viewer has stayed running with all three channels. Thank you!