No video, error 500 in the logs (python3/dev branch) #2398
Comments
|
Looks like there is another bytes > string conversion missing. Those are regular V4L2/ I'll have a look into the code tomorrow. Btw, would you mind to help adding Arch/pacman/pkg support to the new motioneye_init > linux_init command for installing motion, v4l2-utils, FFmpeg and the motionEye service + config? Currently only DEB and RPM based distros are supported, but adding Arch (and probably Gentoo, although it uses a different package manager) would be great. |
Thank you, yes. These both are standard V4L2 cameras, nothing fancy/special.
On Arch or Arch-based distros it's Really what Arch users are supposed to do (if using |
|
Ah, I wasn't ware that there is a motionEye package in AUR. Great community I must admin 🙂.
Btw on the tmpfiles:
And: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=motioneye-git#n40
|
Sure, once there is a release tag I can adopt the AUR has no official support (https://wiki.archlinux.org/title/Arch_User_Repository) and I doubt
Thank you, I removed that file.
Yup, Arch also uses symlink. I think I just left that from the previous commits as I was updating the ticket. But as it's unnecessary I removed this also.
Fixed. Thank you for your valuable comments. |
|
Great. Okay, so I think we can assume Btw, I wonder what the different, or different aim of the motioneye and motioneye-git packages is. Was the latter only created to make use of the Python 3 (and now |
Yes, I think it's a safe bet. Also, Arch users often are aware of what AUR helper they use (and just replace
Having |
|
Okay, thanks for clarification, makes sense. |
|
What about the initial report? I get the same 500 errors with chromium on a Raspberry Pi but nowhere else. Chromium on Linux does not have the same problem. Is that maybe related to browser caches when coming from an older version? How can I reproduce or get rid of the problem? |
|
For me it's the same in Firefox and Google Chrome - both in normal and incognito/private mode. I've also tested both cameras in https://meet.jit.si/ (making a new session) and looks to be working fine there. |
|
I tried to understand where this bytes, which shall be a string, are coming from:
The Calls this method: https://github.com/motioneye-project/motioneye/blob/16fd474/motioneye/mjpgclient.py#L98-L100
The question is why this is assumed to be a string, why this is true in most cases (I never faced this issue) but not in yours, even depending on the browser 🤔. Although it also depends on whether a resizing is done or not, since otherwise the function returns We could simply run sed -i 's/StringIO(jpg)/StringIO(str(jpg))/' /usr/local/lib/python3.*/dist-packages/motioneye/mediafiles.py
systemctl restart motioneyeWe could also use |
|
After |
Okay, to me it looks more and more that this resizing is not done often, so that this quite clear type error has not been detected yet. Probably with Python 2 (and related older module versions) PIL took string file objects, but doesn't do that anymore: https://pillow.readthedocs.io/en/stable/reference/Image.html#PIL.Image.open sed -i 's/StringIO(jpg)/BytesIO(jpg)/' /usr/local/lib/python3.*/dist-packages/motioneye/mediafiles.py
sed -i 's/StringIO(str(jpg))/BytesIO(jpg)/' /usr/local/lib/python3.*/dist-packages/motioneye/mediafiles.py
systemctl restart motioneye |
|
Substituted and restarted: |
|
Let's try to create the target file object as BytesIO as well: sed -i 's/sio = io.StringIO()/sio = io.BytesIO()/' /usr/local/lib/python3.*/dist-packages/motioneye/mediafiles.py
systemctl restart motioneyeThis matches how it is done in |
|
|
This is now failing with a different error at an earlier place which is not affected by the last change. I searched for this and found: https://stackoverflow.com/questions/12984426/pil-ioerror-image-file-truncated-with-big-images So it seems to be when the received JPEG is somehow not complete, like chucked badly by the webserver or somewhere along the line. There is an option to allow PIL processing truncated images. The remaining space is then filled white/grey, but better than crashing: sed -i 's/^from PIL import Image$/from PIL import Image, ImageFile/' /usr/local/lib/python3.*/dist-packages/motioneye/mediafiles.py
sed -i '/image.thumbnail((width, height), Image.CUBIC)/i\ ImageFile.LOAD_TRUNCATED_IMAGES = True' /usr/local/lib/python3.*/dist-packages/motioneye/mediafiles.pyBut I'd prefer someone with more experience with tornado, MJPEG streams, general data streams I/O object processing and/or PIL would have a look over that code. Probably we can simplify and harden it at some point, but for me it is hard to keep the overview as well as depth on certain modules, so that it feels more like dirty patching what I try here, than a real sustainable solution 😅. Not sure whether feasible and it doesn't have an effect until including the code that is dealt with here, but it would be probably good to skip using the motionEye's HTTP API from the backend itself: GET /picture/1/current/?_=nnn&width=n.nn&_username=admin&_signature=xxx (127.0.0.1)Looks like the backend itself ( |
|
With the latest replacements I get a little more image data, this is me sitting in front of the camera with headphones on: In the log: When I get a chance I'll test this on my laptop with integrated camera to see if I get similar behaviour. Thank you for your help and patience. |
|
Okay great, at least it is not crashing anymore. The remaining error in motionEye logs is unrelated and can be ignored. Of course we should try to solve it as well: #2382 I'll open a PR with these changes and add a bunch of reviewers, let's see whether someone has a cleaner solution in mind. But at least there is one. I don't know why there is so much data missing for the incomplete (?) image, whether this is expected if e.g. bandwidth is limited (instead of having lowered FPS) and how to resolve this. Another reason for deeper investigation and a cleaner solution. |
|
FWIW I did a test on a laptop with the latest |
|
Interesting that this was an issue before already. I though it was introduced with Python 2 => Python 3 conversion. However, no need to test with |
|
Probably #2432 solves the issue with the chunked JPEGs and hence the artefacts in your stream. The string/bytes format fixes however still need to be applied. Probably you can test to apply these changes manually. |
|
I tested with the latest |
|
Based on the errors logs, if there are some, the following two should still be required if server side image resizing is done: sed -i 's/sio = io.StringIO()/sio = io.BytesIO()/' /usr/local/lib/python3.*/dist-packages/motioneye/mediafiles.py
sed -i 's/StringIO(jpg)/BytesIO(jpg)/' /usr/local/lib/python3.*/dist-packages/motioneye/mediafiles.py
systemctl restart motioneye |
|
I've got a nice black&white image from both cameras (on my desktop PC) and this message in journal log: |
|
motionEye does not support motion 4.4 fully yet, please use motion 4.3.2. We're working on it but I need some help to finish the netcam settings mapping: #2462 |
|
Ha, finally a colorful picture! 🎉 So first I downgraded motion to 4.3.2 and restarted. No luck, then I started digging into motion alone. Stopped motioneye and started: This produced a color stream from the camera. Ok but this is not what motioneye is running so I stopped it and ran This time it went into b&w mode again. I opened the config file and changed the first from in the code |
|
Hmm, not sure about that either. I didn't know the setup mode until now, to be honest 😅. But great that it works now. |
|
Marking this as closed as it has been solved in |
Using the latest
devbranch on Arch Linux system with two Logitech webcams connected. For some reason I get no signal from either of the cameras (yet they work fine in e. g.xawtv). The log goes like this:Camera activity LED is on. Any idea?
Update: If I move the resolution dimmer slider to 100 then the error flow stops and I get the picture but it's only grayscale and of a low quality.
The text was updated successfully, but these errors were encountered: