sr99622 / libonvif

Onvif library with GUI implementation and built in YOLOX
GNU Lesser General Public License v2.1
173 stars 44 forks source link

Error when trying to start on onvif-gui on Fedora 39 #78

Open jin-eld opened 9 months ago

jin-eld commented 9 months ago

Hi,

I followed the "build from source" instructions on my Fedora 39 installation which worked without any issues - everything got built and installed.

However, when I try to run onvif-gui I get the following trace:

$ onvif-gui
Traceback (most recent call last):
  File "/home/xxx/onvifenv/bin/onvif-gui", line 5, in <module>
    from gui.main import run
  File "/home/xxx/onvifenv/lib64/python3.12/site-packages/gui/__init__.py", line 1, in <module>
    from .main import MainWindow
  File "/home/xxx/onvifenv/lib64/python3.12/site-packages/gui/main.py", line 37, in <module>
    from gui.panels import CameraPanel, FilePanel, SettingsPanel, VideoPanel, AudioPanel
  File "/home/xxx/onvifenv/lib64/python3.12/site-packages/gui/panels/__init__.py", line 1, in <module>
    from .camerapanel import CameraPanel
  File "/home/xxx/onvifenv/lib64/python3.12/site-packages/gui/panels/camerapanel.py", line 27, in <module>
    import libonvif as onvif
  File "/home/xxx/onvifenv/lib64/python3.12/site-packages/libonvif/__init__.py", line 19, in <module>
    sys.modules[name] = importlib.util.module_from_spec(spec)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ImportError: Python version mismatch: module was compiled for Python 3.6, but the interpreter version is incompatible: 3.12.1 (main, Dec 18 2023, 00:00:00) [GCC 13.2.1 20231205 (Red Hat 13.2.1-6)].

I am not quite sure how Python 3.6 comes into play, because I built libonfiv from source inside a virtual env and I am also starting it from there, just as described in the readme...

Any idea what is going on?

sr99622 commented 9 months ago

Thank you so much for reaching out. I had not tried installing on Fedora before, so the steps required are different than those in the "build from source" instructions, which are really for debian/ubuntu.

The following instructions install the supporting libraries needed to compile onvif-gui. Note that you need the non-free fffmpeg libraries which is the reason for the rmpfusion commands. See link for more information. It may not be necessary to use both the ffmpeg-libs and ffmpeg-devel installs, I think ffmpeg-libs was enough.

sudo dnf install cmake g++ libxml2-devel python3-devel python3-pip SDL2-devel virtualenv
sudo dnf -y install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
sudo dnf -y install https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
sudo dnf -y install ffmpeg-libs
sudo dnf -y install ffmpeg-devel

Once the supporting libraries are installed, you can start compiling using the pip command. I would recommend using the -v option to see compiler output in the case of error.

virtualenv myenv
source myenv/bin/activate
git clone --recursive https://github.com/sr99622/libonvif
cd libonvif/libonvif
pip install -v .
cd ../libavio
pip install -v .
cd ../onvif-gui
pip install .
onvif-gui

I'm not sure how you got involved with python 3.6, that's a little weird, but the instructions above worked for me on a fresh fedora 39 install.

Best Regards,

Stephen

jin-eld commented 9 months ago

Hi,

thanks for getting back to me! I think the the build system was trying to link against the wrong version of Python, I saw some lines checking for the minimum Python version, which was 3.6, I am not a cmake expert, but perhaps during this check it falsely picks up some link flags for 3.6? Turned out I had several versions of Python installed, which is not necessarily a problem as such, 3.6 was among them. I uninstalled Python 3.6 and did a new checkout and a new build - and then I was able to start onvif-gui as expected.

Please let me know If you would like to look into the build scripts and need me to reproduce the build problem where Python 3.6 is available on the system, if not then I think we can close the issue, thank you!

Now I'm curious if my cheap AliExpress cam is supported, but that'd be another topic ;)

Kind regards, Jin

sr99622 commented 9 months ago

I see what you're saying. It looks like the multiple python version issue has been around for some time. There are some posts indicating that setting the python location explicitly when calling cmake might help. -DPython3_ROOT_DIR or -DPython_EXECUTABLE have been mentioned, but some claim that these don't always work.

Personally, if I need multiple python versions, I have used conda in the past, which seems to isolate them pretty well. There are some other issues with conda that make it a less than perfect solution, but it seems to work in most cases.

Hopefully, your camera will work, it can be a dice roll sometimes depending on the camera implementation.

jin-eld commented 9 months ago

On Fedora they offer basic Python packages for all the various versions in the standard repo, allowing the user to set up an own venv which is quite convenient. I never tried conda and I am not sure I'd like to )) Anyway, it compiled in the end.

Hopefully, your camera will work, it can be a dice roll sometimes depending on the camera implementation.

Not sure if they were lying about ONVIF support of this camera - no luck so far. It's actually an iCSee kind of cam, I understand this app is able to control all sorts of brands, this one is from Wondsar (bought it for ~20€ on AliExpress).

I compiled onvif-util and tried to connect via cli, but did not have any luck either, wireshark suggested, that the tool tried to use some port which is not open on that cam - I think it's expecting everything on 80/HTTP. My next approach will be to sniff out the traffic between the app and the cam, perhaps then it will become clearer if it uses ONVIF at all or if it's some proprietary crap :>