Stream key to the live feed changes occasionally.

[tfabris]

I don't know why, but once in a while I find that the stream is unexpectedly down and then I notice that YouTube changed my stream key.

Some time overnight last night (during the night of 2019-05-04 to 2019-05-05) the stream key changed, so the stream was down in the morning. This is the second time that the stream key had changed out from under me. The prior time this happened was only ten days ago, on 2019-04-25.

The fix is:

• Connect to Live Dashboard at https://www.youtube.com/live_dashboard
• Reveal the stream key and copy it to the clipboard.
• Paste it into the "Live Broadcast" control panel on Synology Surveillance Station and press Save.

To do:

• Find out why this happens?
• Find out if I can prevent it?
• If not, find out when I can detect it and notify when it happens?

[tfabris]

This issue recurred on the morning of 2019-05-08 after having encountered some troubles on the live stream (it happened after issued #23 occurred). The stream key got changed.

I suspect that maybe each time there is one of these occurrences, a new "Upcoming" entry appears on the live dashboard. I only see these entries on the "Beta" version of the live dashboard site but perhaps there is a way to see them on the "Classic" site too and I just forget the URL. In any case they look like this: https://studio.youtube.com/channel/UCqPZGFtBau8rm7wnScxdA3g/videos/live?filter=%5B%5D&sort=%7B%22columnType%22%3A%22date%22%2C%22sortOrder%22%3A%22DESCENDING%22%7D

[tfabris]

When I look into the details of those "Upcoming" entries, I can't see their stream keys in the web UI. but perhaps the whole issue is that you must "bind" your current stream to one specific one of those "Upcoming" entries as described here? https://stackoverflow.com/questions/55029629/youtube-api-v3-how-set-the-stream-key-on-new-event

Don't know. I mean, how could I bind to one of those if it won't show me the stream key value?

Update: Looked into it more. The docs on the "bind" command are here: https://developers.google.com/youtube/v3/live/docs/liveBroadcasts/bind The URL format is like this:

  https://www.googleapis.com/youtube/v3/liveBroadcasts/bind?id=YOUR_BROADCAST_ID&part=snippet&streamId=YOUR_STREAM_ID

This doesn't appear to help me with this bug. If the stream key changes out from under me, I don't care whether the stream key is related to the "broadcast" or the "stream", either way I'm sunk if I don't know the key.

Also:

• Need to understand with clarity their definitional difference between "broadcast" and "stream",

[tfabris]

Oh hey, at this URL the dude has a screen shot: https://stackoverflow.com/questions/55029629/youtube-api-v3-how-set-the-stream-key-on-new-event It shows that you can create a "re-usable stream key" instead of a single use stream key. Is it possible that I simply created single use key when I set up the channel? Look for this! How do I find it?

[tfabris]

I can't find that "Reusable stream key" setting described above.

[tfabris]

I have a piece of Work In Progress code that is now checked in which shows how to read the stream key from the YouTube API.

Will fix this issue with the following steps in CrowCam.sh:

• Read the current stream key from the Synology API's "Live Streaming" feature. This key will be visible already as part of one of the existing Synology API queries, but we don't change it.
• Read the stream key that exists on our YouTube channel's default livestream channel, using the example code that I just checked in.
• If both of those stream keys I just read above are nonblank, then can continue with the below.
• If either of those stream keys are blank, print an error to the log and skip the steps below.
• Check to see if the keys are the same. If they are the same, there is nothing to do and all is OK.
• If the keys are different, print an error to the log and write the new key to the Synology API. (Decide if this should be INFO or ERROR level message.)
• Note: Updating the stream key in the Synology API is theoretically a similar procedure as turning the stream off and on, so you should be able to do this.

To Do:

• Might need to refactor some code and put some of the YouTube API access token stuff into the helper functions.
• CrowCamCleanup uses those access tokens. Check to make sure that two programs don't need to be using the access token at the same time. If the access token is refreshed out from under the other program at the same time, it might cause a problem.
• Consider the different ways we can prevent a race condition. Perhaps write the access token to a file and have all programs read the token which need it? Look closer at how they're being used.

[tfabris]

The latest commit fixes this by updating the stream key if it differs.

[tfabris]

Okay. On 2019-06-02, there was a problem:

• I noticed network problems in the afternoon on The Agora network as follows:
  • Slow upload of videogame savegames to playstation network.
  • Nest Thermostat lost connection to the WLAN.
• Around the same time I heard that Google Cloud Services had had a major outage that day for several hours.
• The CrowCam stream had went down for the afternoon and I left the house without knowing that it had done so.
• Checking later that night, I see that the Stream Key is unchanged, but all the video metadata, such as the title and description, the thumbnail, and the public/unlisted setting, were all wiped and were set back to the channel defaults.
• Not sure what is up with the stream remaining down though. Looked at my code and the code says that I should not have prevented a proper stream-uppage due to the title difference. Why did the stream stop?

This is similar to the situations which occur when the stream key gets clobbered out from under me. However it's different because the key didn't change, but the title and metadata did change. So what happened here?

To do:

• Since I have repaired all the title and metadata information, the stream should theoretically go back up again tomorrow morning. Check it to see if it did.
• When you get back home, look at the logs and save them off and see what happened.
• Consider whether you can figure out how to fix this situation automatically when it recurs.

[tfabris]

I'm going to close this bug and open a separate bug about the stream metadata changing.