Yawcam

It appears that, at least, the {date} variable is only replaced for the first instance in a path name.

Filename = c:\motion\{date}\{date}-{stamp}.jpg would return c:\motion\2007-04-16\{date}-21.17.30.jpg

I have a schedule task that creates new directories at midnight each night. Having the date also in the filename would be of major benefit

I have only tested the {date} variable, but am sure its probably the same for all substitution variables.

{tstampMS} variable is not available when saving files on a schedule. See: Settings -> Output -> File.

C:\motion\{date}\{dateY}-{dateM}-{dateD}_{tstamp}_{tstampMS}.jpg returns C:\motion\2007-04-16\2007-04-16_17:55:17_{tstampMS}.jpg

Note: Need to do dateY, dateM, dateD because of previous variable substitution bug outlined above !

{tstampMS} substitution works ok on motion detection file names.

I have fixed so that the variables are parsed more than in the first occurrence now. If the folder doesn't exist it will be created.

This fix will be included in the next beta version.

Regarding your question about {tstampMS} in the FILE output:
Do you really want to include the milliseconds in the filename when the minimum save interval for this output is 1 second?
Regardless of the answer it could be implemented...

/malun

Thanks

I understand what you are saying with the minimum time interval of 1 seconds making the {tstampMS} of little benefit.

Its more for consistentcy of filenames, thats all.

I'll leave the implementation call to you. Its not a critical issue from my end.

I'm extremely happy with the product you have provided.

Rgs
Peter

zebra300760 wrote:Its more for consistentcy of filenames, thats all.

That's a reason good enough for me...

By the way, the "create folder if it doesn't exist feature" doesn't work for ftp-upload at the moment. I'll see if I can fix that later.

/malun