By restarting the update immediately instead of waiting for the next one.
We only try this up to 3 times to prevent excessive quota usage if it keeps happening.
Previously, we would only do reorderings if we were refreshing the playlist
for some other reason (eg. a video was inserted).
We want to refresh the playlist before attempting reorderings,
so we split the routine into two parts:
- A part that finds out-of-order videos and returns a list of moves to make.
- A part that executes those moves.
We do the former before AND after refreshing, and the latter only with the result from after.
In addition to sorting the videos themselves into the correct spots,
we need to special case them when scanning for the correct place to insert other videos.
Note this only places them in the correct place on insert,
which requires they be set in the playlist config BEFORE being inserted.
A follow-up commit will handle the case of needing to re-order them post insert.
And switch to passing around a namedtuple of these + tags instead of just tags.
To avoid confusion with the list of videos in the playlist, we refer to this data as the "playlist config".
This is required in order to be able to move entries later.
Note our view of entry IDs may always be out of date, so any time you use one
you have to handle it no longer existing.
So that playlists don't pick up unlisted videos.
When the video is modified to be public, it will be added as normal.
However, note that since playlist_manager never removes videos from playlists,
making an existing video public video unlisted will not remove it from playlists.
We've seen cases where videos are not inserted even though the API call succeeded.
Our suspicion is that two concurrent insert calls for the same video are causing a race.
We try to avoid this by putting a lock around insert calls
The sheetsync loads playlist ids and tags into a new table `playlists`.
playlist manager reads this table and merges it with the playlists given on the command line.
This is the simplest case as we can just cut each range like we already do,
then concat the results.
We still allow for the full design in the database and cutter, but error out if transitions
is ever anything but hard cuts or if it's a full cut.
We also update the restreamer to allow accepting ranges, however for usability we still allow
the old "just one start and end" args.
Note this changes the thrimshim API to give and take the new "video_ranges" and "video_transitions" columns.
Mike Lang