Midday stream bounce should happen every day, not just in summer.

[tfabris]

The midday stream bounce is a useful tool which makes the video processing time for each days' video become reasonable. I should program the system so that the midday stream bounce happens every day rather than just only on the longest days.

This might be accomplished by changing the number of hours that I allow for the "longest" video. This is a hard coded value in the code. This should be changed to an editable value in crowcam-config and made to be shorter than its current value.

Related to issue #34.

[tfabris]

Code now includes this. Will need to leave it running in production and see how it does. Found an interesting problem, which I have put in as a code comment:

# BUG, potentially livable: This algorithm intends to bounce only at midday,
# but there is a discrepancy between the max length video versus the possible
# number of hours in the day for certain latitudes. The current code issue
# means that after the day's midpoint, there might still be multiple bounces
# if the max stream length is configured to be too short. For example, at the
# height of summer in Seattle, the day can be about 16 hours long, and if I
# add 15 minutes of cam-on/cam-off compensation at the twilight ends (which I
# do), that makes it possibly a total of about 16.5 hours of total stream time.
# If I set the max video segment length to 8 hours, then the first half of the
# day will still run to about 8 hours (up to the midpoint) and bounce, and then
# after the midpoint, it will run for 8 more hours and then bounce again,
# shortly before the camera shuts itself off for the night. So that's slightly
# too short of a time to set. But then I'm squeezed at the other end: In the
# winter, the daylight can be about 8.5 hours long, so I don't want to set the
# max time to 9 hours to work around the "too short" thing in the summer. In
# reality, I don't care if an extra bounce happens near the end of the day in
# the summer, since the critters don't usually visit that late in the day. So
# for now I can live with setting this value to the shorter one (6 to 8 hours)
# so that the stream always has a midday bounce, even in the winter, and the
# summer sometimes get a second "midday" bounce near the end of the day.

[tfabris]

I've been thinking about this, and the algorithm should be rewritten to work as follows:

• Maximum video length feature should work no matter whether the limit is hit before midday or after midday. In other words, if you have a seven-hour length limit, and midday is at the nine hour mark, it should cut off the morning video at the seven hours mark anyway.

• During summer, when the video lengths before and after a midday split would end up being longer than the maxlength, that means the day ends up getting split into thirds, with the last third being shorter than the first two thirds. The first two thirds would be maxlength (for example seven hours) and the last third would be whatever is left over.

• If maxlength is short enough, then it'll just keep splitting the video at maxlength every time.

• If maxlength is longer than midday, it'll split the video at midday first.

• If maxlength is longer than the entire day, it'll still split the video at midday. (bad idea, scrapped)

I think I can do this by simply adding an additional parenthetical clause for the max length limit in the existing IF statement. Poke at it a bit.

[tfabris]

I have simplified the code, and now just bounce the stream if the length gets longer than the configured maximum. From the comments in the code:

# Check to see if the total video length exceeds maximum length, and if so,
# bounce the stream, to force the video to split the archive.
#
# This has a side effect of sometimes leaving a "short" segment near the end of
# the day before the camera gets shut down for the night. In other words, if
# the daylight (camera uptime) hours are 13 hours total, and the video length
# is set to 6 hours, there will be two 6-hour segments followed by a 1-hour
# segment. I tried several algorithms to make this more elegant, including
# midday splits, sliding scale "averaged" segment lengths, etc., but there was
# too much complexity, mostly due to the possibility that the stream might need
# to also get bounced because of network problems. In the end, I have decided
# that a "short" segment near the end of the broadcast day is not as much of an
# issue because there is usually not any critter activity in the late evening.

[tfabris]

The last issue (short segment at end of day) has been addressed in the latest checkin for issue #47.