Top notch julien! Cheers.

It is indeed a bug, the creation date was incorrectly set in the MIDI archive files -- this will be fixed in the next update !

Thanks to to Pianoteq devs! I can confirm the problem is now cured in the latest release!
Many thanks!

Shaun

It is indeed a bug, the creation date was incorrectly set in the MIDI archive files -- this will be fixed in the next update !

Thanks for the confirmation ! that's saved me from delving deeper  :-)

Shaun

Nice find ShaunHHH, interesting.

Hi Qexl - many thanks for replying to my post - you have added some interesting insights.

>Would be interested to know if any Linux users are having this (re "Unux start of time" convention).
This is something I never thought about - of course Jan 1970 is the Unix epoch, not the MS one...

If I am monitoring mid files in the Everything File Search tool, I can see what's happening when the new mid file is created. The Filecreation date is correct initially and then changes to the Jan 1970 date...

>In my case, it's !harmless! for now on PC where I can control my own access etc..

I'm not sure if it is harmless though - it does look like a bug, so might have unpredictable effects. I know on my system my Onedrive sync was using 15% of the CPU even though it said that it was done with syncing (maybe coincidence).

>Couple of things spring to mind, do you have your archives set to be saved for "a billion years"? (maybe setting that to something else may have different results) but

Yes, I do.Thanks, I'll do some further experimentation

>Note to self and others
> Maybe apply some caution when changing archive settings temporarily - remembering to return them to
>stateful settings you want long-term
Good advice! :-) I've done that myself.

I've been playing around with some scripts recently as I want to set up a script that monitors the archive directory for new files, then brings up a text box so I can write a little note on what I've been doing on the keyboard and then append the note to a running text file. At the moment I've got >15,000 mid files & don't know what are in them... :-)

Best wishes,

Shaun

Would be interested to know if any Linux users are having this (re "Unux start of time" convention).

Hunch is, at the point a user of Pianoteq standalone stops playing their first notes long enough to engage the archive system, code then asks

"What is the creation date of this user performance",

then "touching" the file to copy that to file name like

"2019-10-03 0147 (Tuesday) 1921 notes, 468 seconds.mid"

to do that may be low-level wiping the meta creation date to a "session beginning at Unix start of time" + hour. Each successive saved performance is later in hours - but the first file of a session is 1s. Jan 1970 at user clock time

That issue of creation date timestamps '1970' seems to have a few users of Owncloud pointing out issues (via searching for example "linux 1970 file timestamp").

In my case, it's !harmless! for now on PC where I can control my own access etc.. but maybe it could have consequences if I need to sync to some 'dumb' device in future or attempt copying to a HD with a different file system/OS. Could be annoying to lose these files in such a way.

But, the files are "after" the Unix start of time, so maybe not a huge looming worry.

Since 2017 (when I last setup to archive in a particular way), my archived files have 1970 creation date also. Currently, I'm missing my archives older than that (moved them somewhere in the past - largely discardable - if found though, I'll check them too).

Couple of things spring to mind, do you have your archives set to be saved for "a billion years"? (maybe setting that to something else may have different results) but

1
The file name is the creation date, so we're not technically losing out on info.

2
"modification date" may be used a lot more programmatically - IIRC in the 90s there was a lot of debate about how flaky creation date could be when relied upon in a programming context for fail-safe systems. Maybe it's same/worse now in general? (esp. with more file systems inter-operating on different devices and OS combos).

3
Wondering if setting our archives for saving for a billion years does this, or if other settings also generate the 1970 date. (cannot test right now)

Note to self and others:

Maybe apply some caution when changing archive settings temporarily - remembering to return them to stateful settings you want long-term - and always back the files themselves up before you do make alterations, just in case you overlook something and lose where they are placed (at worst, it may be  lose them, or have to go looking).

I've noticed a problem with the Pianoteq automatically created Midi archive files on my system.
Each of the files created has a "Date Created" attribute showing Jan-1970.
The initial "Date Modified" date is correct

I wondered if this might be a Onedrive problem, but this would seem to not be the case, and files created by other applications are not affected by the issue.
I also have Cantabile on my PC, and when I set this up to auto-record midi files (like Pianoteq standalone) the correct "Date Created" datestamp is made for midi files.

I'm running Pianoteq Stage 64 bit version 6.51./20190523, windows 10 Pro

I've tried the following to see if anything might change (with no difference happening)
* uninstalling and re-installing Pianoteq
* moving archive directory out of Onedrive
* turning off Onedrive sync
* tried PianoTeq versions 6.41 & 6.30
* Tried the 32 bit exes
* ran Pianoteq on a different (Windows 8 Pro PC)

Any thoughts on this issue?
Anyone encountered the same problem?
Have I missed something obvious?

Edit - I've just noticed that if I turn auto-archiving off, make a manual recording and save the midi file, it does get the correct creation datetimestamp... so it appears to only affect the automatically created recording files...

thanks in advance,

Shaun