Don't split the stream based on length if it's about to shut down for the night anyway.

tfabris / CrowCam

A set of Bash scripts to control and maintain a YouTube live cam from a Synology NAS.

GNU General Public License v3.0

3 stars 3 forks source link

Don't split the stream based on length if it's about to shut down for the night anyway. #47

Closed tfabris closed 5 years ago

tfabris commented 5 years ago

There is code in place to split the video stream up into manageable segments, as described in issue #44. At the current time, the code is designed to split the stream if it exceeds X hours in running length, where X is configurable.

Consider changing the code to skip the split if the "end of day" shutdown is approaching:

At the point in the code where it is about to split the stream due to exceeding X hours in length...
Check to see if the "end of day" time is coming up soon anyway.
("coming up soon" would be a configurable grace period, defined in seconds.)
Perform the check by looking to see if the "end of day" seconds, minus the grace period seconds, is less than the current clocktime seconds.
If so, then log a debug message and don't bother to do the split.

tfabris commented 5 years ago

Fixed with the latest commit.

To do:

Put this into production and check the logs to make sure it looks like it's working.

Note: Modified the maxlength so that this has a chance to happen:

Current Earth axis: CrowCam Controller - Will start the stream at about 18360 05:06. CrowCam Controller - Will stop it for the night at 76920 21:22.

With original setting of 6hr maxlength and 1hr grace: 5:06 start 11:06 restart (~6hr segment) 17:06 restart (~6hr segment) 21:22 end (~4:16 segment)

Changed to 7:40 hr (27600 seconds) maxlength and 1hr grace: 5:06 start 12:46 restart (~7:40 hr segment) 20:26 restart (~7:40 hr segment) 21:22 end (~0:56 segment)

tfabris commented 5 years ago

I've put the changes into production. Now, to wait for a day in which the network never goes down (it's been bad the last couple days) and YouTube doesn't glitch (heh) and we'll see if the code works. Can close this bug once I've seen the correct messages in the log file and the correct lengths in the video stream segments.

tfabris commented 5 years ago

One of the messages I was looking for in the log, the "Within grace period" message, was a debug-only message, so I never actually saw it in the log. However, the behavior on 2019-07-09 was correct:

First segment of the day was 7:20 in length. It was stopped due to videoIngestionFasterThanRealtime at 12:44 pm.
Second segment was only about 6 minutes long, it was bounced due to videoIngestionFasterThanRealtime at 12:53 pm.
Third segment ran for 8:31 until EOD at 9:26 pm.

This is the correct behavior so I'm closing the bug as Fixed.