Background Worker stops (BYEOS 3.1.18 Prem)

[astro@nangreaves.net]

Howdy campers,
I have a problem with the background worker stopping (for no reason I can determine).  

While I don't think I have lost any captured data, I have had some images not renamed and many jpg-to-avi conversions fail (I do use my EOS 100D for planetary sometimes, instead of reconfiguring cameras).  I can usually rename the image files, but ending up with 5000 .jpg files instead of 1 .avi is quite inconvenient.

The only clue I have found is that it usually happens if the camera accidentally disconnects or is intentionally disconnected while files are in the queue, though it happens when everything appears to be going well.  Data collections works fine, but the background process just stop sometimes.  It also happens if my disk gets too full during an imaging run (my bad).

The processes remain active in task manager, usually using memory and CPU resources as if it's running, but nothing happens - and I have left the computer running for days just to see if it catches up.
Closing BYEOS and reopening it will let it work properly again, but only on the subsequent data; the data already captured remains in the BYEOStemp/download folder unprocessed.

3 lines of resolution I am interested in:
1.  Stop it from happening altogether.  
2.  Re-starting it so it will finish the job(s).  It's not a terminal problem, but certainly a time-consuming inconvenience.
3.  Manually starting the processes, particularly to convert jpeg collections to AVI files.

Any help appreciated.

Thanks,

John

[admin]

The background worker is automatic, if you kill it in task manager, BYE main process should start a new one when needed... but the current pending job won't run again.

[admin]

19 minutes ago, astro@nangreaves.net said:

The only clue I have found is that it usually happens if the camera accidentally disconnects or is intentionally disconnected while files are in the queue, though it happens when everything appears to be going well.  Data collections works fine, but the background process just stop sometimes.  It also happens if my disk gets too full during an imaging run (my bad).

 

That is an excellent clue... and your issue. 

The background worker is a secondary/child/slave process of the main BYE process... it does nothing except waiting for push/pull commands form the main BYE process. If your camera disconnects unintentionally from BYE (dead battery, something going to sleep like USB or HD) then BYE may no longer be able to push/pull commands from the background worker process. 

Everything is working as intended but there are limitations, your camera must *not* disconnect unintentionally.  Intentionally disconnect using the BYE connect/disconnect button should have no effect because BYE knows that it is disconnected and can terminate all BYE internal camera command loops... leaving the background worker command push/pull in working order.

[astro@nangreaves.net]

Thanks, a perfectly reasonable (and somewhat anticipated) answer.  

As a follow-up, is there anything I can do to kick the process into continuing or starting again?
The two most annoying things are image files not being renamed and moved from the download folder to the destination folder; and planetary videos not being created from the collection of jpegs.  It looks like the logs know much of what was done, I'd even be happy if I could use a batch file to finish the job(s).

P.S. Additional information FYI: 

• Camera crash was due to a power drop caused by the dome motor jamming.  I am putting a battery in the power source so everything on the OTA runs on 12vdc (everything below the OTA already does).
• HDD overflow problem was a 2-fold mistake on my part: I was capturing video and forgot to account for the 2x space needed for conversion from jpg to avi; and my cloud sync was slower than my data collection rate.  SSD filled up, bad things happened ended up with thousands of zero-length JPG files. 

Thanks Much!
John

[astro@nangreaves.net]

Thanks - good to know.  I will check out alternative crash recovery options.
Not as big as a problem as I thought as the majority of the files in question are zero-length (some sort of write-error I assume to be related to the disk-full problem).

Please mark as resolved.

Clear Skies,

John