I will be ready if you need more data or experiments.
phew ok it seems it was a slightly simpler fix than expected. It will also fix the SSL error message, BTW. Keep an eye out for the RC4 update on the main thread.
1 Like
You got it fixed incredibly fast, Iām excited and looking forward to RC -4 - thank you
1 Like
I kind of fixed it by accident. I was taking a short break and trying to fix the SSL error, because that I know where it comes from and how to fix. Fixing the one, kind of fixed the other. 
4 Likes
And RC4 is out now, with the fix for both the SSL error, and hopefully the camera handling. Public Release Candidate - 1.7.00 - #78 by adammhaile
1 Like
Hi @bernd.dk - Iām seeing the following lines in your syslog:
Sep 5 12:56:52 laser-computer kernel: [ 179.118998] usb 2-1.4: Found UVC 1.00 device Lightburn Camera (1bcf:2cb4)
Sep 5 12:56:52 laser-computer kernel: [ 179.208819] usb 2-1.4: 3:1: cannot get freq at ep 0x86
Sep 5 12:56:52 laser-computer kernel: [ 179.211572] usb 2-1.4: 3:2: cannot set freq 11025 to ep 0x86
Sep 5 12:56:52 laser-computer kernel: [ 179.213310] usb 2-1.4: 3:3: cannot set freq 16000 to ep 0x86
Sep 5 12:56:52 laser-computer kernel: [ 179.214822] usb 2-1.4: 3:4: cannot set freq 22050 to ep 0x86
Sep 5 12:56:52 laser-computer kernel: [ 179.221335] usb 2-1.4: 3:5: cannot get freq at ep 0x86
Sep 5 12:56:52 laser-computer kernel: [ 179.224067] usb 2-1.4: 3:6: cannot set freq 32000 to ep 0x86
Sep 5 12:56:52 laser-computer kernel: [ 179.225808] usb 2-1.4: 3:7: cannot set freq 44100 to ep 0x86
Sep 5 12:56:52 laser-computer kernel: [ 179.227335] usb 2-1.4: 3:8: cannot set freq 48000 to ep 0x86
Sep 5 12:56:52 laser-computer kernel: [ 179.274078] usb 2-1.4: Warning! Unlikely big volume range (=4096), cval->res is probably wrong.
Iām thinking theyāre indicative of a problem setting the camera mode properly, or not having enough USB bandwidth. Are you plugging in through a USB hub? Is it possible the USB hub is USB 1.0 instead of USB 2.0? Or was this working with an older release at some point?
Hi John, Camera has worked with Lightburn for Linux but I canāt just remember when (which version) it broke but it happened here in the last quarter year ā¦
I will try tonight if I can find a working LB version.
ā¦ no hub and same physical USB connector as āalwaysā, and cheese finds fine LB camera
Thanks for the information. I was just guessing, so I will keep digging into what could be causing this. Unfortunately looks like upgrading the Qt version wasnāt the only fix we need here.
Because I like to be a bit proactive in the troubleshooting process, I started by installing all LightBurn versions, backwards, all the way down to 1.4 and tested the camera function in LB and Cheese.
In LightBurn, all versions show my LightBurn camera in the list but do not āfetchā it.
Purely by chance, I tried another usb port and here my camera worked !!
I have 6 USB ports/sockets on the back and 2 ports/sockets on the front. No. 2 on the front has always been reserved for the camera and worked, but now it doesnāt work anymore.
I think it is somehow āseizedā by something else.
What confuses me is that it shows a LB-camera on USB plug/port2 and when I unplug it shows that there is no cameraā¦, it detects a camera but canāt use it in LightBurn. (on usb port 2)
But it doesnāt matter, the camera works fine, with all versions of LB, just not on the one USB port. I know that and it means nothing to the functionality of the computer or LightBurn.
I apologize for causing so much extra effort to find a fake malfunction. I thank you for your efforts and am now more confident that ver.1.7 will serve me well on my laser computer for a few years.
3 Likes
On a new Manjaro install with LB RC-4, shuffling the USB ports did nothing to make any of the three cameras functional. None display a preview when selected, regardless of where theyāre plugged; a USB 3 hub plugged into a USB 3 port on the PC has worked perfectly with all LB versions up to 1.7.
VLC shows good video from all three cameras, regardless of their port / hub / whatever.
Can you check your LB output when starting from the command line and share it here?
If @bernd.dk 's issue is fixed, Iām curious to see if maybe Manjaro has a rolling release causing version incompatibilities with some of the underlying libraries.
Thanks!
Glad to see your camera is working properly!
About the ghost camera/USB port assignment, is it possible you dug into config files/udev rules at some point and made it create a ghost device on that port as a result of that?
That may well be the case:
LB-1.7RC4.txt (1.1 KB)
Oddly, thereās a plugins-bad installed:
gst-libav 1.24.7-1 extra 248.6 kB
gst-plugin-pipewire 1:1.2.3-1 extra 138.6 kB
gst-plugins-bad 1.24.7-1 extra 3.8 MB
gst-plugins-bad-libs 1.24.7-1 extra 12.2 MB
gst-plugins-base 1.24.7-1 extra 970.4 kB
gst-plugins-base-libs 1.24.7-1 extra 12.5 MB
gst-plugins-good 1.24.7-1 extra 7.4 MB
gst-plugins-ugly 1.24.7-1 extra 562.6 kB
gstreamer 1.24.7-1 extra 11.6 MB
manjaro-gstreamer 20221002-1 extra
This may be one of those ānot that plugins-badā situations, but dinking around with gstreamer seems fraught with peril.
Iām willing to burn that box down to bedrock and do another clean Manjaro install if itāll help move the ball toward the goal.
So I think these should not be used. The whole gstreamer stack is now embedded in the AppImage. Or it should be, at least. But itās possible there are bindings to lower level libraries causing issues.
Iām not as familiar with Manjaro as I am with Debian, Ubuntu and their variants, but I will point out the supported distribution for 1.7 will be Ubuntu 22.04, and possibly 24.04, if we have enough time to finish testing that well enough.
I hope youāll understand that for support reasons, if you want to try and fix it up on Manjaro youāll be doing so on your own? The AppImage helps a lot, but itās not a universal silver bullet. That would be a docker image. But there are even more reasons that that is not what weāre shipping.
So if youāre really interested in Linux, but willing to rebuild your system, I highly recommend Ubuntu, or mint if you really donāt want a canonical system.
Well, I am, but you officially aināt and thatās pretty much everything of importance in this discussion. 
The least awful way out (for me, anyhow) may be a dedicated Win 11 box [^1] at the laser, then duplicating the UI upstairs using RDP / VNC / Parsec / whatever. That way I can push designs around from the Comfy Chair on my usual Linux desktop, then Fire. The. Laser. in the basement.
Iāll stand up the n-1 Token Windows Laptop as a testbed to see what jank emerges.
[^1] IIUC, EOL Windows versions will be discarded in short order, so thereās no point in deep emotional attachments.
So, 1.7 is still releasing for Linuxā¦ And will be supported on Ubuntu 22.04.
We wonāt release 1.8 on Linux, so if you donāt need/can live without the new features, you can still use Linux indefinitely.
We wonāt be pulling the plug on existing, functioning, Linux licenses either. There was a lot of flak and misreading of what it actually means. But we stand by our commitment to let people use the software they have, on whichever os, forever. We just canāt dedicate as much time moving forward to keeping Linux as a platform we dedicate developer, testing and support staff time. Not with Millmage and its expected support burden as a new product.
I myself am a Linux daily user. Iām masochistic enough I run Gentoo on my personal machine. But when I see the kind of issues and the time it takes to fix Linux compatibility issues on one distributionā¦ It just takes too much time away from writing the features we want to bring forward to make the software a happier experience overall.
I regret that we canāt deliver Linux users a version moving forward, but weāre not taking anything away, ever. And as 1.7 will be the last Linux release for the foreseeable future, weād like to āgo out with a bangā if possible, meaning having fixed as many usage issues as possible.
Manjaro is unfortunately too difficult to target as a compatibility target. The rolling release of the essential underlying system libraries (glibc, xorg, xcb, etc.) make compatibility with a fixed release binary an impossible target without constantly recompiling our binary on top of it. A burden we canāt afford. Ubuntu LTS, for all its canonical-driven evils and issues, does address that major hurdle. As would a number of other distributions (Ubuntu derivatives, CentOS, Debian, SuSE, and so on). The reason we chose Ubuntu as the supported distribution is because of its overall popularity and the LTS reliability.
So while I understand the distaste one can have when needing to use a Linux distribution thatās not the one we favorā¦ Isnāt it still better than having to change OS entirely? Itās up to you, as Iāve successfully tested RC4 running properly on Mint 21.3, and another colleague tested it on Arch. Though we donāt recommend those options, they can work depending on your needs and how close to the versions of the system libraries of Ubuntu 22.04 you lock down your system.
2 Likes
I could run a fossilized Linux box with 1.7, because (as you point out) there is absolutely no way 1.7 will continue to work given the usual Linux updates. I do that with Debian for my Sherline mill: it gets reinstalled whenever LinuxCNC fires off a new release on a new live CD (and Iām not in the middle of a house move).
But using LightBurn means Iām absolutely dependent on, among other things, having its license infrastructure continue to work with that fossilized version on a fossilized OS. Iāve outlived enough proprietary programs to not believe anything said about their future plans, other than knowing I will have little time to react to those changes.
So a Win 11 box stripped to a single function seems the least awful way forward. It has guaranteed long-term corporate interest, costs under a kilobuck, and buys some time after the next change in direction.
I rest my case.
(Not mad, but also not the first time around this block.)
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.