Choose Lens Calibration stating page as a tool to get a picture, probably any other option will also work.
Regarding the command line: see the thread, what additional information is missing? Just to avoid to spam this thread with the same information again and again.
FWIW, I’m booting Ubuntu 20.04.1 from iso and installed LightBurn 1.2.04.
I pulled out a half dozen cameras and 2 of them presented a black screen. I then installed LightBurn 7z file( into ~/LightBurn ), installed git and ran the bash script which gets some old gstreamer libs into ~/LightBurnLibs and both cameras showed images.
One camera would only show the image for 20-30 seconds and then would freeze with the console output looking like this:
"WebCam Instant " "/dev/video2"
res: 176 x 144
res: 352 x 288
default: -1 x -1
Setting res: 352 x 288
Unable to query the parameter info: "Invalid argument"
Unable to query the parameter info: "Invalid argument"
Unable to query the parameter info: "Invalid argument"
CameraBin error: "Internal data stream error."
and this:
ubuntu@ubuntu:~/LightBurn$ v4l2-ctl -d /dev/video2 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Type: Video Capture
[0]: 'JPEG' (JFIF JPEG, compressed)
Size: Discrete 176x144
Size: Discrete 352x288
The other camera which starts working and stays working after the old gstreamer libs:
"USB Camera (0553:0002)" "/dev/video2"
res: 160 x 120
res: 176 x 144
res: 320 x 240
res: 352 x 288
default: -1 x -1
Setting res: 352 x 288
Unable to query the parameter info: "Invalid argument"
Unable to query the parameter info: "Invalid argument"
Unable to query the parameter info: "Invalid argument"
and this:
ubuntu@ubuntu:~/LightBurn$ v4l2-ctl -d /dev/video2 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Type: Video Capture
[0]: 'CPIA' (GSPCA CPiA YUV, compressed)
Size: Discrete 160x120
Size: Discrete 176x144
Size: Discrete 320x240
Size: Discrete 352x288
That’s an interesting “data point”.
Is the build system still 16.04? Maybe there are now some incompatible changes in some libraries.
Would be an interesting experiment, if building on 20.04 LTS changes the behavior.
What “build system” are you referring to?
LightBurn now supports 18.04 and 20.04 so I would think they are building on the lower and testing on 20.04.
My script gets gstreamer libs from 16.04…
#!/bin/bash
#
# if LightBurn update feature does not work, try installing libssl1.0-dev
#sudo apt install libssl1.0-dev
HERE=`pwd`
lbDIR=~/.local/share/LightBurn
lbDIR=~/LightBurn
lbCMD=$lbDIR/LightBurn
lbLibsDIR=~/LightBurnLibs
gstLibs=gstreamer-1.0
if [ ! -d $lbLibsDIR/$gstLibs ] ; then
cd
git clone http://github.com/dlarue/LightBurnLibs
cd $HERE
fi
GST_PLUGIN_SYSTEM_PATH=${lbLibsDIR}/${gstLibs} $lbCMD
Well since I gut an email a few days ago (see above) that stated they build with 16.04 I expect that it didn’t change.
We build and test with 16.04, a much newer version may have issues.
That would be a crazy thing for a developer to do… Was that email from a LightBurn dev or support person?
Yes they have not updated their Linux support versions tags but a LightBurn support staff person stated they now support Ubuntu versions 18.04 and 20.04. Camera is recognised but no picture is captured - #26 by ColinW
No name, I guess it was a supporter, but since they claimed until a few days ago on their download page (edit: or was it in the documentation) that it should run on 16.04+, the assumption is not that far fetched, especially in combination of the mail.
A LightBurn employee responded on this thread 2 days ago that they only support 18.04 and 20.04 so I would think THAT is what should be believed. Not an email from a user of the software and not a LightBurn web page which hasn’t been updated and says it runs on 16.04+. I’m betting on the staff employee stating what is current.
And I have a feeling it won’t run on 18.04 since the GLIBC issue others had states needing 2.29 and IIRC 18.04 is 2.27. But I’m downloading 18.04.6 now and will test to be sure.
@Colin only stated what they support, nothing about the build system.
And inserting 16.04 libraries with good result is an other indicator in my eyes. If it was really build with the newer libraries in 18.04 or even 20.04 the 16.04 libraries had a good chance of not working.
I just booted Ubuntu 18.04.6 and LightBurn 1.2.04 would not run because of the GLIBC v2.29 requirement, really just libm. v18.04.6 is running glibc v2.27. I downloaded glibc 2.29 and compiled it then copied libm.so.6 to the LightBurn directory and loaded LightBurn with LD_PRELOAD=./libm.so.6 LightBurn and it ran.
As referenced here: Linux Lightburn - #10 by Crowloy
it is a data point… there could be a regression or new APIs in the gstreamer subsystem on 18.04 and/or 20.04. I pointed this out because years none of my cameras worked in 18.04 back when they were only supporting 16.04 and it was made to work by bringing the gstreamer 16.04 libraries forward.
Sorry, I don’t seem to be helping here…
No no - it’s all good data points.
Please know that even us devs are frustrated with this one… We test on a variety of Linux versions but as you are seeing, it’s not always a consistent failure. With the cameras I have I had it working fine the other day on Ubuntu 18, 20, and 22 with the only caveat being that for 22 I had to run Xorg instead of Wayland for one of the cameras, for a reason I still don’t know.
Regarding the “Build System” - please note that as of 1.2.03 we are building on Ubuntu 20.04 whereas before we were building on Ubuntu 16.04. The Qt version did not change: 5.15.2
This is the reason for the glibc change.
We are trying to find a balance since building on Ubuntu 16 was holding back newer releases and we generally try to prioritize supporting older operating systems if possible since a lot of people like to use old machines to run their lasers. This is why we still support Windows 7 even when MS doesn’t.
I think part of the problem is that in recent distro releases gstreamer has been pushed forward with some changes that aren’t super compatible with Qt 5.15 and the move to Wayland has thrown in its own complications. The “solution” to this, honestly, is to move to Qt 6. However, that basically requires dropping support for old OS’s and is a non-trivial update for us to do.
One of the things I am researching, however, is also providing a snap package version of LightBurn. My general understanding is that this would allow us to package the “correct” versions of all the libs that LB requires so that we are no longer dependent on the system libraries. I don’t exactly have an ETA on that at this time, but I will certainly reach out and provide betas of that package for people to try out when the time comes.
Many thanks to all of you for continuing to provide great data on what you are seeing and bearing with us. We’re doing our best to provide a good experience for the beta users and I hope to make it even better soon.
I figured as much since it was looking for GLIBC v2.29 which is newer than 18.04.x had.
Snap and app images do let you bundle the libs needed. One of the reasons I tested just linking in libm.so.6 from the glibc 2.29 package was to point out it’s just one Math library holding things up.
Appreciate all that you guys put into this and into the Linux version.
Is there any reason why not AppImage which does the same as Snap but without the package manager fontend. I could see using the same install process you’re currently using but in the .local/share/LightBurn director would be LightBurn.AppImage and the .desktop would reference it.
If I were running 18.04 now, I would just move libm.so.6 built from glibc 2.29 into the LightBurn/lib directory. Or put it on my github repo and include the test for it before running and git it if not found where it should be.
One of the things I loved about *nix stuff years ago when I was doing Windows and OS/2 was how a software package could retain all the libs it needed locally in a tar file and directory if needed. I’ve had to patch up old software installs this way for years. DLL hell, lib hell, etc it’s tough to move forward without dragging the whole forest along with you.
Possible? We actually already use linuxdeployqt which can produce an AppImage. The problem I had with that in the past was getting it to actually pull in the necessary libs and run in full sandbox mode when using linuxdeployqt to generate it.
Maybe that has changed in recent versions of that tool? I’ll check.
I was mostly just used to snap as having a “more complete” sandbox, from what I have seen. I’m happy to be proven wrong as an AppImage would be easier to generate.
The gotcha with Snap packaging is being unable to write files outside the user’s home directory, because “security”. I think AppImages don’t have that restriction.
All our data lives on a server in the basement with automagic daily backups, making the desktop / laptop boxes are pretty much disposable. Unfortunately, I long ago mounted the NFS shares outside the home directory and must go through contortions to use Snaps.
LightBurn runs fine on whatever Manjaro’s rolling release serves up these days, which seems to include both QT5 and QT6 libraries. I do design / layout / tweaking in the Comfy Chair upstairs, save the LB file, trot downstairs, load the file on the box atop the laser, rearrange the pieces to match the material, and fire away.
Admittedly, I rarely save the rearranged LB file, but moving it back to the server would require several (easily forgotten) manual steps.
Have ordered an other camera, curious if that one will behave differently. Is advertised with an different chip so that might help.
Ok, a first try says that camera works, even though I can not say what the difference ist.
Will install it in the next days and hope it solves my problem (someone in need of two camera modules not working with openpnp? 
).
Don’t know if that is related: if I have the camera control window enabled, it sometimes resizes the sidebar for nor apparent reason so it completely hides the “drawing space”.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.