BackyardWorker Log File in incorrect folder

[astroman133 687]

I am testing BYE 3.1.6 with my T5i and had a problem that led me to look for the log files. 

 

My preferred configuration has all the BYE folder paths set to be under D:\Pictures\BackyardEOS.  So the log files should be under D:\Pictures\BackyardEOS\BackyardTEMP\Logs.  The Backyard Worker log file was found under the default location of C:\Users\<username>\Pictures\BackyardTEMP\Logs. So to be clear, the main log file and the background worker log file were not created in the same directory.

 

The problem that I was troubleshooting was that the .AVI file was not being created unless I ran as Administrator.  I traced it down to the fact that I had a copy of VirtualDub in the Download folder.  It was apparently there from a previous version of BYE.  I deleted it and observed the expected behavior, so no problem once I removed Virtual Dub.

 

 

[admin 393]

Yes this is a known issue... and a bit complicated to fix oddly.  The background worker is unaware of the user setting at start up and this is why this bug is a bit add to fix/address.

[astroman133 687]

Can BYE launch the Background Worker with the log folder path as a command line argument?

[admin 393]

I don't think so.  I'm using log4net and I don't believe it allows that... but I'm not sure.  I would have to check.

[admin 393]

ummm, actually this may solve it.

 

http://stackoverflow.com/questions/571876/best-way-to-dynamically-set-an-appender-file-path

[astroman133 687]

I am not familiar with log4net, so I will leave it to you. It will be good to get fixed.

[PoppaChris 13]

I thought we needed Virtual Dub to prevent the Backyard Worker from locking up BYE when the number of AVIs to be compiled and downloaded to the PC grew past 1 or 2 files.  Is this still true?

[astroman133 687]

I don't believe that this is still the case.

[admin 393]

I thought we needed Virtual Dub to prevent the Backyard Worker from locking up BYE when the number of AVIs to be compiled and downloaded to the PC grew past 1 or 2 files.  Is this still true?

 

That was never true.  

[PoppaChris 13]

Really?  I distinctly remember your advice to add Virtual Dub to the BackYardTEMP folder because you had licensing issues and couldn't add it to BYE (or some similar situation). 

It's inclusion certainly helped the lock-ups I used to have. 

 

Search your previous threads to look for this issue.  I'll do the same and we can refresh our memories.

[PoppaChris 13]

Really?  I distinctly remember your advice to add Virtual Dub to the BackYardTEMP folder because you had licensing issues and couldn't add it to BYE (or some similar situation). 

It's inclusion certainly helped the lock-ups I used to have. 

 

Search your previous threads to look for this issue.  I'll do the same and we can refresh our memories.

 

Found it!

 

www.otelescope.com/index.php?/topic/213-how-to-use-virtualdub-to-encode-planetary-avi-movies-automatically/#entry1416

[admin 393]

Really?  I distinctly remember your advice to add Virtual Dub to the BackYardTEMP folder because you had licensing issues and couldn't add it to BYE (or some similar situation). 

It's inclusion certainly helped the lock-ups I used to have. 

 

Search your previous threads to look for this issue.  I'll do the same and we can refresh our memories.

 

I can not add virtual dub in he setup.exe distribution, this is true... but your statement was not that at all.  It was eluding that without virtualdub BYE will lockup if you have more than one item in the queue, this is what was never the case.

 

Anyhow, virtualdub is more efficient at encoding than the native BYE encoder.... and the bye encoder should not lock up.

[astroman133 687]

To reiterate my original post.  VirtualDub would not create the AVI on my Win 7 x64 system unless I ran BYE as Administrator.  I do not have this problem with the native BYE video encoder.

[PoppaChris 13]

I can not add virtual dub in he setup.exe distribution, this is true... but your statement was not that at all.  It was eluding that without virtualdub BYE will lockup if you have more than one item in the queue, this is what was never the case.

 

Anyhow, virtualdub is more efficient at encoding than the native BYE encoder.... and the bye encoder should not lock up.

 

Perhaps I misspoke myself.  It was not my intent to say that the encoder would lock up BYE all the time.  It only happened to me when there several ( 3 or more ) videos waiting in the queue and would force me to reboot my laptop.  I merely meant to say that your previous (and very helpful) advice to use VirtualDub was a great deal of help with this issue.  I have not had a repeat offense since I followed your suggestion.

 

Trust me when I say that I'm a HUGE fan of BYE and only think the very highest of your work in creating it and the superb support you give to it.    

[PoppaChris 13]

To reiterate my original post.  VirtualDub would not create the AVI on my Win 7 x64 system unless I ran BYE as Administrator.  I do not have this problem with the native BYE video encoder.

 

Curious... I was running Win 7 Pro when I had my issues.  I'm now running Win 10 Pro on the same machine.  How is your "busy" time with the native encoder?  Do you need to limit the number of captures waiting in the queue until they clear?  I still try to limit to no more than 3 or 4 before waiting on things to catch up.

[admin 393]

The background worker is a queue.  It processes a single item at time in a FIFO fashion, first in first out.

 

This is true for any process sent to it, being reading the exif data of an image, encoding an avi with virtualdub or the native encoder, reading the weather info for the weather center, etc.  They are all subjected to this FIFO queue.

 

If a single item in the queue blocks then the entire queue is blocked.  However, there is a provision that if a single item goes awol for at least 5 minutes the process will be killed and the background worker will resume processing with the next item in the queue.

 

Regards, 

[PoppaChris 13]

If a single item in the queue blocks then the entire queue is blocked.  However, there is a provision that if a single item goes awol for at least 5 minutes the process will be killed and the background worker will resume processing with the next item in the queue. 

 

The 5 minute rule is something I did not know about.  Sounds like a very good feature.