Investigate if you can leverage "recordingDate" for uploaded videos.

[tfabris]

CrowCam Archives playlist is mostly populated with live videos. Live videos, have this part:

 "liveStreamingDetails": {
    "actualStartTime": datetime,
    "actualEndTime": datetime,

I have stuck a few hand-edited videos into the playlist. Those do not have that part. They have a different part that the first one does not have:

  "recordingDetails": {
    "recordingDate": datetime

Notes:

• When uploading the video, I have to make sure I have entered the accurate recordingDate for this to be useful to me.
• When adding the video to the playlist, I have to make sure that I position it in the correct sequence in the playlist in order for this to be useful to me.
• The "recordingDate" parameter contains only a good date, not a good timestamp. It is forced to 00:00:00.000Z on the date that you specify. So you need to modify the HTML/PHP code that you're using in your side project to handle this.

I can query for both sets at the same time by doing this, and then parsing the results: curlUrl="https://www.googleapis.com/youtube/v3/videos?part=liveStreamingDetails,recordingDetails&id=$oneVideoId&access_token=$accessToken"

See if you can get both working. The trick is that there's no "end time" for the second one, and you need to be able to handle special cases, and handle the caching. Not sure if this is feasible.

Alternative idea: See if there is a way to force-insert the "actualStartTime" and "actualEndTime" into an uploaded video. Then the code doesn't have to change, you just have to edit the video (perhaps with a side piece of new code). (Edit: I looked. No, you can't update those values, you can only update recordingDate.)

[tfabris]

I am in-process now, with checking in code, which addresses this. It works in my localhost tests.

The code works like this:

• If actualStartTime is not found
• Then the timestamp caching feature will use the recordingDate in place of the actualStartTime instead, and leave the actualEndTime blank.
• The code which consumes this information in the secondary project (html/php code) will detect the special case situation of a missing actualEndTime.
• In that situation it will compensate for the recordingDate being a zero-timestamp, and will print the date only, not the time.

To do:

• Check the following situation, commented in the code in CrowCamHelperFunctions, check what happens and then update the code comment and/or code behavior accordingly:

     # TODO: confirm if this state occurs for the channel's main online
      # live stream, for example, I wonder if an online live stream has
      # an actualStartTime but doesn't yet contain an actualEndTime, or
      # if they are both blank until the live stream finishes.

• If that's all working as expected, then get this code into the production server.

[tfabris]

I think the code as-checked-in will have a bug if run in production.

The way it caches the time stamps, if it caches a “live in-progress” livestream, then it will be caching a start time with no end time. Then, when the live stream is done and it gets an end time, the cache won’t be re-updated because it contains a value in that slot. The video will be destined to never register as having an end time in the cache.

Solution will be to always recheck for an end time if the start time doesn’t look like a recordingDate value. (recordingDate values look like a good date but time stamp of 0Zulu).

This solution will have a drawback, which is that, if a video livestream in-progress comes along, which really did start at 0Zulu (about 4pm pst during winter), then the cache won’t get refreshed for that item and it’ll be stuck. Consider if this is a rare enough problem. Consider always re-querying items with no actualEndTime at the cost of some quota.

[tfabris]

Idea: if there is a real live-in-progress video that really started at 0Zulu, then it’s end time will be updated within 24 hours. So if you want to requery the 0Zulu entries, only do so for entries which are less than 24h old.

[tfabris]

Checked in:

• Cache entries without an actualEndTime will be refreshed, as long as they're not 0Zulu.

To do:

• Cache entries without an actualEndTime, which are 0Zulu, need to be refreshed if their date is less than 24 hours old.
• To do this, you need to do the following:
  • In CrowCamCleanup.sh, there is a bunch of crappy date-comparison code which jumps through a bunch of cross-platform compatibility hoops because "date" function on the mac is different than "date" function on linux.
  • You need to take that crappy code and abstract it into a helper function in CrowCamHelperFunctions.sh.
  • Once that comparison code has been abstracted, then it will be a single function call from both the cache invalidator and the cleanup function.

[tfabris]

Code is checked in which should theoretically fully address all remaining issues.

To do:

• Test this in production and watch its behavior over time.