The video quality degrades while sharing video post updating to Adobe connect 9.2.2c
Environment : Hosted
In the recent past, our customers experienced lots of meeting disconnection issues. After investigating the issue we found that high bandwidth usage led to the frequent meeting disconnection.
We have a “Worst Quality” parameter for every video quality level, which prevents the video quality drop below the threshold value. When we implemented the fix for meeting disconnect issue, we removed “Worst Quality” parameter which caused the video quality to drop below the threshold value. As a result video quality degraded. We identified this issue as a bug#3770546 and our engineering team has fixed this issue in the upcoming Adobe Connect version 9.3.
Recommendation to Customers/Users:
We do not have a solution for this issue as of now till 9.3 is released(tentatively scheduled for September 2014). However, some settings for room bandwidth can improve the video quality to some extent. Steps for the same are mentioned below:
Go to Meeting room > Meeting > Preferences > Room Bandwidth > LAN
For more details on optimizing the room bandwidth click here
It is expected that post Adobe Connect 9.3 release, the video quality level will not drop below the threshold value (Set for each video quality level) and will improve the video quality to a great extent.
When running the installation of Connect 9.2.1 (and higher) when you get to the step “Select Deployment Options” you can specify to deploy the services under “Local System Account” or to specify an existing user account.
One common reason to specify a user account is when using shared storage. The Connect service needs to have access to the network share specified in a later step during installation.
It is necessary to grant this user account “log on as a service” rights, otherwise the Connect, FMS, FMG services set to run under this user account will not start.
Here’s how to grant a user “log on as a service” right.
- Go to “Control Panel”, “Administrative Tools”
- Expand “Local Policies”
- Expand “User Rights Assignment”
- Find the Policy called “Log on as a service” and double click on it.
- Select “Add User or Group” and add the user account under which you want to deploy the services.
Alternatively you could also install with the local system account option first, then go to the windows services and change the account under which the service runs from there. This way Windows would automatically assign the missing “Log on as a service” right.
To do so, go to “Server Manager”, “Configuration” and “Services”. Find the “Adobe Connect Service”. Right-click the service name and select “Properties”. Specify the user account / password under the tab “Log On”, when you hit apply you’ll get a message that “Log On as a service” right has been granted to the user account.
11:40am EST – Universal Voice is currently down for customers on the following clusters: (NA1, NA2, NA6, NA8, NA9, NA12). This affects the ‘audio broadcast’ functionality in Adobe Connect Meeting rooms on those clusters. This also affects ‘user-configured’ (non-integrated) telephony profiles on those clusters. Meetings that utilize ‘UV Profiles’ (user-configured) will not have audio. Meetings that use the ‘integrated’ telephony profiles (telephony adaptors for InterCall, MeetingOne, Arkadin, and PGI) will still have audio, but the ‘broadcast’ will not work. We are currently working with our Operations team to resolve the issue. You can get full updates on our Adobe Connect Status Page here: https://status.acrobat.com
4:30pm EST – We have identified the issue and applied a fix for the Universal Voice issues that have occurred today in our EQX (SJ1) datacenter. This was a configuration issue outside of the application that affected the integration with our SIP service. The team has deployed the necessary changes and done appropriate testing to ensure the system is now stable.
When setting up an application-level health monitor (blog) on your LTM, you would point to the testbuilder diagnostic page at:
As the previous article explains, ‘the testbuilder page will send back the “status-ok” string. If there is any problem with the Connect server application, then testbuilder will not report the “status-ok” string’. Expanding on this a little bit, the following (below) are the actual status’ and possible scenarios you may see:
STATUS_OK = 0;
STATUS_CRITICAL = 2;
STATUS_MAINT = 3;
STATUS_TEST = 4;
STATUS_OK = 0;
This means the server is fit to work (status-ok). Server status in PPS_ENUM_DATA_HOST table is neither ‘X’, ‘M’ nor ‘T’ and server is initialized.
This is what load balancers should look for health check.
STATUS_CRITICAL = 2;
Server is not fit to work (status-critical). Server is not yet initialized (during start up), or has server status of ‘X’ in PPS_ENUM_DATA_HOST table.
This is also triggered if no connection to database can be made.
STATUS_MAINT = 3;
Server is in maintenance mode (status-maintenance). Has server status of ‘M’ in PPS_ENUM_DATA_HOST table.
Active server can be put to maintenance mode and vice versa. No new meetings will be run on this server, but currently active meetings will run until ended.
STATUS_TEST = 4;
Server is in “server isolation” mode (status-testing). Has server status of ‘T’ in PPS_ENUM_DATA_HOST table.
Used to put server in separate zone from other servers in cluster. This is hosted feature that is not actively used in production.
NOTE: The following steps only apply when Adobe Connect is configured for user authentication through an LDAP Directory Service.
Under normal circumstances LDAP synchronization is configured to synchronize automatically on a regularly scheduled basis. However, it is occasionally necessary to synchronize at times other than during the regularly scheduled periods. The following steps are for performing a manual Directory Service synchronization.
Please be aware that performing an LDAP synchronization can be resource intensive on the Connect side, and it is highly recommended that these steps not be performed during times of normal system activity.
- Log in to a Connect server
- Open the Administration console (http://localhost:8510/console/)
- Navigate to Directory Service Settings > Synchronization Actions
- Go to the Perform Directory Synchronization section and click on the Synchronize button.
Issue: H.264 encoded FLV not displayed when it is re-shared again in share pod.
Steps to reproduce:
1. Share H.264 encoded FLV in a share pod.
2. Stop sharing (without viewing it completely).
3. Share the FLV again from the share history.
Result:Video bar progresses but the audio and video is not rendered.
Reason: The FLV encoded in H.264 has this limitation that unless initialized from beginning it will not render video (and audio) frames. When we share it from ‘recently shared content’ it is not initialized from the beginning. Server tries to play it from the last cue point, which causes this issue. If we seek it to a position it starts to play well.
The behavior is not seen in VP6 encoded FLVs.
- Seek to start of the recording. Once initialized, we can seek to any point and it will play just fine.
- Re-encode the FLV with VP6 codec.