Preserve file creation meta data on the file itself

[ktiedt]

Description Currently, if you download your media using xbox2local, all files will be named for their creation timestamp, but all have essentially the same file creation date history on the OS... It is possible to modify these values using python, it would be a nice bonus if xbox2local could preserve this data in a way that keeps your media sorted based on when it was actually created (outside of the file name), which would enable OS level file searching, filtering, to be usable then as well for managing backups.

Can you help develop and maintain this feature? Maybe - Python isn't my primary language, so I am having to relearn things trying to make this work, if I solve it, I will absolutely create a pull request, but right now, I am about 0 / 5 on attempts at anything that doesn't throw new errors.

[ktiedt]

I have a working example (no feature or CLI flag -- its just enabled full time -- honestly I dont see a reason to not use it for data accuracy). Will clean it up for a PR and wait to discuss?

[jdaymude]

Hi @ktiedt! Sorry for the slow response. My day job keeps me very busy and I only get to work on random projects sporadically. I completely agree that storing the metadata pulled from the API calls is a good idea and I can give that some thought. Thanks for taking a first stab at it with #23.

One note: your screenshot/clip filenames should reflect the capture date/time—which is the time the screenshot or clip was recorded on your Xbox as reported by the API call—not the time that the file was written to your local device.

[jdaymude]

Now that I'm looking into this more carefully, could you describe exactly what you're hoping the filenames will look like after this change? For example, I have the following rows in my history.csv file (spacing added for readability):

id,                                   game,                           type,       capture_dt,          download_dt,         xboxnetwork, width,  height, sdr_filesize, hdr_filesize
9fd619e2-2b6b-4820-a4a0-a67a2f5201f9, Assassin's Creed IV Black Flag, screenshot, 2015-09-06T07-38-59, 2023-01-02T22-48-23, True,        1920.0, 1080.0, 3696843,      0
0b6e1fbc-881f-404c-b2fc-34eed3d6f95f, Batman™ Arkham Knight,          gameclip,   2021-02-26T04-39-11, 2023-01-02T23-02-06, False,       1920.0, 1080.0, 103053018,    0

The corresponding files on my filesystem are: Assassin's Creed IV Black Flag/2015-09-06T07-38-59.png and Batman™ Arkham Knight/2021-02-26T04-39-11.mp4, respectively, following the capture_dt variable as expected. What would you prefer these filenames look like? And what extra information would you want stored in the history.csv file that isn't there yet?

[ktiedt]

Sorry if I didn't describe it well. My goal wasn't to modify the file name or the meta data file but to modify the files creation dates to enable file system sorting and searching features to work.

I am syncing my clips to google photos and without this change all clips get synchronized with the same date which is the download time (so essentially all identical). With this update, they get assigned to their original date that they were taken (at least on OSX - admittedly I didn't think to test on any other OS).

[jdaymude]

Ah! Thanks for explaining this again—I get it now: you would like the OS creation date to reflect the capture_dt variable. I can definitely take care of this; give me a day or two and I'll have something official pushed to #23 and merged into dev.

[ktiedt]

Thanks! The PR does achieve it, most definitely a better way I imagine, but I've been running this since it made the PR and it hasn't failed yet.

[jdaymude]

Right, I'll build off of what you've done in the PR and see if I can get a simpler but correct implementation.

[ktiedt]

@jdaymude Looking at the results from this code today, it does not appear to be working correctly. In the screenshot here you can see there are now dates from in the future which were taken today. I also was not creating clips at 1am... Is there a timezone issue not being taken into account from the API maybe?

[Edit: Added better screenshot to show the time does appear to be failing due to timezone issues, the times are being set to the filename time, not the creation time it seems. --]