CroatianMeteorNetwork
StartCapture option to suppress checking GMN for revised platepar & mask
I would like to request an added StartCapture option, -t, which suppresses GMN checking for revised .config, mask or platepar. This option would only be used for short test captures on a .config that is already set to upload: false.
Or, even better, if upload_enabled: false, then suppress checking for revised files, since this would not require a new cmd line option.
Without this capability a test with -d 0.03 spends more time timing out, while waiting for new files, than it does actually running the test capture and processing.
Thanks, Peter E.
Interesting thought. I don't like the idea of skipping the checks for updated files if upload is false, because at least two operators, and multiple stations do not use the standard RMS upload mechanism, and have upload_enabled set to false. I think you are referencing a special case where your private key does not match the public key of the account you are trying to connect to.
Given the problems that might be caused by relying on upload_enabled: false, I think the -t or other char to indicate running in test mode would be the best solution. This would allow test runs to complete without having to wait for comms timeouts when looking for new mask or platepar on GMN.
Just adding a -t or --test flag to disable server connections so you can quickly start and run capture on a station with no keys.
No, I think that's an excellent idea.
Additionally, we currently disable upload by setting upload_enabled to false when station id is XX0001. We could use the same logic for download.
Also, we have a download mask permissive flag to disable downloading mask but there's no equivalent for platepar. Is there a use case for only disabling mask but not pp download. If not a generic download_enabled option could disable both.
I need to think about disabling download when XX0001 is stationID. It sounds like a good idea.
I do a lot of testing using secondary or tertiary streams of IMX-291, where the primary stream uploads to GMN, but the testing streams, lasting all night, or all day and night, do not upload.
In this case it would be best if authentication was also skipped if .config is set to upload_enabled: false
When testing, I need to be able to run the default routines supplied by GMN to be sure that no issues are triggered by other things in the test environment, In this case, adding command line switches is not feasible.
Sorry, I had overlooked the earlier messages that argued against using upload_enabled: false
In my testing case, I'm testing MultiCam, so I can't just set the ID to XX0001. I also rather not introduce a special case where I override a default RMS startup script with one that has a command line option added. These are night long test runs, not short sessions. Although the timeout eventually happens, if you are monitoring the startup live, it can be frustrating to have to deal with repeated wait timeouts when there are delay instances for both mask and then platepar download attempts. Perhaps an alternative would be to detect the first ssh key validation resulting in false, and then set authentication to off for that session?
@peschman
I'm not seeing this getting much traction unfortunately. One workaround could be to set up a local pi to simulate the remote server, with which you do authenticate. You could even set the remote server address as the address of the pi itself.
How about this: test for camera ID starting in XX, XX0 or XX00 rather than just for XX0001? In that case, I could use XX0001, XX0002, XX0003, and other XX000? designations for MultiCam testing.
I prefer the command line switch idea, which is written. You could always check that branch out when you want to do some testing?
Luc has discovered the perfect work around to cancel authentication.
Commenting out the rsa parameter in config eliminates the delay:
; Path to the SSH private key
rsa_private_key: ; ~/.ssh/id_rsa
I will leave it up to you if you want to proceed with the PR for command line arg or not. Thanks for all your time working on this issue.
I will try to close the issue -- when I looked earlier today, I could not find it under open or closed. I will check again tomorrow as it's late evening here now.
On Mon, Jul 21, 2025, 17:40 David Rollinson @.***> wrote:
g7gpr left a comment (CroatianMeteorNetwork/RMS#362) https://github.com/CroatianMeteorNetwork/RMS/issues/362#issuecomment-3099940047
Great, would you be good enough to close this issue?
— Reply to this email directly, view it on GitHub https://github.com/CroatianMeteorNetwork/RMS/issues/362#issuecomment-3099940047, or unsubscribe https://github.com/notifications/unsubscribe-auth/BHMOSBMYDGKAM6JFYD5OOTL3JV26TAVCNFSM6AAAAAB6KD7YV6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOJZHE2DAMBUG4 . You are receiving this because you were mentioned.Message ID: @.***>