Add date-based naming scheme for DVR files and add video metadata

[Master92]

This PR allows users with an active RTC to chose between the conventional naming scheme (i.e. hdz_000, hdz_001 etc.) and a date-based one (i.e. 2023-11-24T13_34_37).
When no rtc battery is present, the user can not change the naming scheme. On top of that, it automatically falls back to the conventional scheme as default.

Further, I added some metadata to the DVR files i.e. a title (currently the file name) and - for mp4 - the date it was created.
Over the course of my research and the implementation, I found out that the ts container does not support any metadata information about the media creation date, hence a note in the sources.

Closes #42
Closes #116

[SumolX]

I was playing with this feature on the emulator and noticed I'm unable to change the Naming Scheme option because there is no RTC battery installed on the Emulator. Do you think this option should be disabled in a similar fashion to your other PR, if no RTC battery is present then the row is not selectable and has a darker shade?

Perhaps mark the PR as a draft until the other PR has been merged, that way it follows the standard you have set forth. Besides that I think this is great and much more intuitive, especially if a user enables the Date/Time in the Live View... gives them an idea of when they flew.

Actually I could see us temporary blinking the Date/Time in live view when the recording is started.... that way we don't need to have it on permanently.... but that would potentially be a future feature.

Final comment... though its more of a personal preference.... i think we should simplify the timestamp convention to something a little more readable perhaps...

2023-11-24T13_34_37.mp4
to
20231124_133437.mp4

[Master92]

I was playing with this feature on the emulator and noticed I'm unable to change the Naming Scheme option because there is no RTC battery installed on the Emulator. Do you think this option should be disabled in a similar fashion to your other PR, if no RTC battery is present then the row is not selectable and has a darker shade?

You're right. I already had that in mind but wasn't sure how to correctly go ahead and mark this PR to lack some work after #369. I'll convert this PR to draft in a minute 👍
Maybe I'll play around a little and try to come up with an RTC mock for emulator builds 😉

Actually I could see us temporary blinking the Date/Time in live view when the recording is started.... that way we don't need to have it on permanently.... but that would potentially be a future feature.

Yeah we should keep that in mind. Perhaps you'd need the user to decide how they want the OSD to behave.

Final comment... though its more of a personal preference.... i think we should simplify the timestamp convention to something a little more readable perhaps...

2023-11-24T13_34_37.mp4 to 20231124_133437.mp4

That's actually a good idea imho. That way you could navigate your files easier by just typing the digits instead of having to add the dashes, too. The only thing I'd change is separating the date from time with a dash instead of an undesrscore like so: 20231124-133437.mp4. What do you think about that?
I came up with the current scheme through Wikiwix's comment in #123.

[SumolX]

I like your dash format better, all keys are in the same row on the keyboard.

[Master92]

That was a pure coincidence, they aren't on my (German) keyboard 😆

[evilC]

Liking it, great!
Any thoughts, however, on #359 ?

[evilC]

It's worth noting that it appears that this PR also changed hot clip naming? (At least I assume it was this PR, I see that mark_video_file changed.)
Previously, if you had no hot clips and hot clipped DVR file hdz_028, it would become hot_hdz_001, but now it becomes hot_hdz_028.
I kind of like it to be honest, it helps you know where the file was in the sequence of DVR files - without the RTC mod, this was impossible to know for sure with the old system.
It also seems that the next clip will be hdz_029 - ie hdz_028 would not get used again, so you would not end up with a hot_hdz_028 and a hdz_028, so even if this was unintentional, I see no real need to change it back to how it was.

[Master92]

That was indeed unintentional 😅

[evilC]

@Master92 If we do intend to keep it as it currently is, then we should probably remove unused code

[Master92]

@evilC agreed. I'm currently working on that file for the date-folder feature and will try to keep removing that in mind 👍

[evilC]

@Master92 I could maybe get rid of it as part of PR #389 ?

[Master92]

@evilC I'd be okay with that as well 😉👍