Guest

Cisco Videoscape Distribution Suite for Internet Streaming

Release Notes for Cisco TV CDS 2.5.3

  • Viewing Options

  • PDF (183.2 KB)
  • Feedback
Release Notes for Cisco TV CDS 2.5.3

Table Of Contents

Release Notes for Cisco TV CDS 2.5.3

Contents

Enhancements

Supported Environments

System Requirements

Limitations and Restrictions

Open Caveats

CServer

Configuration

FSI

Monitoring

Statsd

Resolved Caveats

CServer

RTSP

Other

Upgrading to Release 2.5.3

Upgrading from Release 2.5.2 to Release 2.5.3

Downgrading from Release 2.5.3 to Release 2.5.2

Related Documentation

Obtaining Documentation and Submitting a Service Request


Release Notes for Cisco TV CDS 2.5.3


These release notes cover Cisco TV CDS Release 2.5.3.

Revised: January 2012 OL-26377-01

Contents

The following information is in the release notes:

Enhancements

Supported Environments

System Requirements

Open Caveats

Resolved Caveats

Upgrading to Release 2.5.3

Related Documentation

Obtaining Documentation and Submitting a Service Request

Enhancements

The following enhancements have been added in Release 2.5.3:

Added asset filename (mName) to archived stream reports (Report > Archived Data > Stream Reports). (CSCtn11549)

In RTSP environment, support more than four playlist items if master Streamer fails over. (CSCtu34010)

Supported Environments

Release 2.5.3 of the Cisco TV CDS supports both the ISA and RTSP environments. Some RTSP environment features are only applicable to certain RTSP Deployment Types.

System Requirements

The Cisco TV CDS Release 2.5.3 runs on the CDE110, CDE220, CDE250, and CDE420. See the Cisco Content Delivery Engine110 Hardware Installation Guide, and the Cisco Content Delivery Engine 205/220/250/420 Hardware Installation Guide.

The Cisco TV CDS Release 2.5.3 also runs on the CDE100, CDE200, CDE300, and CDE400 hardware models that use the Lindenhurst chipset. See the Cisco Content Delivery Engine CDE100/200/300/400 Hardware Installation Guide for set up and installation procedures.

Release 2.5.3 does not support the CDEs with the ServerWorks chipset. All CDEs with the ServerWorks chipset need to be replaced with the CDEs with the Lindenhurst chipset or the Next Generation Appliances (CDE110, CDE220, CDE250, andCDE420) before upgrading to Release 2.5.3.


Note If you are using Internet Explorer 8 to access the CDSM GUI, for the online help to display correctly, you need to turn on Compatibility View. To turn on Compatibility View in Internet Explorer 8, choose Tools > Compatibility View.


Limitations and Restrictions

This release contains the following limitations and restrictions:

RTSP Redirect Server Limitations—The TV CDS Redirect Server provides a central entry-point for stream requests, which are then redirected based on internal load balancing policies to other Setup servers in the CDS deployment for session processing. The load balancing policies require that the CDS server running the Redirect Server have access to the database of each potential Setup server. The policies use key pieces of information from the database, such as the RTSP server status, the server load, and the Setup IP address to management IP address mappings. If the Redirect Server does not have access to this data, it cannot properly redirect the setup request to the "best" Setup server.

In the case of multiple Stream Groups, with the Redirect Server configured to run on Streamers within one of the Stream Groups, it is required that the database replication partners for the Streamers contain all of the Streamers from all Stream Groups, which basically constitutes a full-mesh database replication approach among all of the Streamers

If a full-mesh database replication for the Streamers is not desired, the Redirect Server can operate on the Vaults, which already have the necessary database replication partners defined to support required data.

Open Caveats

This release contains the following open caveats:

CServer

CSCtx54504

Symptom:

Server may errantly (and very temporarily) report system pressure.

Conditions:

When the system is running at full capacity and resources are very low.

CSCtt22964

Symptom:

Transmit unit hang detected on e1000 interfaces during a server bring-up soon after upgrading from Release 2.3.3.

Conditions:

Happens only after upgrading the software from Release 2.3.3 during server bring-up on servers with e1000 adapters in quad formation and specific adapters on that quad configuration.

Workaround:

Rebooting a second time fixes the issue. This is a know issue with Intel drivers. Following is the excerpt from the driver README:

Detected Tx Unit Hang in Quad Port Adapters
-------------------------------------------
In some cases ports 3 and 4 don't pass traffic and report 'Detected Tx Unit
Hang' followed by 'NETDEV WATCHDOG: ethX: transmit timed out' errors. Ports 
1 and 2 don't show any errors and will pass traffic.
 
   
This issue MAY be resolved by updating to the latest kernel and BIOS. The 
user is encouraged to run an OS that fully supports MSI interrupts.
 
   

CSCtr46736

Symptom:

Primary-backup status conflict in some servers.

Conditions:

Network partition.

Workaround:

None.

CSCtt02130

Symptom:

Server goes into kernel debugger (KDB) mode after a "service network restart" is issued or an individual adapter is restarted.

Conditions:

It only happens when the adapters are shared with the Linux operating system.

Workaround:

None.

CSCtr15443

Symptom:

Evaluators shown as continuously active; they never seem to complete.

Conditions:

A disk drive that is bad or failing, yet not sufficiently bad to be declared "sick" by the disk driver continues to go in and out of "repair" mode, causing the evaluators to constantly restart and inhibiting the evaluators from completing.

In addition, the evaluators need to have a significant amount of local work that needs to be done (such as defragging or smoothing). If the amount of work is small, this symptom may not be exhibited because the evaluators are able to complete the task during the small windows of time that the disk drive is not in repair mode.

Workaround:

Remove and replace the bad disk drive.

CSCtu19076

Symptom:

System KDB may occur.

Conditions:

Removing a front-mounted device before the logical preparations for removal are complete.

Workaround:

Before removing a functioning storage device from the front of the server, ensure that it has first been logically removed by echoing the device name to /proc/cds/cdd/remove_device. For example,

echo csd3 > /proc/cds/cdd/remove_device prepares the device csd3 for removal from the server.

Ensure that the message "csdX can now be safely removed" (where X is the device number) appears on the console before pulling the device. Also, the red LED on the device will be flashing after it has been prepared to be removed.

Following these recommendations will avoid a possible system KDB event.

CSCts35941

Symptom:

During a failure of the Streamer hosting the primary Control server, occasionally part of the playing streams could be lost. This loss happens because of communication problems between the Streamers, causing confusion over which Streamer was the primary Control server, and also in some cases preventing the backup server from receiving the current state for all playing streams.

Conditions:

Loss of streams during a primary Control server failure are most likely to occur when a new Streamer has been brought online shortly before the primary Control server failed. Code that should have been sending switch forwarding probes on the ports for the new server to determine if the router forwarding table was sending and receiving traffic on the ports, before using the ports for live video and control traffic, was incorrectly making the ports available for use before the switch forwarding table was properly setup for sending and receiving traffic on these ports. This caused a very high percentage packet loss for communication traffic to the new server. The new server could then mistakenly believe there were no other primary Control server and could temporarily take over the role of primary Control server with no stream state. While in this mode, the new Streamer would issue commands to tear down all the streams that were playing on Streamer that it could communicate with.

A second problem could occur when the new Streamer did see the current primary server and the new server was the second Streamer to come up. There is a time window, during which the new Streamer has not finished bringing all of its ports online and had only one or two active ports, where the primary server could decide to use this new Streamer as the backup server. The primary would then send the new Streamer stream state information in parallel from multiple ports on the primary server exceeding the capacity to deliver the information being sent from many ports to the one or two active ports on the receiving Streamer. This would result in a high level of packet loss, and retransmitting the packets would continue to fail until the Streamers declared each other unreachable. The backup server would then see the primary as unreachable, but would only have state for part of the playing streams. If the primary server really failed so that the primary control IP address was no longer reachable over the management network, the backup server could become primary without having state for many of the stream.

These problems are much more likely to occur when the switch being used has a significant delay when a new port comes online, before the switch forwarding table is setup to forward traffic to and from the new port. The problem is also dependent on the timing between when a new Streamer comes online and when the existing primary server fails.

Workaround:

When possible, avoid shutting down the primary server if another Streamer has just come online. Wait for a couple of minutes after bringing the new Streamer online to make sure that it has had time for the switch to enable communication on all of the ports.

Some switches have configuration settings that can be modified to reduce the time delay between when a new port first detects link state and when the switch sets up the forwarding table information to send and receive traffic on the port. Reducing this time delay will help minimize the window in which this problem can occur.

CSCtt22591

Symptom:

Usually the first symptom is the presence of "WARNING: Stream transmit..." errors in the protocol timing log. This indicates that the LAN ports are getting behind.

Next some streams are dropped to reduce the load on the server, and some streams may end up getting changed to a NULL state-see the "Nulls:" part of the "Active streams:" lines in the protocol timing log to track this.

Conditions:

This appears to happen when the LAN channel has a total combined bandwidth (transmit and receive) of 41 to 46 Gbps.

Workaround:

There currently is no workaround other than to avoid having the server support both a maximum fill-bandwidth load and a maximum transmit-bandwidth load at the same time. It takes a well balanced load to do this; usually a server reaches a maximum on one or the other instead of both at the same time; so it is not likely you will actually encounter this problem.

Release 2.5.3 has the following LAN transmit and receive maximum limits:

Maximum transmit-bandwidth for a server with 4 10-gigabit Ethernet adapters is around 37.5 Gbps.

Maximum fill receive-bandwidth for a server with 4 10-gigabit Ethernet adapters is around 9.45 Gbps.

CSCtn28329

Symptom:

In the CDSM (or VVIM) GUI, on the Server Setup page (Configure > Server > Server Setup), when specifying an interface for the FTP Out Interface field under the FTP Out Setting section, the configuration setting does not take affect and the specified interface is not used for FTP out operations.

Conditions:

Using the CDSM (or VVIM) GUI, specify an FTP out interface and submit the Server Setup page. The setupfile on the server will be updated to reflect this configuration, as in following example:

ftpout if eth0 max utilization mbps 0 max sessions 0
 
   

Workaround:

The IP address of the interface to be used in FTP out operations can be specified on the ftp command line.

Configuration

CSCti78219

Symptom:

Not all packages are found in the drop-down list on the Monitor > System Level > Package Monitor page.

Conditions:

When the number of packages in the system reaches a level greater than 70,000.

Workaround:

If the number of packages in the system grows much beyond 70,000, then the drop-down list may not be able to display them all. The solution is to delete packages that are no longer needed. The maximum number of packages that will display in the drop-down list is variable, and is dependent on the system that is accessing the web page.

FSI

CSCtt46144

Symptom:

For a duplicated live future request, the state field in response XML body is empty instead of having the correct state of the scheduled live recording.

Conditions:

The client sends a request to schedule a live content with the same assetID, providerID, captureStart and captureEnd as an already scheduled future recording on the same channel.

Workaround:

None.

Monitoring

CSCtu23071

Symptom:

The following symptoms have been observed:

1. Monitor > Server Level > Disk Monitor shows a different failed disk than the Disk Activity graph.

2. When using some web browsers, the Disk Activity graph may reload repeatedly.

3. The Disk Activity Graph may show zero read/write activity if the disk activity is greater than100 Mbps.

Conditions:

Any CDE250.

Workaround:

For item one, there is no workaround. For item 2, using an older browser (IE6) should allow the user to see the Disk Activity graph. For item 3, when viewing the graph, the user can click on the icon to switch between the graph and a table display of the values to see if any disks are working at greater than 100 Mbps.

Statsd

CSCto43335

Symptom:

Caching Node remote servers file contains all servers from old group.

Conditions:

Moving Caching Node from group A to group B.

Workaround:

Restart statsd on the Caching Node that was moved and log in to the CDSM GUI and submit the Server Setup page for that Caching Node.

Resolved Caveats

This section contains he resolved caveats in Cisco TV CDS Release 2.5.3. Not all resolved issues are mentioned here. The following list highlights resolved caveats associated with customer deployment scenarios.

CServer

CSCtx27620

Symptom:

In an group of streams, nearly all the streams get assigned to be streamed on one Play server.

Conditions:

When a playlist is used and there are very short bumpers or advertisements put at the beginning of the playlist and before the main feature; the algorithm to assign where a playlist play uses the first element in the playlist. The result of this is that with the short bumpers or advertisements, the whole playlist is assigned to the same Streamer. This causes an imbalance of the assignment of the streams.

CSCtw89998

Symptom:

The following assert is seen:

CALYPSO ASSERT: "!getDiskLookAhead()->canGroupWithinReadAheadLimit(earlier AdjacentDiskIo, diskIo)" failed in file"/build/cdsbuild/workspace/cdstv_release_builds/ cdstv_2.4.2-b39/cds/cserver/lom/LookAheadElevator.cpp", line 64 Entering kdb current=0xffff8100a6ec1040, pid 4647) on processor 2 due to KDB_ENTER()

Conditions:

If the tunable "echo x > /proc/calypso/internal/restart_adapter_index"is executed with an adapter number (the value located in x) outside the bounds of the legal adapters in the system, it causes a CServer crash.

CSCtu45475

Symptom:

Both primary and backup Streamers crash simultaneously in selectStreamPlayer().

Conditions:

The Setup server is sending three successive play requests just as the first segment of a multi-segment play list is about to end (within the last two seconds of the end). See the description about replicating this issue below.

Replicating the issue:

1. Start a stream with a playlist with at least two segments.

2. Send three play requests successively that are timed to play just as the first segment is about to complete and while it is preparing to transition to the next play list segment.

3. The first play request for 1X should be sent about 1.3 seconds before the segment transition (before the end of the first segment).

4. Last two requests should be sent back-to-back 200-300ms after the first request is processed and the play-response is sent back to the application. These last two requests are queued and delayed to run 500 ms after the first request, placing them within in the last 800ms of the first segment. The second play request should be a pause, followed by a 1X play request. The delay in the processing of successive play requests is determined by the tunable "cm_minplaytime," which has a default of 500ms.

Placing the processing of the last two play requests within the last 800 ms of the first segment is important, because this is when the play transition starts and the first segment's active play state changes from PLAYING to COMPLETING. This really confuses CServer, getting three play requests just as it is preparing to transition to a new segment.

CSCtu02586

Symptom:

System asserted.

Conditions:

Only occurs on assert and debug code, and the content being streamed live has to be deleted.

CSCtt99042

Symptom:

Streams stop unexpectedly after sending 16 GB of data, without playing all the way to the actual end point.

Conditions:

This issue can happen intermittently when the content used is larger than 16 GB and the content is live (specifically, the content is streamed as it is ingested).

CSCtu37690

Symptom:

System crashes.

Conditions:

Longevity test.

CSCtu12699

Symptom:

When the primary Control server loses link state on all of the fill ports, but does not lose link state on the management network port, it will continue to hold the virtual IP address on the management network for the control service. This will allow other servers that may still have fill link-state to become the primary server because the virtual IP address for the control service is no longer in use by the original primary. After another server becomes primary it will make sure that all streams are playing on servers which still have fill link-state. Later when the original primary server gets link state again, the two primary servers detect that there is a conflict and the primary server that has most recently communicated with the backoffice will win and the other server will stop being primary. If the new primary server never communicated with the back end, then the original primary server will take over as primary again. However, because it does not know about the stream state changes that happened while it did not have fill link-state, some of the streams can be lost when the original primary takes over again.

Conditions:

The primary control server must lose link state on all of its fill ports, but not lose link state on its management network port. Another server must become primary, but never communicate with the back office. When the original primary gets fill link state again it will take over as the primary again.

RTSP

CSCtu12643

Symptom:

Streaming when some Streamers are running Release 2.5.2 and some Streamers are running Release 2.3.2 or Release 2.4.1 causes assert "LARGE_POOL_MAX_SIZE."

Conditions:

Streaming content when some Streamers are running Release 2.3.2 or Release 2.4.1 and some Streamers are running Release 2.5.2.

CSCtu90061

Symptom:

RTSP server crashes sometimes during processing of a message that contains an RTSP ANNOUNCE response and a TEARDOWN request in the same packet.

Conditions:

The RTSP message should contain both an RTSP ANNOUCE response and a TEARDOWN request.

RTSP/1.0 200 OK
Session: 20466513
CSeq: 645532
Date: 2011-11-11 10:24:31
M
TEARDOWN * RTSP/1.0
Session: 20466513M
CSeq: 32
User-Agent: Coship MAP-C
Date: 2011-11-11 10:24:31
 
   

Other

CSCtw45759

Symptom:

The ImporterServer stops working. Socket() call fails, cannot check if it is master, and cannot work anymore.

Conditions:

Happens once a month.

Upgrading to Release 2.5.3

The supported upgrade path is from Release 2.5.2 to Release 2.5.3.

If the CDS is running an earlier software release, you must first upgrade to Release 2.5.2 before upgrading to Release 2.5.3.

For software upgrade procedures, see the Cisco TV CDS 2.5 Installation, Upgrade, and Maintenance Guide.

Upgrading from Release 2.5.2 to Release 2.5.3

For the upgrade sequence of the CDS devices in your system (CDSM/VVIM and CDS servers [Vault, Streamer, Caching Node, ISV]), see the "Overview" chapter in the Cisco TV CDS 2.5 Installation, Upgrade, and Maintenance Guide.

To upgrade a CDS device, do the following:


Step 1 Download the ISO image file (CDS-TV-2.5.3.iso) and the cdsinstall-2.5.3 script from the Cisco Software Download website. For more information on downloading the software files, see the "Overview" chapter in the Cisco TV CDS 2.5 Installation, Upgrade, and Maintenance Guide.

Step 2 For the CDS servers, offload the device before upgrading the software.

a. From the CDSM GUI, choose Maintain > Servers > Server Offload. The Server Offload page is displayed.

b. From the Server IP drop-down list, select the IP address or nickname of the sever and click Display.

c. Select Enable and click Submit.

d. Ensure the CDS server has been offloaded by checking the protocoltiming log.

Step 3 Log in to the CDS device as user root.

Step 4 For CDS servers, before installing the image file, stop the database with the following command:

# db_shutdown
 
   

Wait until the following command returns no output:

# netstat -an | grep 9999 and #pgrep avsdb
 
   

Step 5 Copy the ISO image file and the cdsinstall-2.5.3 script to the CDS server.

# scp -p <user>@<remote_ip_address>:CDS-TV-2.5.3.iso /
# scp -p <user>@<remote_ip_address>:cdsinstall-2.5.3 /
 
   

Step 6 Run the cdsinstall script to upgrade the ISO image to Release 2.5.3.

# cd /root
# ./cdsinstall-2.5.3  /CDS-TV-2.5.3.iso
 
   

Step 7 For the CDSM or VVIM, when the script has completed, reboot the server.

Step 8 For CDS servers, make sure that the database is not running and reboot the server.

# pgrep avsdb
# reboot
 
   

Step 9 For CDS servers, after the CDS server has been verified as reachable, disable the Server offload.

a. Choose Maintain > Servers > Server Offload. The Server Offload page is displayed.

b. From the Server IP dropdown list, select the IP address or nickname of the server and click Display.

c. Choose Disable and click Submit.

d. Verify the CDS server is online by viewing the status on the Monitor > System Level > System Health page.


Downgrading from Release 2.5.3 to Release 2.5.2

For the downgrade sequence of the CDS devices in your system (CDSM/VVIM and CDS servers [Vault, Streamer, Caching Node, ISV]), see the "Overview" chapter in the Cisco TV CDS 2.5 Installation, Upgrade, and Maintenance Guide.

To downgrade a CDS device, do the following:


Step 1 Download the ISO image file (CDS-TV-2.5.2.iso) and the cdsinstall-2.5.2 script for Release 2.5.2 from the Cisco software download website. For more information on downloading the software files, see the "Overview" chapter in the Cisco TV CDS 2.5 Installation, Upgrade, and Maintenance Guide.

Step 2 For CDS servers, offload the server (see Step 2 in "Upgrading from Release 2.5.2 to Release 2.5.3").

Step 3 Log in to the CDS device as user root.

Step 4 For CDS servers, before installing the image file, stop the database with the following command:

# db_shutdown
 
   

Wait until the following command returns no output:

# netstat -an | grep 9999 and #pgrep avsdb
 
   

Step 5 Copy the ISO image file and the cdsinstall script to the /root directory and run the cdsinstall script to download the software.

# scp -p <user>@<remote_ip_address>:CDS-TV-2.5.2.iso /
# scp -p <user>@<remote_ip_address>:cdsinstall-2.5.2 /
# cd /root
# ./cdsinstall-2.5.2  /CDS-TV-2.5.2.iso
 
   

Step 6 For the CDSM or VVIM, when the script has completed, reboot the server.

Step 7 For CDS servers, make sure that the database is not running and reboot the server.

# pgrep avsdb
# reboot
 
   

Step 8 For CDS servers, after the CDS server has been verified as reachable, disable the Server offload.

a. Choose Maintain > Servers > Server Offload. The Server Offload page is displayed.

b. From the Server IP dropdown list, select the IP address or nickname of the server and click Display.

c. Choose Disable and click Submit.

d. Verify the CDS server is online by viewing the status on the Monitor > System Level > System Health page. (see Step 7 in "Upgrading from Release 2.5.2 to Release 2.5.3" procedure).


Related Documentation

Refer to the following documents for additional information about the Cisco TV CDS 2.5:

Cisco TV CDS 2.5 ISA Software Configuration Guide

http://www.cisco.com/en/US/docs/video/cds/cda/tv/2_5/configuration/isa_guide/tv_cds_2_5_isa_config.html

Cisco TV CDS 2.5 RTSP Software Configuration Guide

http://wwww.cisco.com/en/US/docs/video/cds/cda/tv/2_5/configuration/rtsp_guide/tv_cds_2_5_rtsp_config.html

Cisco TV CDS 2.5 API Guide

http://www.cisco.com/en/US/docs/video/cds/cda/tv/2_5/developer_guide/tv_cds_2_5_apiguide.html

Cisco TV CDS 2.5 Installation, Upgrade, and Maintenance Guide

http://www.cisco.com/en/US/docs/video/cds/cda/tv/2_5/installation_guide/tv_cds_2.5_maint_guide.html

Cisco Content Delivery System 2.x Documentation Roadmap

http://www.cisco.com/en/US/docs/video/cds/overview/CDS_Roadmap.html

Cisco Content Delivery Engine 205/220/250/420 Hardware Installation Guide

http://www.cisco.com/en/US/docs/video/cds/cde/cde205_220_420/installation/guide/cde205_220_420_hig.html

Cisco Content Delivery Engine 110 Hardware Installation Guide

http://www.cisco.com/en/US/docs/video/cds/cde/cde110/installation/guide/cde110_install.html

Cisco Content Delivery Engine 100/200/300/400 Hardware Installation Guide

http://www.cisco.com/en/US/docs/video/cds/cde/installation/guide/CDE_Install_Book.html

Regulatory Compliance and Safety Information for Cisco Content Delivery Engines

http://www.cisco.com/en/US/docs/video/cds/cde/regulatory/compliance/CDE_RCSI.html

Open Source Used in TV CDS 2.5

http://www.cisco.com/en/US/products/ps7127/products_licensing_information_listing.html

The entire CDS software documentation suite is available on Cisco.com at:

http://www.cisco.com/en/US/products/ps7127/tsd_products_support_series_home.html

The entire CDS hardware documentation suite is available on Cisco.com at:

http://www.cisco.com/en/US/products/ps7126/tsd_products_support_series_home.html

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.