shorten the live ingest stability delay

[adrianlambert]

wondering if it could be possible to reduce the live ingest delay? Or even just monitor and more quickly refresh for now files in a specific directory. The 10 second limit is pretty tardy compared to other solutions.

[Kirk Baker]

wondering if it could be possible to reduce the live ingest delay? Or even just monitor and more quickly refresh for now files in a specific directory. The 10 second limit is pretty tardy compared to other solutions.

After the first file is ingested, there should be no delay if other files arrive in the interim.  Copying an incomplete file would be disastrous, and some file formats we are unable to determine their length from their initial information provided in the header of the file.  So we have to wait until the files 'settle'.

-Kirk

[adrianlambert]

After the first file is ingested, there should be no delay if other files arrive in the interim.

Sorry but can you clarify. Are you saying that PM drops the delay after the first file in the live ingest session or that additional files don't delay the arrival of the first file and that all files are subject to the delay?
If it's the latter could PM set a trigger to live ingest a file based on the size of the first file (probably would want to check that the first frame isn't a black frame - flash didn't fire). So, say the first file is ~27MB, PM moves subsequent files when they have had enough time to deliver say 50MB or some other reasonable amount of data from the time of detection. Would that speed it up?

Copying an incomplete file would be disastrous

True. I suffer these disasters on a regular basis due to Capture One Pro and Canon utilities dropping the camera connection. I've found a much more reliable bit of tethering software, but would like to maintain at least some of the promptness of it's less reliable cousins.

[Kirk Baker]

After the first file is ingested, there should be no delay if other files arrive in the interim.

Sorry but can you clarify. Are you saying that PM drops the delay after the first file in the live ingest session or that additional files don't delay the arrival of the first file and that all files are subject to the delay?
If it's the latter could PM set a trigger to live ingest a file based on the size of the first file (probably would want to check that the first frame isn't a black frame - flash didn't fire). So, say the first file is ~27MB, PM moves subsequent files when they have had enough time to deliver say 50MB or some other reasonable amount of data from the time of detection. Would that speed it up?

Sure, that would speed it up, but it would also likely corrupt images.

It really doesn't get any better than what we're doing unless we can find a way to tell instantly when a file is complete.  For JPEGs, we can tell when the entire file has arrived.  For RAW files, we have to wait for the file to not change for a while.

-Kirk

[adrianlambert]

OK, lucky last. I assume you are working to some performance assumptions. Would an "unreccomended" delay period be possible so as to allow users to find their own optimum settling period for their particular hardware?