<div dir="ltr">BTW, FWIW, I started running again. It finished the first image and went into its 3-minute-long (this time) star detection<div>on the sub that I described above as 'Major Problem'. I noticed that it was using 3 or 4 CPUs at near 100% to do this.</div><div>I doubt that this was ever multi-threaded before. So, apparently, in addition to the SEP library running in a separate thread, </div><div>the SEP library is also running multiple processes on its own. These both seem like likely suspects for these memory issues.</div><div><br></div><div>Hy</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 20, 2020 at 9:01 PM Hy Murveit <<a href="mailto:murveit@gmail.com">murveit@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Started testing Jasem's change tonight, 30 minutes ago.<div>TL;DR It runs better than before, but unfortunately still crashes. A few other bugs too.<br><div><br></div><div><b>ISSUES</b></div><div><br></div><div><b>Most Major problem</b>. Worked for a little while (a few minutes?) which is much better than before when it crashed pretty much at the start of guiding, but then still segv'd. Started again in gdb in hopes of getting a stack trace. Running for a while...segv'd after about 10 minutes. See pretty unhelpful stack track below.</div><div><br></div><div>In summary, I ran it twice, crashed after a couple minutes the first time, crashed after 10 minutes the 2nd time. Always seems to crash in the guider's request for star extraction. Can we run star extraction on the normal thread instead of the threading we're doing?</div><div><br></div><div><b>Major problem</b>. Computing the HFR after my sub (8-minute Ha image) <span style="background-color:rgb(255,255,0)">used to take 1-5 seconds</span>. It needs to detect stars, calculate individual HFRs, etc</div><div>I did some work to optimize the time for this. <span style="background-color:rgb(255,255,0)">It took 130+ seconds</span> for my first image with stellarsolver! I can try and help fix that somehow.</div><div></div><div><br></div><div><b>Minor problem</b>. I noticed is that in the guideview, even though I checked and am 100% sure it was off, the little button called 'Detect Stars in Image' in the guideview window got enabled and there are little red circles over the detected stars. This is a little bug--didn't used to be this way.<br></div><div><br></div><div><br></div><div>Wish I had better news,</div><div>Hy</div><div><br></div><div><b>End of GDB output including crash and backtrace.</b></div><div><b><br></b></div><div>[New Thread 0x9ec56090 (LWP 16299)]<br>[Thread 0x9ec56090 (LWP 16299) exited]<br>[New Thread 0x9ec56090 (LWP 16333)]<br>[Thread 0x9ec56090 (LWP 16333) exited]<br>[New Thread 0x9ec56090 (LWP 16364)]<br>[Thread 0x9ec56090 (LWP 16364) exited]<br>[New Thread 0x9ec56090 (LWP 16398)]<br>[Thread 0x9ec56090 (LWP 16398) exited]<br>[New Thread 0x9ec56090 (LWP 16432)]<br>[Thread 0x9ec56090 (LWP 16432) exited]<br>[New Thread 0x9ec56090 (LWP 16462)]<br>[Thread 0x9ec56090 (LWP 16462) exited]<br>[New Thread 0x9ec56090 (LWP 16492)]<br>[Thread 0x9ec56090 (LWP 16492) exited]<br>[New Thread 0x9ec56090 (LWP 16526)]<br>[Thread 0x9ec56090 (LWP 16526) exited]<br>[New Thread 0x9ec56090 (LWP 16531)]<br>[Thread 0x9ec56090 (LWP 16531) exited]<br>[New Thread 0x9ec56090 (LWP 16560)]<br>[Thread 0x9ec56090 (LWP 16560) exited]<br>[New Thread 0x9ec56090 (LWP 16587)]<br><br>Thread 35 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.<br>[Switching to Thread 0xa4239090 (LWP 5157)]<br>0xb6fbc14c in memset () from /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so<br>(gdb) bt<br>#0 0xb6fbc14c in memset () from /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so<br>#1 0xb421a500 in SEP::Deblend::deblend (this=0x67985398, objlistin=objlistin@entry=0xa423855c, l=l@entry=0, <br> objlistout=objlistout@entry=0xa4238454, deblend_nthresh=deblend_nthresh@entry=32, <br> deblend_mincont=0.0050000000000000001, minarea=minarea@entry=5, lutz=0x4d348778)<br> at /home/pi/Projects2/stellarsolver/stellarsolver/sep/deblend.cpp:77<br>#2 0xb421ae84 in SEP::Extract::sortit (this=this@entry=0x7fef5478, info=info@entry=0x66ae1218, <br> objlist=0xa423855c, objlist@entry=0xa4238554, minarea=5, minarea@entry=-1541175988, finalobjlist=0x66be0218, <br> finalobjlist@entry=0x0, deblend_nthresh=32, deblend_nthresh@entry=3, deblend_mincont=0.0050000000000000001, <br> gain=1) at /usr/include/c++/8/bits/unique_ptr.h:342<br>#3 0xb421cbc0 in SEP::Extract::sep_extract (this=0x7fef5478, this@entry=0xa4238896, image=0x1a5e8308, <br> image@entry=0xa4238948, thresh=thresh@entry=8.42488956, thresh_type=thresh_type@entry=1, minarea=-1541175988, <br> minarea@entry=5, conv=conv@entry=0x66be01b8, convw=<optimized out>, convw@entry=3, convh=convh@entry=3, <br> filter_type=<optimized out>, filter_type@entry=0, deblend_nthresh=32, deblend_cont=0.0050000000000000001, <br> clean_flag=1, clean_param=1, catalog=0xa423889c, catalog@entry=0xa4238894)<br> at /home/pi/Projects2/stellarsolver/stellarsolver/sep/extract.cpp:643<br>#4 0xb41ebee8 in InternalSextractorSolver::extractPartition (this=0x76e6468, parameters=...)<br> at /usr/include/c++/8/cmath:475<br>#5 0xb41efa6c in non-virtual thunk to QtConcurrent::RunFunctionTask<QList<FITSImage::Star> >::run() ()<br> at /usr/include/c++/8/bits/exception.h:63<br>#6 0xb4855f30 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5<br>#7 0xb485eb58 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5<br>#8 0xb42c2494 in start_thread (arg=0xa4239090) at pthread_create.c:486<br>#9 0xb3979578 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 from /lib/arm-linux-gnueabihf/libc.so.6<br>Backtrace stopped: previous frame identical to this frame (corrupt stack?)<br>(gdb) <br></div><div><br></div><div><b>Here's the end of the log. Clearly in a guide-frame's star extraction.</b></div><div><b><br></b></div><div>[2020-10-20T20:39:36.043 PDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] GetRAEncoder() = 10576388 "<br>[2020-10-20T20:39:36.060 PDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] Current encoders RA=10576388 DE=9885062 "<br>[2020-10-20T20:39:37.115 PDT DEBG ][ org.kde.kstars.indi] - processBLOB() mode 2<br>[2020-10-20T20:39:37.122 PDT DEBG ][ org.kde.kstars.fits] - Reading FITS file buffer ( "1.2 MiB" )<br>[2020-10-20T20:39:37.188 PDT DEBG ][ org.kde.kstars.ekos.guide] - Received guide frame.<br>[2020-10-20T20:39:37.188 PDT DEBG ][ org.kde.kstars.ekos.guide] - Multistar: findTopStars 25<br>[2020-10-20T20:39:37.192 PDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] Compute local time: lst=21.51869180 (21:31:07.29) - julian date=2459143.65248889 "<br>[2020-10-20T20:39:37.209 PDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] GetRAEncoder() = 10576506 "<br>[2020-10-20T20:39:37.211 PDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] Current encoders RA=10576506 DE=9885062 "<br></div><div><br></div></div><div><br></div><div><div><b>Odd message</b>: Saw this as the last log line in the first crash:</div><div>[2020-10-20T20:14:08.358 PDT WARN ][ default] - QObject::~QObject: Timers cannot be stopped from another thread<br></div><div><br></div><div>also saw these earlier in a log, never seen them before, dont know if relevant:</div><div>[2020-10-20T20:15:57.329 PDT WARN ][ default] - QObject::connect: invalid null parameter<br>[2020-10-20T20:15:57.329 PDT WARN ][ default] - QObject::connect: invalid null parameter<br></div><div>[2020-10-20T20:15:58.014 PDT WARN ][ default] - QObject::connect: signal not found in Ekos::Mount<br>[2020-10-20T20:15:58.015 PDT DEBG ][ org.kde.kstars.ekos.capture] - Registering new Module ( "Mount" )<br>[2020-10-20T20:15:58.017 PDT WARN ][ default] - QObject::connect: invalid null parameter<br>[2020-10-20T20:15:58.017 PDT WARN ][ default] - QObject::connect: invalid null parameter<br></div><div>[2020-10-20T20:15:59.315 PDT WARN ][ default] - QObject::disconnect: Unexpected null parameter<br></div><div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 20, 2020 at 1:17 PM Robert Lancaster <<a href="mailto:rlancaste@gmail.com" target="_blank">rlancaste@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Yes, please, I agree! I am working on fixing up the options profile now.<br><div><br><blockquote type="cite"><div>On Oct 20, 2020, at 12:11 PM, Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank">murveit@gmail.com</a>> wrote:</div><br><div><div dir="auto">I'd like to suggest that since the main KStars branch still core dumps while guiding (every time for me) and perhaps there are other issues with flats, we should push back the release date for at least two weeks. I believe we need a stable two weeks of user testing before any major release.<div dir="auto"><br></div><div dir="auto">I know Jasem and Robert are working very hard to fix this, and in no way is this a knock on their work, just a desire to make this a stable release.</div><div dir="auto"><br></div><div dir="auto">I would propose that there only be bug fix commits during those two weeks.</div><div dir="auto"><br></div><div dir="auto">Comments?</div><div dir="auto">Hy</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 15, 2020, 9:55 PM Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank">murveit@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Core dump again with the 'load all indexes' flag unchecked. Am running in gdb now.<div>...</div><div><br><div>Also, it doesn't seem to remember that checkmark, nor the profile type (top menu under ""Options Profiles")--please add that to the todo list too.</div><div>Also, it's my impression that the solver takes longer than it used to. Could it be that the binning isn't being honored?</div><div>Perhaps you derived your speed by threading, and I'm defeating that by unchecking the box?</div><div>...</div><div><br></div><div>Here's the backtrace, as it crashed again--this time in GDB.</div><div><br></div><div>I guess I'm done testing for the night.</div><div>Hy</div><div><br></div><div> log-odds ratio 0.335153 (1.39815), 0 match, 0 conflict, 0 distractors, 39 index.<br> RA,Dec = (318.284,63.9039), pixel scale 3.84851 arcsec/pix.<br> log-odds ratio 0.335153 (1.39815), 0 match, 0 conflict, 0 distractors, 39 index.<br> RA,Dec = (318.284,63.9039), pixel scale 3.84851 arcsec/pix.<br> log-odds ratio 34.6274 (1.09262e+15), 18 match, 0 conflict, 120 distractors, 37 index.<br> RA,Dec = (325.282,58.0472), pixel scale 3.97646 arcsec/pix.<br> Hit/miss: Hit/miss: ----+-----------+--+--+------+---------------+---+------+----+--+--+---------------+-----------+----<br>[Thread 0x83925090 (LWP 1384) exited]<br><br>Thread 38 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.<br>[Switching to Thread 0x92c2c090 (LWP 31265)]<br>belong (corenb=corenb@entry=0, coreobjlist=coreobjlist@entry=0xb42b9afc <debobjlist>, shellnb=shellnb@entry=0, <br> shellobjlist=0x47d6cbc) at /home/pi/Projects/stellarsolver/stellarsolver/sep/deblend.c:378<br>378 int xc=PLIST(cpl+cobj->firstpix,x), yc=PLIST(cpl+cobj->firstpix,y);<br>(gdb) bt<br>#0 belong (corenb=corenb@entry=0, coreobjlist=coreobjlist@entry=0xb42b9afc <debobjlist>, <br> shellnb=shellnb@entry=0, shellobjlist=0x47d6cbc)<br> at /home/pi/Projects/stellarsolver/stellarsolver/sep/deblend.c:378<br>#1 0xb4217178 in deblend (objlistin=0xa8cb2b00, objlistin@entry=0x92c2b1c4, l=l@entry=0, objlistout=0x0, <br> objlistout@entry=0x92c2b0c4, deblend_nthresh=75328520, deblend_nthresh@entry=0, <br> deblend_mincont=0.0050000000000000001, minarea=minarea@entry=5)<br> at /home/pi/Projects/stellarsolver/stellarsolver/sep/deblend.c:125<br>#2 0xb4217b4c in sortit (info=info@entry=0xa8cc52b0, objlist=0x92c2b1c4, objlist@entry=0x92c2b1bc, minarea=5, <br> minarea@entry=2, finalobjlist=0xa8c296d8, finalobjlist@entry=0x0, deblend_nthresh=32, <br> deblend_nthresh@entry=3, deblend_mincont=0.0050000000000000001, gain=1)<br> at /home/pi/Projects/stellarsolver/stellarsolver/sep/extract.c:777<br>#3 0xb4219e80 in sep_extract (image=0x5b8d6c <NewFOV::slotDetectFromINDI()+324>, image@entry=0x8ecf2008, <br> thresh=thresh@entry=54.3094788, thresh_type=thresh_type@entry=1, minarea=2, minarea@entry=5, <br> conv=0xa8cc7100, convw=<optimized out>, convw@entry=3, convh=convh@entry=3, filter_type=<optimized out>, <br> filter_type@entry=0, deblend_nthresh=32, deblend_cont=0.0050000000000000001, clean_flag=1, clean_param=1, <br> catalog=0x92c2b514, catalog@entry=0x92c2b50c)<br> at /home/pi/Projects/stellarsolver/stellarsolver/sep/extract.c:632<br>#4 0xb41edc34 in InternalSextractorSolver::runSEPSextractor (this=this@entry=0xa8cb9e70)<br> at /usr/include/c++/8/cmath:475<br>#5 0xb41eed90 in InternalSextractorSolver::sextract (this=0xa8cb9e70)<br> at /home/pi/Projects/stellarsolver/stellarsolver/internalsextractorsolver.cpp:94<br>#6 InternalSextractorSolver::run (this=0xa8cb9e70)<br> at /home/pi/Projects/stellarsolver/stellarsolver/internalsextractorsolver.cpp:137<br>#7 0xb420ddd4 in StellarSolver::extract (this=0x9e403bd0, calculateHFR=calculateHFR@entry=true, frame=...)<br> at /usr/include/c++/8/bits/atomic_base.h:390<br>#8 0x00c4c4c8 in FITSSEPDetector::findSourcesAndBackground (this=0x92c2b89c, boundary=..., bg=bg@entry=0x0)<br> at /usr/include/arm-linux-gnueabihf/qt5/QtCore/qrect.h:60<br>#9 0x00c4a32c in QtConcurrent::StoredMemberFunctionPointerCall2<bool, FITSSEPDetector, QRect const&, QRect, SkyBackground*, decltype(nullptr)>::runFunctor() (this=0x424be80)<br> at /usr/include/arm-linux-gnueabihf/qt5/QtConcurrent/qtconcurrentstoredfunctioncall.h:911<br>#10 0x004df0f0 in QtConcurrent::RunFunctionTask<bool>::run (this=0x424be80)<br> at /usr/include/arm-linux-gnueabihf/qt5/QtCore/qmutex.h:240<br>#11 0xb4855f30 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5<br>#12 0xb485eb58 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5<br>#13 0xb42c2494 in start_thread (arg=0x92c2c090) at pthread_create.c:486<br>#14 0xb397c578 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 from /lib/arm-linux-gnueabihf/libc.so.6<br>Backtrace stopped: previous frame identical to this frame (corrupt stack?)<br>(gdb) <br></div><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 15, 2020 at 9:36 PM Hy Murveit <<a href="mailto:murveit@gmail.com" rel="noreferrer" target="_blank">murveit@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">OK, you knew this would happen 10 minutes after I sent that...<div><br></div><div> log-odds ratio 0.69992 (2.01359), 0 match, 0 conflict, 0 distractors, 17 index.<br> RA,Dec = (309.748,70.6162), pixel scale 4.38547 arcsec/pix.<br> log-odds ratio 0.69992 (2.01359), 0 match, 0 conflict, 0 distractors, 17 index.<br> RA,Dec = (309.748,70.6162), pixel scale 4.38547 arcsec/pix.<br> log-odds ratio 6.76328 (865.472), 0 match, 0 conflict, 0 distractors, 14 index.<br> RA,Dec = (327.788,50.727), pixel scale 4.50653 arcsec/pix.<br> log-odds ratio 6.76328 (865.472), 0 match, 0 conflict, 0 distractors, 14 index.<br> RA,Dec = (327.788,50.727), pixel scale 4.50653 arcsec/pix.<br> log-odds ratio 53.7431 (2.18938e+23), 18 match, 0 conflict, 100 distractors, 37 index.<br> RA,Dec = (325.28,58.0466), pixel scale 3.97665 arcsec/pix.<br> Hit/miss: Hit/miss: +------+----+--------++------------+-+---+-----+--------++--+-----------------++--------------+-----<br>Segmentation fault<br><br></div><div><br></div><div>It's hard to say what caused it, but if I had to guess, I'd say it was run out of memory.</div><div>It happened during a meridian flip, and perhaps StellarSolver is too greedy with memory.</div><div>I'll uncheck that load all indexes flag and continue.</div><div><br></div><div>Hy</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 15, 2020 at 9:23 PM Hy Murveit <<a href="mailto:murveit@gmail.com" rel="noreferrer" target="_blank">murveit@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Some good news.<br><div><br></div><div>Tonight, for the first time, I was able to start up the latest (built from latest source as of an hour before I wrote this) KStars and StellarSolver on my RPi4, without issues (so far).</div><div>I've polar aligned, plate solved, focused, guiding, ... and so far all good. I have never been able to get to this point with this new software, so there's definitely been progress.</div><div><br></div><div>Still need to bang on it for several nights, I'm sure, but thanks for the hard work!</div><div><br></div><div>FWIW, I am not using any of the safeguards I was asked to put in (e.g. I have "Use Scale" and "Load All Indexes In Memory" both checked).</div><div><br></div><div>Hy</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 14, 2020 at 12:35 PM Hy Murveit <<a href="mailto:murveit@gmail.com" rel="noreferrer" target="_blank">murveit@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Rob,<br><div><br></div><div>Thanks for your hard work on this!</div><div><br></div><div>As we discussed privately, I have been unable to get plate-solving to work with the internal StellarSolver on my RPi4.</div><div>Do you think this is unique to me--that is, have others been able to do so? If this a general problem, then I think Oct 22 is too aggressive a release target, as we should give our advanced users at least a few weeks of using the software more-or-less successfully on their target environments. If this is something specific to me, but others are successfully plate-solving on RPi's, then perhaps I'm over-reacting.</div><div><br></div><div>FWIW, I just tried to send the full bug report I sent you out to this devel list, but it got blocked (I guess one of my screenshots was too large).</div><div>Hopefully the moderator will accept my thread soon, and it will be available to all. </div><div><br></div><div>Until that happens, where should we post bugs related to 3.5.0? This thread? New threads on kstars-devel?</div><div><br></div><div>Again, I want to emphasize that this is a huge undertaking and I really appreciate the effort,</div><div>Hy</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 14, 2020 at 5:47 AM Robert Lancaster <<a href="mailto:rlancaste@gmail.com" rel="noreferrer" target="_blank">rlancaste@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey guys, <br>
<br>
I also agree 100%, we are not ready by Oct. 15th. There are still several loose ends that need to be tied up on my end, as well as writing up documentation for how to use StellarSolver. Since it is a major release of KStars (3.5.0 vs 4.4.4), I think major changes in the UI and the functions are perfectly fine, but I agree we don’t want to change everything on the user without warning, so we need time to write up documentation and make sure everything is clear and simple for the user to use. So please let me know what is confusing so that we can try to improve that. As for your suggestion that we allow the old code to work during a transition period, the issue with that is that the old code is not compatible really. But that doesn’t mean that we couldn’t make the UI in the Align module *LOOK* like it used to with the combo boxes in align. I put the options for which source extraction method, which solving method, and which profile to use inside the Options dialog because I thought people would access them less often than the other settings in the align module and I also want those to be available if we plate solve in other places in KStars. But we could also put those same options at the bottom in the align module as well, which would make it look close to what it used to look like. There is no reason they couldn’t be in both places. It might lead to a better transition.<br>
<br>
On that note I also agree that we weren’t really ready to put all this in KStars master right away, especially because people rely on the master branch of the repo for nightly builds, and we needed to test it thoroughly before integrating it. I was hoping for more of a testing time period where people could test this on my fork or maybe in a different branch in the main repo and we could have a nice discussion about how to improve it before putting it in the official KStars Master repo. But, let's not be too hard on Jasem for that, he is a great guy and works incredibly hard to support KStars and INDI and us. It has caused a little more pressure on me to fix all these problems and get it all integrated, and maybe that was a good thing, because I had mostly finished StellarSolver back in June, and I was not integrating it into KStars very fast at all. This has pretty much lit a fire under me to get it done. We already did complain to him about putting it in the main repo so quickly, but it really has worked to get things up and running. So instead of focusing on that, now that its done, let's work really hard to polish everything up and get it ready for release. I think we could be on track for a Oct 22nd release. Please keep testing and I will keep trying to perfect things with StellarSolver and its integration with KStars for the release. And I am sorry if the integration has caused anybody any issues because it wasn’t ready yet.<br>
<br>
Thank you very much,<br>
<br>
Rob</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</div></blockquote></div><br></div></blockquote></div>
</blockquote></div>