On Sunday, I hosted a Hangout On Air which ran pretty well. However, several features of the experience were disappointing.
Here, I’m setting aside questions about what the panellists said. It was a fascinating discussion, but in this blogpost, I want to ask some questions, instead, about the technology involved in creating and broadcasting the Hangout On Air. That was the disappointing part.
If anyone reading this can answer my questions, I’ll be most grateful.
If you take a quick look at the beginning of the YouTube video of the broadcast, you’ll immediately see the first problem I experienced:
The problem was that the video uplink from my own laptop didn’t get included in the event. Instead of what I thought I was contributing to the event, the event just showed my G+ avatar (a static picture of my face). That was in contrast to situation for the other four participants.
When I looked at the Hangout On Air window on my laptop as I was hosting the call, it showed me a stream of images recorded by my webcam. It also showed, at other times, slides which I was briefly presenting. That’s what I saw, but no-one else saw it. None of these displays made it into the broadcast version.
Happily, the audio feed from my laptop did reach the broadcast version. But not the video.
As it happens, I think that particular problem was “just one of those things”, which happen rarely, and in circumstances that are difficult to reproduce. I doubt this problem will recur in this way, the next time I do such an event. I believe that the software system on my laptop simply got itself into a muddle. I saw other evidence for the software being in difficulty:
- As the event was taking place, I got notifications that people had added me to their G+ circles. But when I clicked on these notifications, to consider reciprocally adding these people into my own circles, I got an error message, saying something like “Cannot retrieve circle status info at this time”
- After the event had finished, I tried to reboot my laptop. The shutdown hung, twice. First, it hung with a most unusual message, “Waiting for explorer.exe – playing logoff sound”. Second, after I accepted the suggestion from the shutdown dialog to close down that app regardless, the laptop hung indefinitely in the final “shutting down” display. In the end, I pressed the hardware reset button.
That muddle shouldn’t have arisen, especially as I had taken the precaution of rebooting my laptop some 30 minutes before the event was due to start. But it did. However, what made things worse is that I only became aware of this issue once the Hangout had already started its broadcast phase.
At that time, the other panellists told me they couldn’t see any live video from my laptop. I tried various quick fixes (e.g. switching my webcam off and on), but to no avail. I also wondered whether I was suffering from a local bandwidth restriction, but I had reset my broadband router 30 minutes before the call started, and I was the only person in my house at that time.
Exit the hangout and re-enter it, was the next suggestion offered to me. Maybe that will fix things.
But this is where I see a deeper issue with the way Hangouts On Air presently work.
From my experience (though I’ll be delighted if people can tell me otherwise), when the person who started the Hangout On Air exits the event, the whole event shuts down. It’s therefore different from if any of the other panellists exits and rejoins. The other panellists can exit and rejoin without terminating the event. Not so for the host.
By the time I found out about the video uplink problem, I had already published the URL of where the YouTube of the Hangout would be broadcast. After starting the Hangout On Air (but before discovering the problem with my video feed), I had copied this URL to quite a few different places on social media – Meetup.com, Facebook, etc. I knew that people were already watching the event. If I exited the Hangout, to see if that would get the video uplink working again, we would have had to start a new Hangout, which would have had a different YouTube URL. I would have had to manually update all these social networking pages.
I can imagine two possible solutions to this – but I don’t think either are available yet, right?
- There may be a mechanism for the host to leave the Hangout On Air, without that Hangout terminating
- There may be a mechanism for something like a URL redirector to work, even for a second Hangout instance, which replaces a previous instance. The same URL would work for two different Hangouts.
Incidentally, in terms of URLs for the Hangout, note that there are at least three different such URLs:
- The URL of the “inside” of the Hangout, which the host can share with panellists to allow them to join it
- The URL of the Google+ window where the Hangout broadcast runs
- The URL of the YouTube window where the Hangout broadcast runs.
As far as I know, all three URLs change when a Hangout is terminated and restarted. What’s more, #1 and #3 are created when the Hangout starts, even before it switches into Broadcast mode, whereas #2 is only available when the host presses the “Start broadcasting” button.
In short, it’s a pretty complicated state of affairs. I presume that Google are hard at work to simplify matters…
To look on the positive side, one outcome that I feared (as I mentioned previously) didn’t come to pass. That outcome was my laptop over-heating. Instead, according to the CPU temperature monitor widget that I run on my laptop, the temperature remained comfortable throughout (reaching the 70s Centigrade, but staying well short of the 100 degree value which triggers an instant shutdown). I imagine that, because no video uplink was taking place, there was no strong CPU load on my laptop. I’ll have to wait to see what happens next time.
After all, over-heating is another example of something that might cause a Hangout host to want to temporarily exit the Hangout, without bringing the whole event to a premature end. There are surely other examples as well.