I already see this same error with my Atik 314.
In my case this is related to a bad USB cable.
You can look in syslog for a USB disconnect at the time of the first error.
sudo lsof /dev/ttyUSB0
this show you all the process using the device.
I use VNC a lot, for telescope computer control but also for my build and test server on the cloud. There is no need to use other software than the one provided by the Linux distribution.
If the remote computer has a real screen I want to share, I just run the vino server included with Ubuntu.
On a headless computer I install vncserver, using one of the alternative, both vnc4server and tightvncserver work for me.
A detached session is started by an init script. Something like: /bin/su - $VncUser -c "/usr/bin/vncserver -geometry 1680x1050 -depth 24 :1
In the user home directory create a .vnc directory to contain the password file and the xstartup script the allow you to start the desktop and the application you want.
The client I find the more stable and easy to use is krdc, a KDE application.
If the client is on your local subnet you can just connect with : krdc vnc://host:1
For remote access over Internet the best is to use ssh to encrypt the communication. You probably already have ssh configured for shell access.
Then connect using: krdc vnc://localhost:2
Maybe the problem is because INDI do not use the last version of libEFWFilter.
indi-3rdparty/libasi/CMakeLists.txt show a version 0.3.1205 updated on 2017-12-05
But on ZWO web page there is a version 0.4.1022 from 2018.10.22
It is probably worth someone with a ZWO wheel try to update this library.
To respond to your question, you must install first the library at a given level and then compile and install the same level driver.
Personally I use my Atik 314L+ every clear night, I have used all this version including the last 1.8.2 without any issue.
But this is on i386, so there is still a doubt about the armhf build. Can you try with your camera connected on a i386 or amd64 platform?
Wim, which system do you use?
If Ubuntu, this package is available only since 18.04, see:
Thank you for this work!
I just installed it, connect to mosquitto, do some test with the indi simulator and browse the result. This look fine.
Not sure if this is documented somewhere but my understanding is the saved setting is loaded only if a client send CONFIG_PROCESS.CONFIG_LOAD or CONFIG_PROCESS.CONFIG_DEFAULT
CONFIG_LOAD load from the file driver_name.xml and CONFIG_DEFAULT load from driver_name.xml.default.
driver_name.xml.default is saved the first time the client call CONFIG_PROCESS.CONFIG_SAVE, the next time it save to driver_name.xml. So driver_name.xml.default is not necessarily the hardcoded values.
I don't know how KStars manage CONFIG_PROCESS, but in my applications I have a check box if the user want CONFIG_PROCESS.CONFIG_LOAD be send after the device is connected.
Yes, new name for new name librawcr3 is better that libraw20.
We must also be sure this library will be removed when no more need.
Yes if the version in the distribution is different it work OK.
18.04 and 18.10 use libraw16 so no problem.
19.04 and 19.10 use libraw19 and it break when libraw is replaced by the master version with the same name.
A solution is if libraw change it's version to 20 instead of making a snapshot with the old version number.
If I build libraw from master and install on my system every KDE graphic application crash with segmentation fault as soon I try to open a raw file.
The crash is when libKF5KDcraw.so call libraw, probably because of some structure format change in the new version.
Here a backtrace:
Thread 4 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe527a700 (LWP 8900)]
LibRaw::LibRaw (this=0x7fffe51ef990, flags=0) at src/utils/init_close_utils.cpp:26
26 LibRaw::LibRaw(unsigned int flags) : memmgr(1024)
#0 LibRaw::LibRaw (this=0x7fffe51ef990, flags=0) at src/utils/init_close_utils.cpp:26
#1 0x00007ffff53aa740 in KDcrawIface::KDcraw::loadEmbeddedPreview(QByteArray&, QBuffer const&) ()
#2 0x00007ffff7d83ff2 in ?? () from /usr/lib/x86_64-linux-gnu/libgwenviewlib.so.5
#3 0x00007ffff7d81d64 in ?? () from /usr/lib/x86_64-linux-gnu/libgwenviewlib.so.5
#4 0x00007ffff619e262 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5 0x00007ffff619acc2 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
This is bad if we cannot replace libraw without rebuilding all the applications.
Trying to port CR3 support but keep the previous structure compatibility is probably a lot of work.
Installing the library with another name is very bad.
PixInsight do not have this problem because libraw is statically linked. But this is not a good solution too.
Maybe look with the Debian maintainer if a backport is planned?
Any other idea?
Thank you, this fix the other application. The version number was changed after the "snapshot" release in this commit:
But do this build support CR3?
objdump -TC libraw.so.19.0.2 |grep crx return nothing.