PVRX2 wont start when Archiving in progress?

[fla]

Thanks for the tip. I just tried it and .net terminates background threads on application exit which then causes partial/corrupt XRecord archives so I went back to foreground threads. Sorry jksmurf but I'm out of ideas on this one. Why not minimize pvrx2 instead of exiting? Don't know if there's already an API where pvrx2 asks plugins if they're busy? Perhaps a warning at gbpvr exit saying plugin xyz is busy, do you want to exit anyway and possibly lose data?

[jksmurf]

Sorry jksmurf but I'm out of ideas on this one. ....Perhaps a warning at gbpvr exit saying plugin xyz is busy, do you want to exit anyway and possibly lose data?

No worries, I guess I just didn't expect to be ABLE to exit, so was surprised when I did, that I couldn't go back in. So a warning would help on that front, for sure.

k.

[sub]

Don't know if there's already an API where pvrx2 asks plugins if they're busy? Perhaps a warning at gbpvr exit saying plugin xyz is busy, do you want to exit anyway and possibly lose data?

No, there is no mechanism like this, and I dont really think its worth adding it for just this one problem. I dont like fiddle with the way the application interacts with plugins - from past experience I know just how likely changes in this area are to break other plugins.

You're probably better to run something out of process to perform the actual archiving, then just have your plugin communicate with it. That way it wouldnt matter if the app exits while your lengthy archiving process is in underway. Also minimize the duration of any database activities so that you dont create locks that interfere with the other things. For example, if you're moving recordings to another drive, get a list of them up front (few milliseconds, to read then release the database), then for each file do the copy, then a quick update the database (again a few milliseconds), then delete the original. This is only a guess of what you're doing though.

[fla]

I understand wanting to keep the plugin API very stable. I don't think rewriting/distributing an archiving executable is worth it for this problem. Sounds like you'll have to be careful not to exit jksmurf.