Heh, good that it was solved, yes the ignore setting is for fork mounts and such which don't require any special pier side handling.
Syncing dome to the scope is all handled by the base INDI Dome class, the driver only sees commands to move to absolute azimuth angle. With my ScopeDome dome OTA offset definitely does have an effect and is critical for successful syncing. It's easy to see by slewing to near the meridian and near horizon so that the mount is sideways and not upright like in park position towards the pole.
Scheduler runs the jobs in order (unless you enable sorting by score in which case it reorders those itself) and in this case the second job has start time set before the first job ends. Switching those two around so that the earliest job is at the top should fix it. Having other automatic sorting options might be useful too. I usually use repeat for N repeats myself so that I get full sets of all filters and it's less timing dependent (and easier if I continue with the same schedule over multiple nights), but have used the repeat until condition in some cases to avoid meridian flips as well.
Oh, that's unfortunate then, people can be defensive of "their" code after working hard on it and depending on the timing and way of presenting the issue can be crucial as we are all human after all.
Jasem does have quite a lot on his plate as is so having him hunt for magic patches with disparaging comments added doesn't help. Preparing a merge request at invent.kde.org/education/kstars and having discussion there would be the easiest way to get it merged.
Autohome works well, I've had to use it a few times after I've messed up the mount state somehow (usually cutting power at wrong time). If the mount is pointing totally wrong way, I usually first manually run the scope roughly in the right position so that it doesn't hit the pier or anything while it finds the home sensors. As said I have the older EQ8, but as far as I know it should work the same with EQ8-R too if the mount code has been added so that the driver detects the capabilities correctly.
My older model only has USB in the handset so I need to still use the same RJ45 EQDir cable I used with HEQ5, but EQ8-R has additional USB-B in the mount as well and can be used directly with EQMod with just USB-A-B cable. Difference is that baud rate needs to be set to 115k instead of 9600 used with EQDir cable but otherwise it should work exactly the same.
You should always park the mount before turning off power and start from the same position when turning power back on, otherwise the model doesn't work. I used HEQ5 in remote observatory for a few years and usually only made a new alignment model if I had physically moved the mount and everything worked just fine.
I switched from HEQ5 to EQ8 (the older model) and at least there is was very much plug & play, nothing changed except additional capabilities like possibility to autohome (which is very useful in a remote observatory) and so on.
Not sure about best as I don't have experience with any other wheels, because my Starlight Xpress USB wheel has worked flawlessly and doesn't require any external binary blobs to compile as it's a simple HID device.
Stellarium has had support for INDI in the telescope control plugin for a while, I'm not 100% sure, but I think it's included in the Windows version too:
Thanks, that is useful information, I usually run Debug builds, have to try with Release too. The binary sizes are in line with what I have on x64 and ARM, release version does inline a lot more stuff (it uses -O3 optimization level by default) which causes the size to balloon quite a bit. Optimizing for size (CMAKE_BUILD_TYPE=MinSizeRel) might actually be better in that case.
Thank you, especially out.log looks interesting, everything seems to go normally, the dome connects and commands seem to get valid data, but then it just dies.
<message device="ScopeDome Dome" timestamp="2021-08-25T18:02:32" message="[DEBUG] read response: 8056"/>
2021-08-25T18:02:32: Driver ./indi_scopedome_dome: stderr EOF
<delProperty device="ScopeDome Dome"/>
2021-08-25T18:02:32: Client 0: queuing <delProperty device='ScopeDome Dome' name=''>
2021-08-25T18:02:32: Driver ./indi_scopedome_dome: restart #1
This shows the driver has crashed and indiserver restarts it.
2021-08-25T18:02:32: Driver ./indi_scopedome_dome: pid=6114 rfd=3 wfd=7 efd=8
2021-08-25T18:02:32: Client 0: sending msg copy 1 nq 9:
<message device="ScopeDome Dome" timestamp="2021-08-25T18:02:32" message="[INFO] Steps per revolution read as 8056"/>
If you can run the indiserver under gdb, that would show where the driver crashes and would help fix the issue.
The command line for gdb needs a few flags, something like: gdb --eval-command=set follow-fork-mode child --args indiserver -v ./indi_scopedome_dome
then type "run" and connect normally to indiserver and if/when the driver crashes, "where" would show the place and stack trace.