This feature adds the possibility to set the original recording date when uploading video, for more lisibility for viewers.
It should fix #50
I am not sure looking for the modification date is a sane default for the general case: A user may shoot its video one day and edit it another day. I am not confident the last edit date is "better" than the shoot date. But if the video was shot across multiples day, which file and which date is best here ?
Ok, I read the issue, I am not sure which defalt is best between the file modification and nothing. Do you know how this is presented in both Youtube and Peertube ? I am interested by the wording they are using.
Unfortunately, getting "creation" date for a file is really difficult depending the OS, and we cannot know if a file have been copy/pasted before, thus its creation date is also inexact.
Ideally, I wanted to get the recording date from metadata, but this information is missing in most .mp4 files.
So the only "automatic" information available are modification date of the file, and last opening date. Modification seems the best alternative.
Youtube presents it exactly as Original Recording date (also allowing to set the Original recording location in UI, but not in API)
Original Recording date
Original recording location
Peertube is slightly different as it's the Original publish date, and it's for example used when downloading video from Youtube using a youtube link in Peertube, it's filled with the date of Youtube publication.
Original publish date
But for simultaneous upload as we do in prismedia, this fields seems relevant to me.
Do you think something like that could be better?
I am a big lover of default options to avoid the need to configure everything, but I know it's bias of myself so I am open to discussion ^^
I know for both of us the no option meaning a value is set is good. But thinking about someone who shoot on Monday, do the edit on Wednsday and upload on Friday (for example) may prefer to set the record date.
Especially if the subject of the video is news related. Like for the recent american election. I feel like "Nothing" is a better default. And you can just set an "auto-original-date" on your NFO ;)
You have a good point here indeed!
I'll change the default, and add the --auto-originalDate option.
Also, I'll add a strict option for that (--withOriginalDate) to avoid mistake in the same schema that other strict option, as we have it for publishDate for example.
Does it makes sens for you?
We are starting to have a lot of options here, we may think about only including important one / some important example. The list is already present if we ask for help so as long as this is explain, I do not see a lot of value to keep both.
Indeed, the Readme begins to be very long, you are true.
I'll try to select some specific option that are not easy to understand and focus on them :)
This is a copy past of validatePublishDate. Maybe just use one named validateDate or something like that.
I have thought about that, but it's not exactly a copy/paste as there is a difference: publish date should be in the future, while original is in the past ^^"
I have found no satifying way to do that with one function, as in this scope we only have the parameter value as a date, and no its name. So we have no way to know if this is a publish or original date, but if you have any idea, I would be happy to reduce the code!
Ah right, I missed that :s
Is it possible to pass an argument ? To tell before/after present date ? Or maybe the validation being a call to valid date and a call to before/after present.
But if this is too hard nevermind.
I found no easy way to pass arguments, I think something is possible with handler instead of validate function, as we do for strict options, but it's more complex...
I'll keep this in memory if we change the docopt/schema system one day, some other help/doc libraries may be better for that.
The function is already too long and this is the same as for the publish date, call a function to format a date and add it to the fileds here. (For here and the publish date)
You are sooo true, and so hard with my lazyness xD
I'll update it :p
This fells strange. But I am not sure that creating the structure would be better. Especially if/when we will add another field in this struct.
I am not a big fan to add the "recordingDetails" empty, but it does not broke the upload if it's empty, and I found no easy way to add this later because of the dictionnary of dictionnary structure (probably missed something here though, it should be possible somewhat)
As you said, it seems easier to create the structure directly, so it's available for latter use.
Is it ok for you?
Yes we can keep it. Maybe adding a comment in it saying that (not break upload and easier if we end up with multiples optionals fields).
No due date set.
This pull request currently doesn't have any dependencies.
Deleting a branch is permanent. It CANNOT be undone. Continue?