Subject: [93attendees] meetecho questions

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jul 2015 13:20:10 -0400

I'm remote for IETF93, and I've lived entirely on meetecho, while previously,
I've used a mix of streamed MP3/downloading-slides/pure-xmpp, and some meetecho.

1) the meetecho sessions seem to stop exactly at the closing time, which is
   sometimes a problem, and not everyone's watch is identically set.

2) the meetecho sessions do not start until the starting time, and you can't
   wait, so it means that one can not come a minute or two early.  I also
   suggest that during the time before the meeting starts, that some kind of
   "muzak" fill the meetecho room at the same levels, so that people can use
   that to validate if their headsets, etc. work.

3) the meetecho recordings are great because they synchronize slides and chat
   and audio... but... well.. can we have an option for 2x or 3x playback speed?

4) The name that you put on the "Blue Sheet" winds up being your jabber ID.
   Okay, great, but that is no collision process.  So if I happen to be in
   the jabber room using the same ID (through my regular jabber client), then
   I get kicked out with a weird error... Also, "Michael Richardson" is
   actually a pretty common name (my wife even has a cousin with the same
   name; please enqueue ozarks jokes now)... so even non-malicious situations
   could have conflicts.

5) I'd like to opt out of the chat on the *browser* screen, and just have the video and
   the slides be same size... that would be more pleasant.

6) what is the right process to get the camera pointed in a different
   direction? Should people in the room move it?   or?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Meetecho IETF support" <[email-masked]>
Date: Thu, 23 Jul 2015 20:19:37 +0200

Hello Michael,

thanks for your feedback! Answering inline.

>    sometimes a problem, and not everyone's watch is identically set.

If you experienced something like this it's weird, as that's actually not the way it should work. We only stop sessions when we notice it has ended, something we can do as we monitor all the video and audio streams from the control endpoint in the NOC. The only times we stop sessions before they end is when the overtime exceeds ~10 minutes, as in that case we need some time to prepare the session that starts in the following slot.

What does not work is trying to join a session after the end time, that's true, but for remote participants still in the room the streaming will proceed.

>    that to validate if their headsets, etc. work.

That shouldn't be the case either: to be precise, we configure our servers to allow users to join from exactly 5 minutes before sessions start. This allows for people to join quite a bit before the actual sessions start, and gives us enough time to make the proper checks (e.g., whether video and audio are captured and restreamed correctly) and fix things if needed.

>    and audio... but... well.. can we have an option for 2x or 3x playback speed?

Yep, there's no "increase speed" feature, but there is a seekbar below you can make use of to quickly go to a specific point in the recording. It's admittedly not very precise or effective, and is one of the areas we want to improve in that respect.

>    name; please enqueue ozarks jokes now)... so even non-malicious situations

We handle conflicts in Jabber usernames as I believe other clients do (or should do, at least). If you try to join a session via Meetecho and the username is already taken, you'll be asked to choose a different one: the UI suggests some by simply appending something to make the provided one unique. If you join with a Jabber client after you joined via Meetecho, the Jabber client should notify you about the conflict and resolve it pretty much the same way.

Not sure how we could change this behaviour to improve this. If the conflict management is not working as expected, it's a bug we need to fix.

>    the slides be same size... that would be more pleasant.

As of now that's not possible, you're right. We do provide a Jabber-less alternative, but it only provides a Flash-based view of the slides and the audio feed, no video.

Jabber is integrated as we actually thought it would be seen as a convenience for users, so we honestly never thought about an option to opt out. If there will be enough interest in this, we'll try and work on a further alternative to address that requirement as well. 

>    direction? Should people in the room move it?   or?

That's actually our fault :-)

As anticipated, we're monitoring all sessions at the same time from a couple of controlling laptops. All cameras are remotely controllable, which means we can follow speakers around and, when possible, follow the discussion (e.g., focus on the mic line rather than the speaker). That said, 8 sessions at the same time are a lot, and since we're often busy on other things (e..g, making sure audio works, helping a remote presentation, processing recordings and the like) we sometimes lose track of a few videos.

This is something you guys can help us on, though: we join all Jabber session using Meetecho as a username, so if you notice we're not doing something right, just mention us on the jabber room (as Meetecho, capital M), and we'll be alerted loudly. This obviously also applies if you notice any problem, either in the local room or in the Meetecho session.

Thanks again for your feedback and suggestions!
the Meetecho Team

> --
> Michael Richardson , Sandelman Software Works

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Jul 2015 17:32:28 -0400

On 7/23/15 1:20 PM, Michael Richardson wrote:

> 4)  Also, "Michael Richardson" is

I don't understand. I have *never* experienced a naming conflict! :-)

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Jul 2015 16:33:39 +1200

> I don't understand. I have *never* experienced a naming conflict! :-)

Some of us are not so lucky. When I joined IBM there were two other Brian Carpenters
already there, and this guy could perfectly well show up in an IETF context:
https://twitter.com/geeknik