The successor to EVO, by the end of 2012, will be a commercial product called SeeVogh. We have started an evaluation process to see if SeeVogh will work for Fermi.
The initial offer from Philippe Galvez for Fermi would be ballpark $10k for an annual subscription, based on our usage from last year which was about 1100 meetings. Richard would like to compare that to WebEx or GoToMeeting. Alternatively if you buy as you go, the person setting up the meeting is designated the "moderator" and is responsible to pay for the meeting in "SeeVogh" credits. 60 minutes is the minimum meeting time. Right now 1 hour is 54 credits. Once the meeting has started, you cannot be refunded, even if you do not use up the full allotted time. This wouldn't be an issue if we had a subscription.
SeeVogh has gone live in 2013. If you still have issues with it, please enter it here:
Current Issues:
Feb 7, 2013 – Elizabeth Ferrara (using a MacBook Pro, brand new, running Mac OSX 10.8.2)
No services available in meeting: SeeVogh starts properly. I am able to log in and view the main page for my community. When I try to join a meeting, what looks like a default meeting window pops up with all the various services at the top, but no picture. That window is then replaced by one with JUST the picture, but no services. When I try to close the window, I am given the option to leave the meeting or to exit SeeVogh.
Jan 10, 2013 – Jennifer Siegal-Gaskins (using a MacBook Air, mid-2011, running Mac OSX 10.7.5)
SeeVogh kept crashing when I tried to join a meeting (I could log in to SeeVogh, though). The SeeVogh help pages say I need to update my graphics card driver. I cannot locate a Mac update for my graphics card (Intel HD Graphics 3000 384 MB) either on Apple's site or the Intel site. I emailed SeeVogh support on Jan 10, no reply yet. My workaround was continuing to use EVO.
Feb 5 – problem still not resolved.
August 16, 2013 -- Narayana Bhat (I am using MacBook Pro with Snow Leopard) After using the SeeVogh normally I wanted to shut it down by clicking on the pull down SeeVogh menu and hitting exit. Then it comes with an option window to confirm. When I hit 'Yes' it freezes. The window refuses to shut. I have to reboot to get rid of the window.
SeeVogh email support is now: evosupport@seevogh.com. Please cc me (Richard) if you send mail to them. If SeeVogh will not fire up at all, you can find the logfile somewhere like here:
It should be SeeVoghRN.log* in
$TMDIR on macos.
Also, please check for the hs_err_pidXXX.log - this should be either in
$HOME or in $TMPDIR subdirs...
It should be SeeVoghRN.log* in
$TMPDIR on macos.
Also, please check for the hs_err_pidXXX.log - this should be either in
$HOME or in $TMPDIR subdirs...
SeeVogh User Guide
http://seevogh.com/doc/SeeVogh_User_Guide_032612.pdf
Testing Room June 15, 2012
For those who may wish to test out SeeVogh, please use the link below to enter a testing room.
Good for the next month: http://seevogh.com/?join=5994848102
Second Fermi Test May 30, 2012
Participants: Rob Cameron, Jim Chiang, Richard Dubois, Warren Focke, Tom Glanzman, Heather Kelly,Maria Elena Monzani, Tom Stephens
Multiple Attempts by: Joanne Bogart
For those that had troubles, we are in contact with Vladimir Litvine <vlitvine@ligo.caltech.edu> , a technical representative from SeeVogh. You may be asked to provide the log from SeeVogh which tends to stored in /tmp.
Heather acted as moderator this time around. While setting up the meeting - it would be nice to be allowed to update the text boxes directly rather than using the sliders. At least on my Windows XP box using Firefox, I was unable to interact with the text boxes directly. I also waited to see what would happen at the very end of the meeting when our hour was up. SeeVogh waiting an extra 30 seconds or so, and then terminated the meeting. Will there be a way to ask for more time? Will there be a way to record meetings as was available in EVO?
Initially there were a number of issues with getting the audio to work, but ultimately those that were able to connect could at least hear, if not speak. Many of us were eager to turn off the chat chirps that are on by default.
A variety of issues presented themselves:
Joanne was completely unable to connect via her RHEL5 box despite her previous interactions with Vladimir, our technical support contact at SeeVogh. The jnlp file downloaded but apparently crashed. She went back to her Ubuntu netbook and got slightly further but it seems the Java client crashed each time she attempted to enter the meeting, other participants could see Joanne but that's as far as it got. Joanne is in contact with Vladimir again and is working through his suggestions. (Joanne) EVO works on both of these machines.
Richard connected from a Mac had acceptable audio in the beginning, but then it devolved to sounding as though he was speaking through a "sewer pipe". Ultimately he left the meeting and restarted the Java client and his audio was fine.
Marie Elena initially had trouble connecting through her Mac - with the Java client download hanging on 95% completion saying "verifying application". M.E. tried again and she was able to enter the meeting and could hear and speak, after updating her audio settings so that the microphone was not muted as seems to be the default.
Tom Glanzman was unable to connect from his RHEL6-64 box with Chrome v19.0.1084.52 after multiple attempts, where each time the Java client crashed. Note that a recent attempt to update video drivers for RHEL6-64 did not change the openGL version (still at 1.4), so one of our desktop support folks (Wayne Yu) continues to investigate.
Hi Tom, I will need to look into this more. I have looked at both RHEL5 and RHEL6 system with different Nvidia card, and both shows OpenGL 1.4. So I installed Ubuntu 12.04 on a laptop and it shows OpenGL 2.1. And I check the Mesa version on all three system. RHEL5 shows Mesa 6.5.1, RHEL6 shows 7.11 and Ubuntu shows 8.0.2. The OpenGL driver support could be a combination of OpenGL library that comes with the operating system and hardware. Mesa provides the software rendering capability and the video card does the hardware part of it. Wayne
Tom G. then connected from a Windows XP box initially trying through the Chrome browser (both beta and canary) generated an error that the chrome versions are "too old" although they are up to date. Tom then tried Firefox which seemed to work for audio, though there was a complaint that an OpenGL update is required for video (current version is 1.3.1030, but 1.5 is needed) For fun, Tom also tried Android but SeeVogh on android fails immediately --- claims the Safari version was too old.
Jim Chiang connected via his Macbook running Lion which seemed to work, only issue was having to update the audio so that the microphone was not muted (this was an issue for all the Mac users present). Meanwhile on RHEL5-64 SeeVogh window came up but complains about not loading the video module. Jim was unable to hear or speak or select audio devices. His SeeVogh log is available here . During our first attempt for one of our software meetings , Jim was able to connect via his Fedora 12 box just fine.
Regarding this issue with RHEL5 64 bit machine which log you attached. This is not related to graphics card. This graphics card is pretty good and support opengl 3.0+. The problem with this machine is that it is missing SDL package. Perhaps it is because it uses 32 bit java virtual machine. Please ask this person to check and install both 32 and 64 bit version of SDL package. Usually you can check the availability with
yum list SDL
and install all both 32 bit (i586 or i686 prefix) and 64 bit (x86_64 if it was not already installed).
After that you should be able to run SeeVogh on this machine.
We are using SDL for Timer, but right now we are working on it and next release will not have this dependency.
Tom Stephens connected via his ScientificLinux6-64 laptop and Windows 7-32 netbook. When trying to use DesktopShare on SL6, it did not work at all and his SeeVogh client locked up when trying to turn off DesktopShare. When turning it on, nothing happened, no frame appeared and no desktop images appeared on other clients. When turning off DesktopShare the UI became unresponsive and quit updating. He could continue to hear, but was unable to interact with the client to make any adjustments including killing the window. He went to the process table to kill the client manually. Initially he tried to kill javaws SeeVogh, but that just respawned itself, so Tom killed another process instead. The experience on Windows7 seems to have been without incident.
Warren Focke on RHEL5-64 was unable to speak but could hear. He also experienced the SeeVogh client locking up once he tried to start up a DesktopShare. Warren was able to continue to hear the meeting.
Rob Cameron connected to the meeting from a MacBook Air running OS X Lion (10.7), starting from a Firefox browser (version 12.0), wirelessly connected to the SLAC visitor wifi network, at SLAC. He connected to the meeting without problem (after he remembered his nickname from his registration with SeeVogh a few days earlier). He plugged in a USB headset to the Macbook and configured sound input and output through the headset while the SeeVogh Java applet was starting up (which took less than 1 minute). A popup window from SeeVogh asked him to confirm using the USB headset for audio. Audio output was clear from the start and stayed that way (although Richard was almost impossible to understand when speaking from his sewerpipe). The self-facing camera started immediately upon entering the meeting, and his microphone was live when he entered the meeting. He turned off the video feed quickly - the control at the top of the pop-up SeeVogh screen was quite intuitive. The static video feed from Heather was clear for most of his connect time, although it changed to a disrtorted image for some seconds in mid-meeting, but then cleared itself up again. The video feed from Jim Chiang started up and tiled nicely to a vertical tile pair with Heather's video feed. He also changed preferences to turn off the self-facing video feed to the meeting. The default of hearing beeps at every text entry was also very annoying, and he turned that off in the preferences also. The text entry window scrolled correctly as people entered text messages. He tried text entry, which worked fine. He did not try to speak in the meeting. He exited the meeting, and re-entered later, and found that his preferences were preserved and honored at re-entry. His login nickname was pre-filled for the re-entry. He noted that the list of meeting attendees does not show as the default in his first use of SeeVogh, but was turned on quickly through the top on/off control icons. Also, he noted that Tom Stephens nickname was extra long: "Tom Stephens (Windows 7)", which caused the right side panel showing the meeting attendees to have a horizontal scroll bar and not show the right-hand end of Tom's nickname unless that panel was scrolled right. Resizing the overall SeeVogh window did not correspondingly resize the right-hand panel of nicknames and the horizontal scroll bar for that panel could not be made to go away. The panel for the main SeeVogh window and the nickname panel both have black background with no apparent delineated boundary between the panels, and so it is not obvious if there is another way to change the split between the panels. Finally, the "speaking" bubbles against each nickname seemed to roughly correspond to the actual speakers, although there seemed to be at least once instance where a speech bubble appeared against a name, but I didn't hear the person speak - which may have been due to microphone or other problems for that attendee.
When an issue is clearly associated with the video driver - it would be nice to have the option of turning off the video and strictly use the audio only. Unfortunately, that does not seem possible:
The problem here is that EVO client was redone as a one window application. Situation with both Joanne's computers is that two bugs are killing the JVM. In EVO case it is just a Java thread which started ViEVO would be killed, while in SeeVogh case it is the main thread, so the whole client is gone. This is not the situation when you have OpenGL 1.1 and video will not work - this is worse. Due to the bugs, the whole JVM went down.
There are couple of things to try which I sent to Joanne. In one case I recommended to add extra pathes in the xorg.conf - this should help to find the shared libs which are needed, and in second case recomendation was to reduce the video components as much as you can - unplug the webcam.
Would be interesting to see how it will work. HMK comment: unfortunately there was no webcam in this particular case, but maybe that idea will help others
Of course the best way would be to update the video drivers and fix those bugs.
SeeVogh Road Map from Philippe Galvez May 29, 2012
Below if the road map we have concerning features and release concerning the SeeVogh Research Network Service.
o August 2012: Pre-release of our SeeVogh Research Network portal. It will include the following features.
- Android and IOS (Ipad) support
- H.323 and SIP Call-in and Call-out
- Phone connection (same as of today)
- SeeVogh Meeting Manager: That will be an application that can run all the time in your machine (like a simplified Koala and with the SeeVogh L&F) and give access to ongoing meetings, users presence, click to join a meeting, ...
- SeeVogh Client: This window appears when you join a meeting and that will be a place where all the interaction is occurring during the meeting. (you already used the SeeVogh client).
o September 2012: Release of the SeeVogh Research Network
o January 2013: The service will be available to only paying customers
Demo with Bob May, 2012
Joanne was completely unable to connect from three different machines: Mac OS 10.4 (too old), Ubuntu netbook (JAVA issue?), and RHEL5 (possibly due to a need for a native OpenGL driver).
Bob provided a nice demo of the video features of SeeVogh, including desktop sharing. Having a wired connection was vital to use the video at all, and even so, my DSL connection was not quite up to the task of keeping the desktop share usable.
First Test May 7, 2012
Questions that came up are highlighted.
Participants: Anders Borgland, Richard Dubois, Heather Kelly
Richard (Mac) and Heather (Windows 7) had no trouble getting connected. Anders (Linux) could not get the video client to start up and thus was also unable to see desktop shares (it complained about "Cannot load ViEVO lib vievoLib /afs/slac.stanford.edu/u/ek/borgland/.java/deployment/cache/6.0/3/33e21603-26a383f3-n/libvievoLib.so: libjawt.so: cannot open shared object file: No such file or directory". It could be a simple PATH problem. I've attached the logfile.). Anders also could not speak. Richard acted as the moderator. The moderator controls the start of the meeting, so in effect there is no set meeting time. There is a one page used to set up the details including name and description of the meeting. Richard did not see a way to set "recurrence".
Anders did comment that Richard's audio was particularly clear and strong. Later on during the meeting, we did note that Richard's audio started to fade in and out. Typically it was when Richard would start speaking again, and then after a sentence or so the audio would pick up. It did not seem due to changes in his personal volume.
The default for audio and video seems to come up with the microphone un-muted and video on - it would be better to do the opposite. Similarly public chat should be on by default as well as the participants list.
Video is also on by default. The video window is shared so as more participants enter, each tile associate with each participant is given a smaller piece of the pie. Richard wondered how it would appear if there were 100 participants. (Actually he wondered what would happen with the participant list on the side for a large meeting.)
We tried out the "desktop share" by having Richard share his desktop and that seemed fine.
Under Menu->About there is a "Copy Log" button, it would be nice to locate this in a more prominant location under Menu. The ability to directly email the SeeVogh support team seemed to be missing; maybe the red cross button to just send the log.
The moderator controls the ending of a meeting - if we run over an hour, does the moderator get prompted to add additional time?
What if the moderator has to leave early, but the other meeting participants want to carry on?
Does leaving a meeting mean you have to exit the application entirely? Sometimes it is nice to be able to hop into another meeting straightaway.
Is there a capability to browse available meetings? Is there a password capability to prevent anyone browsing the meetings from joining?
Will there be the concept of a Fermi "Community" that our group can join? Will that change the meeting booking behavior - e.g. to allowance recurrence, perhaps no moderator needed to start/stop the meeting.
Does the moderator have control over attendees? Mute, eject etc?
Responses from Philippe:
(1) Anders's video Linux issue: I can see that it is looking for the
libjawt.so lib. You can see some hints at
(http://mail.openjdk.java.net/pipermail/jdk7-dev/2011-August/002256.html
or https://bbs.archlinux.org/viewtopic.php?id=124432)
(2) Anders's audio Linux issue: The code is the same as for EVO. He may
need to select the correct driver via the down arrow close the mic icon.
(3) Meeting recurrence: Not in this version but will come.
(4) Audio fading during the first sentence was probably due to the
autogain adjustment where the audio may be saturated and then adjusted.
You may want to check your input mike level on your Mac Audio Settings.
(5) Audio/Video unmuted was done on purpose as most new comers were
confused when not on. But this is configurable and will be adjustable
depending of the customers.
(6) Video streams is limited to 50 (low quality) maximum and will be
contained to some defined bandwidth and video will be configurable too.
The participants list will increase with a side bar when space is needed.
(7) The "Red Cross" missing button is something we are looking to add
going forward.
(8) When a meeting is over, the meeting is stopped but obviously some
mechanism to extend it will be build as we progress.
(9) If the moderator leaves then it doesn't affect the meeting at all
(10) Leaving the meeting means leaving the application
(11) For now, you have no function to list the ongoing meetings.
(12) We have a concept of "Corporate account" that will include all
members of an organization/group. That something we can demonstrate to
you if you want.
(13) You can moderate (mute, unmute, ...) the meeting by selecting your
name in the participant list and enter the moderator keys.
Question and Answer Time Between Richard and Philippe Galvez May 7,2012
Super. I assume if we subscribe then anyone in Ferm will be able to initiate meetings.
>Yes. Of course.
If I book a 1 hour meeting can people join the room early to make sure everything is working?
>It works a bit differently. You book a total time and it only starts but
>the moderator or who ever has the moderator key starts the meeting.
>In resume, you can reserve a meeting for 2 hours and not using it for
>weeks, the starting time only starts when you activate the meeting.
And will they be able to scan meetings in the community as we can now?
>
>Not for now. We are at the early stage.
Have you maintained your fleet of pandas etc in this transition? There will be lots of questions about the new system :-)
>
>Yes. All should be nearly transparent for the end user concerning the infrastructure.