Downloads |
 Feedback
|
Table Of Contents
Release Notes for Cisco TV CDS 2.5.5
TrickModeListHistory and StreamListHistory APIs
Upgrading from Release 2.5.2 or 2.5.3 to Release 2.5.5
Downgrading from Release 2.5.5 to Release 2.5.2 or 2.5.3
Obtaining Documentation and Submitting a Service Request
Release Notes for Cisco TV CDS 2.5.5
These release notes cover Cisco TV CDS Release 2.5.5.
Revised: March 2012 OL-26988-01Contents
The following information is in the release notes:
•
Obtaining Documentation and Submitting a Service Request
Enhancements
The following enhancements have been added in Release 2.5.5:
•
•
•
•
TrickModeListHistory and StreamListHistory APIs
TrickModeListHistory and StreamListHistory APIs provide the ability to list content playlists for each session that occurred in the specified time period.
The TrickModeListHistory API augments the TrickModeHistory API by providing information on single content session and multi-content (playlist) sessions.
The StreamListHistory API augments the StreamHistory API by providing information on single-content sessions and multi-content (playlist) sessions.
The TrickModeHistory and the StreamHistory APIs still are available, and provide information for single-content sessions.
StreamListHistory
The StreamListHistory request-response message returns a list of single content streams and multi-content streams (playlists) for all sessions that occurred during the specified period of time.
Note
Request
Required: StreamListHistory
Required: fromDate
Required: toDate
The length of time between fromDate and toDate must not exceed one hour. The request example uses the maxRows, fromOffset, and dateFormat optional parameters.
Request Example
http://209.165.201.1/everstream/api.php?messageType=StreamListHistory&fromDate=1233856800& toDate=1233860399&maxRows=1000000&fromOffset=0&dateFormat=secResponse
One of the following HTTP status codes are returned:
•
•
•
The StreamsResponse element is returned in the XML body response.
Table 1-1 describes the XML body elements and attributes returned in the StreamsResponse element.
Table 1-1 StreamsResponse for StreamListHistory
Stream
—
list element
Element that contains the stream information.
startTime
xs:integer
Stream start time (since start of UNIX epoch time).1
endTime
xs:integer
Stream end time (since start of UNIX epoch time).1
dbTime
xs:integer
Time (since start of UNIX epoch time) this stream was recorded in the database.
tsidOutputs
xs:string
TSID2 output.
macAddress
xs:string
MAC address of the STB3 .
serverIpAddress
xs:string
IP address of the Streamer.
serviceGroup
xs:integer
Service Group used to send the stream.
sessionID
xs:string
Session ID associated with this stream.
streamType
xs:string
Stream type (either user or sys) is used to differentiate between user-requested streams and system streams.
Content
Subelement
Element that contains information about a content object.
Content
contentName
xs:string
Name of the content.
bitrate
xs:integer
Rate the content is being streamed, in bits per second.
assetName
xs:string
Name used in the ADI4 metadata for a group of content objects that make up one asset.
contentLength
xs:integer
Duration, in milliseconds, of the content.
segmentIndex
xs:integer
Identifies the content location in a playlist; for example, a value of 0 is the first content, 1 is the second content, and so on.
1 UNIX epoch time is 1970-01-01T00:00:00Z.
2 TSID = Transport Stream ID.
3 STB = set-top box.
4 ADI = asset distribution interface.
Response Example
<?xml version="1.0" encoding="UTF-8"?><StreamsResponsedateFormat="sec"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="../../src/xsd/Streams.xsd"><Stream startTime="1331582148" endTime="1331592074" dbTime="1331592672" tsidOutput="0" macAddress="1331582148:1" serverIpAddress="" serviceGroup="1" sessionID="1331582148:117644001" streamType="user"><Content contentName="DK00694_019.mpg" assetName="ArroyoAsset" bitrate="3750000" contentLength="3599212" segmentIndex="0" /></Stream><Stream startTime="1331582456" endTime="1331592708" dbTime="1331593306" tsidOutput="0" macAddress="1331582456:6" serverIpAddress="172.22.98.74" serviceGroup="1" sessionID="1331582456:693585001" streamType="user"><Content contentName="StaMain.mpg" assetName="arroyo.tv::AVSC0000000000000402" bitrate="3371250" contentLength="6334786" segmentIndex="0" /></Stream><Stream startTime="1331582761" endTime="1331592708" dbTime="1331593306" tsidOutput="0" macAddress="1331582761:2" serverIpAddress="172.22.98.74" serviceGroup="1" sessionID="1331582761:281367002" streamType="user"><Content contentName="StaMain.mpg" assetName="arroyo.tv::AVSC0000000000000402" bitrate="3371250" contentLength="6334786" segmentIndex="0" /><Content contentName="Test_BBQ.mpg" assetName="ArroyoAsset" bitrate="3750000" contentLength="2661405" segmentIndex="1" /><Content contentName="StaMain.mpg" assetName="arroyo.tv::AVSC0000000000000402" bitrate="3371250" contentLength="6334786" segmentIndex="2" /></Stream><Stream startTime="1331582063" endTime="1331592708" dbTime="1331593306" tsidOutput="0" macAddress="C0A800F0DB2A" serverIpAddress="172.22.98.74" serviceGroup="1" sessionID="C0A800F0DB2A::1::3232235818::333" streamType="user"><Content contentName="StaMain.mpg" assetName="arroyo.tv::AVSC0000000000000402" bitrate="3371250" contentLength="6334786" segmentIndex="0" /></Stream></StreamsResponse>TrickModeListHistory
The TrickModeHistory request-response message returns a list of trick-mode actions for single content streams and multi-content streams (playlists) for all sessions that occurred during the specified period of time.
Request
Required: TrickModeHistory
Required: fromDate
Required: toDate
The length of time between fromDate and toDate must not exceed one hour. The request example uses the maxRows, fromOffset, and dateFormat optional parameters.
Request Example
http://209.165.201.1/everstream/api.php?messageType=TrickModeHistory&fromDate=1235012400&t oDate=1235015999&maxRows=100000&fromOffset=0&dateFormat=secResponse
One of the following HTTP status codes are returned:
•
•
•
The TrickModesResponse element is returned in the XML body response.
Table 1-2 describes the XML body elements and attributes returned in the TrickModesResponse.
Table 1-2 TrickModesResponse for TrickModeListHistory
TrickMode
—
list element
Element that contains the trick-mode information.
NPT
xs:integer
The current normal play time. NPT1 starts at 0 at the start of the video, advances in real time in normal play mode, decrements in reverse mode, and is fixed when the video is paused.
errorText
xs:string
Information on any errors that occurred during trick play.
eventTime
xs:integer
Time (since start of UNIX epoch time)2 this trick mode was recorded in the database.
scale
xs:string
The direction and speed of play.
sessionID
xs:string
Session ID associated with this stream.
segmentIndex
xs:integer
Identifies the content segment the trick-mode occurred in. If the content object is not part of a playlist, but instead a single content object, the value is zero (0).
type
xs:integer
LSCP op code.
mode
xs:integer
LSCP stream mode.
response
xs:integer
LSCP response code.
Note
1 NPT = normal play time.
2 UNIX epoch time is 1970-01-01T00:00:00Z.
Response Example
<?xml version="1.0" encoding="UTF-8"?><TrickModesResponsedateFormat="sec"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="../../src/xsd/TrickModes.xsd"><TrickMode NPT="0" errorText="" eventTime="1331582456" scale="0" sessionID="1331582456:693585001" segmentIndex="0" type="0" mode="0" response="0" /><TrickMode NPT="0" errorText="" eventTime="1331582456" scale="1" sessionID="1331582456:693585001" segmentIndex="0" type="160" mode="4" response="0" /><TrickMode NPT="0" errorText="" eventTime="1331582456" scale="1" sessionID="1331582456:693585001" segmentIndex="0" type="6" mode="4" response="0" /><TrickMode NPT="576920" errorText="" eventTime="1331583034" scale="10" sessionID="1331582456:693585001" segmentIndex="0" type="6" mode="4" response="0" /><TrickMode NPT="614372" errorText="" eventTime="1331583038" scale="0" sessionID="1331582456:693585001" segmentIndex="0" type="1" mode="1" response="0" /><TrickMode NPT="615791" errorText="" eventTime="1331583046" scale="-10" sessionID="1331582456:693585001" segmentIndex="0" type="6" mode="4" response="0" /><TrickMode NPT="503550" errorText="" eventTime="1331583057" scale="1" sessionID="1331582456:693585001" segmentIndex="0" type="6" mode="4" response="0" /><TrickMode NPT="6334785" errorText="" eventTime="1331588888" scale="1" sessionID="1331582456:693585001" segmentIndex="0" type="161" mode="4" response="0" /><TrickMode NPT="6334785" errorText="" eventTime="1331588888" scale="1" sessionID="1331582456:693585001" segmentIndex="0" type="64" mode="7" response="0" /><TrickMode NPT="6334785" errorText="" eventTime="1331588888" scale="1" sessionID="1331582456:693585001" segmentIndex="0" type="1" mode="1" response="0" /><TrickMode NPT="10154785" errorText="" eventTime="1331588888" scale="1" sessionID="1331582456:693585001" segmentIndex="0" type="161" mode="1" response="0" /><TrickMode NPT="0" errorText="" eventTime="1331592708" scale="0" sessionID="1331582456:693585001" segmentIndex="0" type="65" mode="0" response="0" /><TrickMode NPT="0" errorText="" eventTime="1331582761" scale="0" sessionID="1331582761:281367002" segmentIndex="0" type="0" mode="0" response="0" /><TrickMode NPT="0" errorText="" eventTime="1331582761" scale="1" sessionID="1331582761:281367002" segmentIndex="0" type="160" mode="4" response="0" /><TrickMode NPT="0" errorText="" eventTime="1331582761" scale="1" sessionID="1331582761:281367002" segmentIndex="0" type="6" mode="4" response="0" /><TrickMode NPT="320040" errorText="" eventTime="1331583081" scale="0" sessionID="1331582761:281367002" segmentIndex="0" type="1" mode="1" response="0" /><TrickMode NPT="320040" errorText="" eventTime="1331583089" scale="1" sessionID="1331582761:281367002" segmentIndex="0" type="6" mode="4" response="0" /><TrickMode NPT="329044" errorText="" eventTime="1331583098" scale="10" sessionID="1331582761:281367002" segmentIndex="0" type="6" mode="4" response="0" /><TrickMode NPT="864808" errorText="" eventTime="1331583152" scale="1" sessionID="1331582761:281367002" segmentIndex="0" type="6" mode="4" response="0" /><TrickMode NPT="6334785" errorText="" eventTime="1331588622" scale="1" sessionID="1331582761:281367002" segmentIndex="0" type="161" mode="4" response="0" /><TrickMode NPT="6334785" errorText="" eventTime="1331588622" scale="1" sessionID="1331582761:281367002" segmentIndex="1" type="160" mode="4" response="0" /><TrickMode NPT="8996190" errorText="" eventTime="1331591285" scale="1" sessionID="1331582761:281367002" segmentIndex="1" type="161" mode="4" response="0" /><TrickMode NPT="8996190" errorText="" eventTime="1331591285" scale="1" sessionID="1331582761:281367002" segmentIndex="2" type="160" mode="4" response="0" /><TrickMode NPT="9803463" errorText="" eventTime="1331592094" scale="10" sessionID="1331582761:281367002" segmentIndex="2" type="6" mode="4" response="0" /><TrickMode NPT="15329546" errorText="" eventTime="1331592647" scale="10" sessionID="1331582761:281367002" segmentIndex="2" type="161" mode="4" response="0" /><TrickMode NPT="15329546" errorText="" eventTime="1331592647" scale="10" sessionID="1331582761:281367002" segmentIndex="2" type="64" mode="7" response="0" /><TrickMode NPT="15329546" errorText="" eventTime="1331592647" scale="10" sessionID="1331582761:281367002" segmentIndex="2" type="1" mode="1" response="0" /><TrickMode NPT="15939546" errorText="" eventTime="1331592647" scale="10" sessionID="1331582761:281367002" segmentIndex="2" type="161" mode="1" response="0" /><TrickMode NPT="0" errorText="" eventTime="1331592708" scale="0" sessionID="1331582761:281367002" segmentIndex="0" type="65" mode="0" response="0" /><TrickMode NPT="0" errorText="" eventTime="1331582063" scale="1" sessionID="C0A800F0DB2A::1::3232235818::333" segmentIndex="0" type="7" mode="3" response="0" /><TrickMode NPT="0" errorText="" eventTime="1331592708" scale="0" sessionID="C0A800F0DB2A::1::3232235818::333" segmentIndex="0" type="0" mode="0" response="0" /></TrickModesResponse>Supported Environments
Release 2.5.5 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.5 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.5 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.5 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.5.
Note
Limitations and Restrictions
This release contains the following limitations and restrictions:
•
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
•
Symptom:
Server may errantly (and very temporarily) report system pressure.
Conditions:
When the system is running at full capacity and resources are very low.
•
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 UnitHang' followed by 'NETDEV WATCHDOG: ethX: transmit timed out' errors. Ports1 and 2 don't show any errors and will pass traffic.This issue MAY be resolved by updating to the latest kernel and BIOS. Theuser is encouraged to run an OS that fully supports MSI interrupts.•
Symptom:
Primary-backup status conflict in some servers.
Conditions:
Network partition.
Workaround:
None.
•
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.
•
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.
•
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.
•
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.
•
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.5 has the following LAN transmit and receive maximum limits:
–
–
•
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 0Workaround:
The IP address of the interface to be used in FTP out operations can be specified on the ftp command line.
Configuration
•
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
•
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
•
Symptom:
The following symptoms have been observed:
1.
2.
3.
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
•
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.5. Not all resolved issues are mentioned here. The following list highlights resolved caveats associated with customer deployment scenarios.
CServer
•
Symptom:
The backup Setup server goes into kernel debugger (KDB) mode and stops. When another backup Setup server is selected, it too goes into KDB when the data is synchronized to it.
Conditions:
This problem happens when the primary Setup server is synchronizing the encryption key information for active streams to the backup Setup server. This problem only happens when viewing Motorola encrypted content. Also, to reproduce the problem, usually hundreds of streams need to be running, and the primary Setup server needs to fail over to the backup Setup server several times.
•
Symptom:
Mirroring of content between Vaults is discontinued and a Vault system could fail.
Conditions:
When multiple extreme failures occurs in a Vault system and/or a significant amount of content is being ingested on only one Vault system. In this condition many terabytes of content is needed to be recovered/replicated across the Vault system; all thread groups could become exhausted and no additional threads may be allocated for the recovery operation. The system is not able to recover in a timely manner.
•
Symptom:
No more than 125 Vaults are used for ingest in a system where there are more than 125 Vaults. This includes all Vaults that are interconnected throughout a system.
Conditions;
As Vaults are added to a system, once 125 Vaults have been inter-connected, any additional Vaults are not selected by the ingest system for ingest.
RTSP
•
Symptom:
Streaming og messages in /arroyo/log/rtsp.log are truncated.
Conditions:
Streaming og messages in /arroyo/log/rtsp.log are truncated.
•
Symptom:
Invalid range response at PLAY if first item in the playlist begins at non-zero.
Conditions:
When an RTSP setup request starts from non-zero NPT value, it throws an "Invalid Play Range" response.
SNMP
•
Symptom:
When a script is run to repeatedly walk the Cisco CDS-TV MIBs every few minutes, the agent dies after the walk script runs for a few days.
Conditions:
The snmpd process crashes only when the following conditions are met:
–
–
–
The issue was a result of a missing fclose() which leads to an ever-growing number of open file descriptors, causing the application to eventually crash.
•
Symptom:
When cdstvFillStreamCommittedBW and cdstvFillStreamActualBW values are fetched using SNMP GET or WALK, it is observed that the values seem to be swapped with each other, when compared to the values in the protocoltiming log.
Conditions:
Always, but only for cdstvFillStreamCommittedBW and cdstvFillStreamActualBW.
Builds
•
Symptom:
Installation using an ISO image file on a CDE250 fails.
Conditions:
When an installation on a CDE250 is attempted, the install fails.
Interoperability
•
Symptom:
Start a session in either direction and from any NPT.
Conditions:
Start a session in either direction and from any NPT.
•
Symptom:
Let session complete (go to EOS) in either direction. CDS does not deliver PSE_END_SEGMENT event.
Conditions:
Either session completes in either direction or session terminated in the middle.
•
Symptom:
Let stream reach EOS, it delivers VE_STOP event. This event should be delivered on stream destroy only.
Conditions:
Stream reaches the end.
•
Symptom:
The scale in the Viewer Events are not updated.
Conditions:
Generate Viewer events and look for scale.
Upgrading to Release 2.5.5
The supported upgrade paths are the following:
•
•
If the CDS is running an earlier software release, you must first upgrade to Release 2.5.2 or Release 2.5.3 before upgrading to Release 2.5.5.
For software upgrade procedures, see the Cisco TV CDS 2.5 Installation, Upgrade, and Maintenance Guide.
Note
To upgrade from Release 2.5.1-ES1 to Release 2.5.5, see EDCS- 1138748. The following are described in EDCS-1138748:
•
•
•
Upgrading from Release 2.5.2 or 2.5.3 to Release 2.5.5
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
Step 2
a.
b.
c.
d.
Step 3
Step 4
# db_shutdownWait until the following command returns no output:
# netstat -an | grep 9999 and #pgrep avsdbStep 5
# scp -p <user>@<remote_ip_address>:CDS-TV-2.5.5.iso /# scp -p <user>@<remote_ip_address>:cdsinstall-2.5.5 /Step 6
# cd /root# ./cdsinstall-2.5.5 /CDS-TV-2.5.5.isoStep 7
Step 8
# pgrep avsdb# rebootStep 9
a.
b.
c.
d.
Downgrading from Release 2.5.5 to Release 2.5.2 or 2.5.3
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
Step 2
Step 3
Step 4
# db_shutdownWait until the following command returns no output:
# netstat -an | grep 9999 and #pgrep avsdbStep 5
# 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.isoStep 6
Step 7
# pgrep avsdb# rebootStep 8
a.
b.
c.
d.
Related Documentation
Refer to the following documents for additional information about the Cisco TV CDS 2.5:
•
•
•
http://www.cisco.com/en/US/docs/video/cds/cda/tv/2_5/developer_guide/tv_cds_2_5_apiguide.html
•
http://www.cisco.com/en/US/docs/video/cds/cda/tv/2_5/installation_guide/tv_cds_2.5_maint_guide.html
•
http://www.cisco.com/en/US/docs/video/cds/overview/CDS_Roadmap.html
•
•
http://www.cisco.com/en/US/docs/video/cds/cde/cde110/installation/guide/cde110_install.html
•
http://www.cisco.com/en/US/docs/video/cds/cde/installation/guide/CDE_Install_Book.html
•
http://www.cisco.com/en/US/docs/video/cds/cde/regulatory/compliance/CDE_RCSI.html
•
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.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)
This product contains watermarking technology that is licensed from Verimatrix, Inc., and such functionality should not be used or distributed further by you without any additional license(s) required from Verimatrix, Inc.
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2012 Cisco Systems, Inc. All rights reserved.
