Downloads |
 Feedback
|
Table Of Contents
Release Notes for Cisco TV CDS 3.0.1
System Monitoring Enhancements
Server-Level Configuration Backup and Restore
MIB Table for Streamer Bandwidth by Content Type
Meshed Streamer Support for Gigabit Ethernet Streaming
nDVR Support for NGOD Deployment
Split-Domain Management with CCP
NGOD Deployment Support Local Vaults
Upgrading from Release 2.5.2, 2.5.3, 2.5.5, or 2.5.6 to Release 3.0.1
Downgrading from Release 3.0.1
Obtaining Documentation and Submitting a Service Request
Release Notes for Cisco TV CDS 3.0.1
These release notes cover Cisco TV CDS Release 3.0.1.
Revised: July 2012 OL-27184-01Contents
The following information is in the release notes:
•
Obtaining Documentation and Submitting a Service Request
New Features
The features supported in Release 3.0.1 are grouped as follows:
All Environments
The following features are supported for all environments:
•
•
•
Playlist Enhancements
The following playlist enhancements have been added in Release 3.0:
•
•
•
•
Skip Missing Playlist Element
If the CDS cannot locate the content referenced by a playlist element, the playlist element is skipped and streaming continues with the next element in the playlist.
Note
Whether playing in the reverse direction or forward direction, if a playlist element references missing content, the element is skipped and streaming continues with the next element in the playlist in the same play direction. If a jump or resume command resolves the starting NPT to a location in the playlist that references missing content, streaming continues with the next playlist element in the direction indicated by the command. If there are no more elements in the play direction or in the direction indicated by the command, streaming stops.
When a playlist element is skipped, the following logging occurs:
•
•
–
–
•
Mid-Roll Advertisement Placement Accuracy
When playlist elements use normal play times (NPTs) for the element start and end times, the Cisco TV CDS software converts the NPT values to file offsets for mid-roll placement of advertisements. The conversion from NPT values to file offsets is accomplished by using a straight-line rate-based computation, which is adjusted to the nearest I-Frame offset.
Release 3.0 introduces the option to use the presentation time stamp (PTS) values to convert the NPT values for mid-roll placement of advertisements, instead of using the file offsets. PTSs are included in the MPEG-TS and are used by the set-top decoder to synchronize separate elementary streams (video, audio, subtitles, and so on). Using PTS values to insert advertisement playlist elements is preferable to converting NPT values to file offsets, because PTS values more closely match the user-observed playback time.
When the file offsets are used, the NPT values are used to identify the starting and ending frames of the playlist content segment and are based on the order of the content segments in the content file.
When the PTS is used, the NPT values are used to identify the starting and ending frames of the playlist content segment and are based on the PTS, which is the display order of the content segments in the file. The display order may not be the same as the file order. Some frames have to be processed or decoded before other frames, because subsequent frame decodings depend on previously decoded frames, even though the previously decoded frames are meant to be displayed at a later time.
Configuring Conversion Mode for Playlist Ranges
By default, the CDS is configured to use the file offsets for mid-roll placement of advertisements. To use PTS values, change the setting of the Conversion Mode field on the Configure > System Level > MPEG Tuning.
Relax Forward Trick-Mode Restriction After Initial Playback
Previously, if trick-mode restriction is configured on a playlist element and a fast-forward command is issued, the restricted element ignores the fast-forward command and plays the content at normal speed.
In Release 3.0, if the restricted element has been played once from beginning to end at normal speed in a specific session, then the fast-forward trick-mode restriction is relaxed for that element in that session and any further fast-forward commands on the restricted element are honored. This relaxation only applies for that session. Other sessions using the same playlist must play the restricted playlist element at least once at normal speed before the fast-forward command is honored for the restricted element.
Enforce Trick-Mode Restriction for Jump Play Commands
In Release 3.0, trick-mode restricted play elements are enforced and the viewer is not allowed to skip over restricted play elements by using chaptering, dragging, or jumping. Jumping and dragging playback commands move the current NPT to a new location in the forward direction.
Forward jumps are not allowed if they are initiated from within a fast-forward-restricted playlist segment. If the forward jump is initiated from within a playlist segment that permits fast-forward tricks, but jumps across, or into, one or more fast-forward-restricted segments, the jump is abbreviated to the point where the nearest (relative to the current playback position) fast-forward-restricted segment begins. Playback resumes at normal speed at that point, if Fast Forward Resume is configured (only on ISA environments). If no further play commands are issued, and if the Fast Forward Resume option has been configured, when the end of the fast-forward-restricted segment is reached, the original jump command resumes as though the jump had been initiated from that point.
If the first playback command of a session is a for normal speed with a starting NPT other than the beginning of the content (NPT = zero), it is assumed that the session is resuming playback after previously playing through the preceding playlist elements, and therefore the fast-forward trick-mode restriction is relaxed.
System Monitoring Enhancements
Release 3.0 supports the following system monitoring enhancements:
•
Monitoring CDS Server Roles
System Health page (Monitor > System Level > System Health) displays the following information:
•
–
–
–
–
–
–
•
Monitoring CDSM and VVIM Failover
The SNMP agent runs on the CDSM and VVIM and monitors interfaces, Linux file system, services, and failover (primary and backup status change) on these servers.
The SNMP agent supports only a subset of the TV CDS-specific management information bases (MIBs), object IDs (OIDs), traps, and functionalities supported on the Streamer, Vault, ISV, and Caching Node. Caching and streaming statistics are not applicable.
The following services that run on a CDSM have been added to be monitored by way of the SNMP and GUI:
•
•
•
Table 1 lists the new OIDs to support the CDSM and VVIM monitoring.
Table 2 lists the new SNMP traps to support the CDSM and VVIM monitoring.
The following traps and OID have been changed from supporting only Vaults to supporting Vaults, CDSMs, and VVIMs:
•
•
•
When a CDSM or VVIM fails over, the one that becomes the primary sends a cdstvServerStatusMaster trap, and the one that becomes the backup sends a cdstvServerStatusSlave trap. Master and slave states can be checked at any time using the OID cdstvServerMasterSlaveStatus.
SNMP Agent on a CDSM or VVIM
The SNMP agent on the CDSM must be manually configured, you cannot configure the SNMP settings on the CDSM by using the Configure > Server Level > SNMP page. Check that the snmpd.conf file on the CDSM is properly configured by logging in to the CDSM as user root, going to the /usr/local/share/snmp directory and viewing the snmpd.conf file. If the SNMP settings are not correct, manually configure them by editing the snmpd.conf file.
Alarmed Events
The following alarmed events are supported and displayed in the Alarms table in the CDSM banner:
•
•
•
•
Server-Level Configuration Backup and Restore
Previously, the Bulk Configuration feature only provided importation of specific configuration parameters for CDS servers. In Release 3.0, the Server-Level Configuration Backup and Restore feature augments the Bulk Configuration feature by providing exportation of the server-level CDS server configuration parameters, as well as more comprehensive import of all server-level configuration settings than the Bulk Configuration feature.
Through the Server-Level Configuration Backup and Restore feature on the CDSM GUI, it is possible to backup (export) the server-level configuration for a CDS server or all CDS servers in a system, modify the parameters as appropriate, and restore (import) the configuration to a new CDS server or all the CDS servers in a new system.
The Server-Level Configuration Backup and Restore feature provides backup and restore functions of all server-level configuration parameters for the following groups:
•
•
•
•
In addition to complete backup and restore functionality for all server-level configurations for the specified CDS servers, this feature also offers export and import on each server-level configuration page for all CDS servers managed by the CDSM (or VVIM).
Note
•
•
•
The restore and import function overwrite all pre-existing settings on the following server-level configuration pages:
•
•
•
•
•
•
Adding a New CDS Server into an Existing System
Previously, when adding a new CDS server into an existing system, after running the cdsinstall script to install the software, and the cdsconfig script to initially configure some basic settings, the user needed to log in to the CDSM GUI and manually enter the configuration on each server-level page.
In Release 3.0, with the addition of the Server-Level Configuration Backup and Restore feature, after the running the cdsinstall and cdsconfig scripts, the user can back up the server-level configuration on a CDS server that has similar configuration, modify the values for the new CDS server, and restore the configuration on the new CDS server. After which, only the System-Level and Array-Level configuration needs to be completed for the new CDS server.
Replacing a CDS Server and Complete Backup and Restore
The Server-Level Configuration Backup and Restore feature can be used in combination with the existing procedures for a complete backup and restore of a CDS server. For a complete backup and restore of the configuration files and database files for a CDS server, continue to use the procedure documented in the Cisco TV CDS 3.0 Installation, Upgrade, and Maintenance Guide, which uses the preugrade script to back up the entire CDS server and the upgrade script to restore the entire CDS server. These procedures are used to perform a complete backup and restore of the same CDS server, and to replace a CDS server.
Now, with the Server-Level Configuration Backup and Restore feature, you can back up all the server-level configuration for the CDS server, and just write down the System Level and Array Level settings.
Using the Server-Level Configuration Backup and Restore Feature
Using the Backup and Restore feature involves the following tasks:
•
•
•
Enabling the Backup and Restore Feature
The Backup & Restore page (Maintain > Software > Backup & Restore) and the Import/Export Server Configuration option on the Server Level configuration pages (Configure > Server Level) are displayed when the Bulk Import/Export Configuration is enabled.
To enable the Bulk Import/Export Configuration feature, log in to the CDSM GUI as a user with Engineering access level, and on the CDSM Setup page in the Bulk Import/Export Configuration section click the Enabled radio button and click Submit.
Backup or Restore Specific CDS Servers
The Backup & Restore page offers the ability to backup all the server-level configuration parameters of specific CDS servers, modify the configuration parameters as appropriate, and restore all the server-level configuration parameters to new CDS servers.
After the backup XML configuration file has been created, you can edit the values of the configuration parameters as appropriate for the new CDS server or all CDS servers in the new system.
Export or Import Specific Server-Level Configurations
The Import/Export Server Configuration option offers the ability to export or import the specific server-level configuration for all the CDS servers. The following Server Level configuration pages have the export and import feature:
•
•
•
•
•
•
•
•
•
After the export XML configuration file has been created, you can edit the values of the configuration parameters as appropriate for the new CDS server or all CDS servers in the new system.
Security Features
Release 3.0 includes upgrades to the kernel and Apache server. The kernel upgrade applies to all CDS servers, including the CDSM and VVIM. The Apache server upgrade only applies to the CDSM and VVIM.
With the kernel upgrade, hardening of security for the Linux operating system is achieved. The kernel upgrade also includes updates to disk and LAN drivers that are more robust and support new hardware. The Apache server upgrade improves security against denial of service (DOS) attacks.
Note
The following changes have been made to further improve security on the CDS servers and CDSM/VVIM:
•
•
•
Disabling USB Ports and Password-Protecting the BIOS
The following procedure provides instructions on disabling the USB ports and password-protecting the BIOS. Disabling the USB ports and password-protecting the BIOS provides a way to secure the server from anyone outside the allowed administrative group from accessing the server through the USB port.
If the USB port is required to perform an operation (for example, a software upgrade), the operator can log in to the BIOS using the BIOS password and enable the USB port for the operation. After the operation is complete, the operator logs back in to the BIOS and disables the USB port.
To set the BIOS password and disable the USB ports, do the following:
Step 1
Step 2
Press DEL to runSetupTo enter the BIOS Setup Utility on a CDSM or VVIM, press F2.
The BIOS menu is displayed with the Main tab selected.
Use the Right Arrow and Left Arrow keys to select a menu tab, and the Up Arrow and Down Arrow keys to select a menu item.
Step 3
a.
b.
c.
To set a user password, use the Down Arrow key to highlight the User Password, press Enter, and enter the password in the Create New Password dialog box.
Step 4
a.
b.
c.
d.
Step 5
Use the Right Arrow and Left Arrow keys to highlight Yes and press Enter.
After rebooting the server, to enter the BIOS Setup Utility, you are prompted to enter the BIOS password. To have read/write permission, enter the Administrator password. To have read-only permission, enter the User password.
To enable the USB ports, reboot the server, do the following:
Step 1
Step 2
Press DEL to runSetupTo enter the BIOS Setup Utility on a CDSM or VVIM, press F2.
The BIOS menu is displayed with the Main tab selected.
Step 3
Step 4
Step 5
Step 6
Step 7
Use the Right Arrow and Left Arrow keys to highlight Yes and press Enter.
Digital Video Watermarking
Digital Watermarking was introduced in Release 2.5.2 for the NGOD RTSP environment. Release 3.0 expands support of digital watermarking to the ISA environment and supports encrypted assets.
The Digital Watermarking feature provides the ability to track the source of unauthorized content copying. A watermark is embedded into the content for each end-user. If a copy of the content is found, then the watermark can be retrieved from the copy and the source of the copy identified. The watermark is undetectable by the person viewing the content.
At the time of ingesting the content into the Vault, the portion of the MPEG-2 Transport Stream containing the watermarked data is repeated back to back in the asset to be ingested. The asset also has a special entry in the PMT that points to a stream containing location and identification of the duplicate watermarked frames. When the Vault ingests this content, it captures all information identifying the watermarking data in a special file and removes it from the content. It also captures special metadata related to that content which is used by the Streamer to create a watermarked content that is unique to the requesting user.
When a user requests a session containing a watermarked asset, the Streamer fetches this content along with the special file identifying the location of the duplicate watermarked frames and the content metadata. The content metadata along with the client ID is provided to the watermarking library through the Watermark Application Server, which returns a decision bitmap. This bitmap is used by the Streamer to decide whether to send an original non-reference frame or its watermarked counterpart. The Streamer only sends one or the other, but never both the original and the watermarked frames.
Should a user captures this video and makes it available illegally, the video can be analyzed to reverse engineer the decision bitmap and the source of the video can then be identified.
Enabling Digital Watermarking
Enabling Digital Watermarking differs depending on whether the CDS is for an ISA environment or for an RTSP environment.
Enabling Digital Watermarking for RTSP
Digital Watermarking is enabled by default. To verify the Digital Watermarking application has started, enter the ps -ef |grep db command. The following output line of the ps -ef |grep db command indicates the watermarking application has started:
isa 6983 1 0 Sep20 ? 00:01:56 /home/isa/bss/bin/CDSWaterMarkSvr --serverid 188 --groupid 66 --dbpath /tmp/isadb --logfile /arroyo/log/wmsvr.log --loglevel LOWTo enable Digital Watermarking, run the cdsconfig script on each Streamer and answer yes (y) to the question "Do you want to enable Watermark Server?"
Alternatively, to enable Digital Watermarking manually, log in to the Streamer as user isa and enter the following commands:
$ arroyo stop# pgrep avsdb# pgrep AVSRTSPServer# su -isa$ cd /home/isa/bss/etc$ touch wmsvr.conf$ arroyo start wmsvr$ arroyo start avsdb$ arroyo start rtspEnabling Digital Watermarking for ISA
To enable Digital Watermarking, enable the Watermarking Support option on the CDSM Setup page.
To manually disable the watermarking application on the Streamer, log in as user isa and enter the following commands:
cd /home/isa/WatermarkServer/serverrun: ./stop_wmsrvTo re-enable the watermarking application on the Streamer, log in as user isa and enter the following commands:
cd /home/isa/WatermarkServer/serverrun: ./run_wmsrvTo check the status of the watermarking application on the Streamer, log in as user isa and enter the following commands:
cd /home/isa/WatermarkServer/serverrun: ./status_wmsrvMIB Table for Streamer Bandwidth by Content Type
The cdstvStatsByContetntTypeTable has been added to the CISCO-CDSTV-CS-STATS-MIB to provide reporting of Streamer ingress and egress bandwidth differentiated by content type. Table 3 describes the object IDs of cdstvStatsByContetntTypeTable.
ISA Environments
The following features are supported for ISA environments:
•
ISA Reason Code Extension
Release 3.0 provides extensions of ISA DSM-CC reason codes used in server-initiated tear down for sessions. This feature includes event codes leading up to stream destroy in the communication between CDS and backoffice.
The ISA Reason Code Extension feature has the following behaviors:
•
•
•
•
Note
Configuring the LSCP Timeouts and Reason Codes
The following CDSM GUI pages provide the ability to configure the LSCP timeout and LSCP reason code values:
•
•
Meshed Streamer Support for Gigabit Ethernet Streaming
Previously, gigabit Ethernet streaming was only supported on single site steering, which uses only one Stream Group to serve streams to all QAM devices. In Release 3.0, gigabit Ethernet streaming is supported on multi-site steering, which uses more than one Stream Group to serve streams to QAM devices.
With multi-site steering for gigabit Ethernet streaming, the following configuration settings are possible:
•
•
•
Note
RTSP Environments
The following features are supported for RTSP environments:
•
•
•
Capacity Enhancements
Release 3.0 supports 600,000 assets for RTSP environments.
The 600,000 assets supported for the RTSP environment has the following limitations:
•
•
•
Each Vault supports a maximum of 600,000 Global Object IDs (GOIDs). GOIDs are used for each asset and for each trick-mode file associated with each asset. The maximum number of assets supported on a Vault varies depending on the number of trick modes configured (the maximum number of trick modes is 12). The maximum number of assets supported in the CDS is determined by the number of trick modes configured and the number of Vaults in the system.
MSA Trap Enhancements
The SNMP trap (cdstvMSAEvent) that supports Managed Services Architecture (MSA) events is now enhanced with additional information. For ingest MSA events, the following information is included:
•
•
For streaming MSA events, the following information is included:
•
•
Note
nDVR Support for NGOD Deployment
The nDVR feature for the RTSP NGOD deployment integrates with Videoscape and provides the following capabilities:
•
•
•
•
•
•
In previous releases, Streamers received cache-fill content from Vaults, Caching Nodes, and other Streamers by way of the Cisco Cache Control Protocol (CCP). For RTSP NGOD deployments, the Streamers received cache-fill content from Vaults, Caching Nodes, and other Streamers by way of the C2 protocol.
In Release 3.0, Streamers are able to receive cache-fill content from CDS servers (by using CCP or the C2 protocol) and third-party sources. The Streamers can route cache-fill requests to Vaults, Caching Nodes, and other Streamers for VOD content, and to third-party sources for network digital video recorder (nDVR) recordings.
The nDVR feature supports unique copy content distribution from a third-party source (for example, nDVR Recorder) to the Streamer, and from the Streamer to end-user devices, which can be an IP set-top or QAM device.
Asset Metadata
Each content an end-user requests from a device has a unique title ID. For each content, there are different versions based on the encoding that is compatible with the end-user device (for example, high definition [HD] or standard definition [SD] for a STB or mobile device, as well as resolution formats), which are identified by content IDs. When a request for content is sent from the end-user device to the backoffice, it includes the title ID. The backoffice maps the title ID to the content ID for the content that is compatible with the requesting device. The backoffice uses the content ID when communicating with the Streamers on what content object to stream to the device.
For some CDNs, the content ID is a combination of the ADI Product ID and Asset ID (PAID), and it is used to convey both VOD and DVR content. Other CDNs send the content ID from the backoffice to the Streamers in a URI. For the RTSP NGOD deployment, nDVR content is identified with a URI, and VOD content is identified with a PAID.
Each unique content can have several unique data objects required for playback; such as the normal video object for standard forward playback, video objects for trick-mode content, and an index file used to map playback time offsets to corresponding data offsets within the various video files. This information can be referred to as vendor-specific content metadata, or asset metadata.
The Cisco TV CDS software uses a global object ID (GOID) to identify the different video and index data objects for a unique content. The TV CDS software contains an association of the content ID with the various GOIDs used to store the different objects for the content.
To support nDVR, Streamers use the third-party object identifier in cache-fill requests. The Streamer not only stores the content ID to GOID mappings, but also a GOID mapping to an external object identifier which is generated by the third-party vendor. In addition, to support cache-fill from third-party vendors, Streamers generate the GOIDs. The generated asset metadata is revalidated to ensure specifically that the PAID-to-GOID-to-external object mappings are still valid.
Cache-Fill Routing
Streamers are used for streaming out regular VOD content sourced from other CDS servers or DVR content sourced from the Recorders. The Streamers route the cache-fill request to the appropriate source based on the content type, which is derived from the asset name space.
A Streamer must know the origin from which the needed object is sourced when performing cache-fill. Normally, a Streamer is configured with static routes for cache-fill. The Streamer must be configured with different source routes for the different content types.
For VOD content, the content identifier is a PAID. For DVR content, the content identifier is a URI, which contains the hostname or IP address of the third-party source (nDVR Recorder).
nDVR Architecture
The C2 protocol is used for cache-fill of DVR content from the nDVR Recorders.
A request for VOD content is identified by the Provider ID and Asset ID (PAID). A request for DVR content is identified by a URI. The Setup server receives the URI or PAID over the R2 protocol in a NGOD RTSP deployment.
The R2 setup request from the backoffice to the Setup server sends a URI for DVR content to be played. The URI includes the routing and protocol information necessary to cache-fill the DVR content. Content is identified by a URI instead of a PAID.
Cut-Through Support
DVR content can be categorized as unique copy or common copy. Unique copy is a recording of content that belongs to a single subscriber. The Streamers perform cache-fill of unique copy recordings directly from the Recorders. Consideration is made such that any unique video content that is cached is only performed for a transitory period.
Note
For unique copy recordings, there is no cache gain benefit of a hierarchical caching system, as the recordings cannot be shared across subscribers; therefore, the CDS servers do not cache unique copy DVR content.
Integration with Legacy VBOs
The nDVR feature integrates with legacy video backoffice (VBO) systems; such as Seachange, Axiom, and Ericsson Openstream.
Dynamic Trick-Mode Files
Normally, trick-mode files are generated by the Vaults at the time of ingest. For DVR content, trick-mode files are generated dynamically by the Streamers.
To enable trick-mode file generation for DVR content, choose Configure > System Level > MPEG Tuning, for Dynamic Trickmodes select Enabled, and click Submit.
If Streamers are found that have a current Dynamic Trickmode value that is different than the value on the MPEG Tuning page, an alert is displayed in the sidebar indicating the issue and listing the Streamer IP addresses or host names. Additionally, the Server Setup page displays the current setting for Dynamic Trickmode. there will be a read only field identifying the current setting for the selected server.
To set the trick-mode speeds for the Dynamic Trickmode feature, choose Configure > System Level > Ingest Tuning, set the speeds, and click Submit. The Ingest Tuning page is normally used to set the trick-mode speeds used by the Vault to generate the trick-mode files, but if Dynamic Trickmodes is enabled, the Ingest Tuning page displays on the Stream Manager for setting the trick-mode speeds for the Dynamic Trickmode feature on the Streamers.
Split-Domain Management with CCP
In previous releases, split-domain management is supported in the following network designs:
•
•
Release 3.0.1 supports VVI using RTSP session control and Cisco Cache Control Protocol (CCP) as the cache-fill protocol.
NGOD Deployment Support Local Vaults
Release 3.0 supports local Vaults in a VVI system with split-domain management through a combination of the Ingest Steering feature and the Vault Group feature.
Enhancements
The following enhancements have been added in Release 3.0.1:
•
Supported Environments
Release 3.0.1 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 3.0.1 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 3.0.1 does not run on the CDE100, CDE200, CDE300, and CDE400 hardware models.
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:
In extreme conditions of initializing services, when the system is starting, the system fails.
Conditions:
When a Streamer is being booted, a very rare race condition may occur causing a null pointer to be created thus causing an exception and the server to fail.
Workaround:
Reboot the Streamer.
•
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:
Occasionally, the Monitor > Server Level > NIC Monitor > Graph Ports page display does not match exactly the received Mbps and transmit Mbps reported by way of the ifstat for some CDS servers.
Conditions:
This appears almost randomly, and may be a temporary condition because of congested traffic between the CDS server and the CDSM.
Workaround:
There is no workaround at this time and this condition is rarely seen.
RTSP
•
Symptom:
RTSP Setup failed and error thrown as ""RTSP/1.0 771 Server Setup Failed - Asset Not Found"
Conditions:
1.
2.
3.
Workaround:
None.
•
Symptom:
Streamers take about 13 seconds to respond to a Session Setup request.
Conditions:
During load test on Streamers running Release 2.3.3 or Release 2.5.2 with RTSP-BNI Backoffice, responses to Session Setup requests takes between 13 and15 seconds.
Workaround:
None.
•
Symptom:
RTSP Session contents are not deleted properly in AVSDB.
Conditions:
When content streaming is very high, the database transmits and the transmits in the Thread Pools are high, which results in updates to the database in a mixed asynchronous and synchronous manner. This results in the orphans sessions in the database.
Workaround:
Stop AVSDB on all Streamers in that Stream Group and enter the following command on each CDS server:
rm rtsp_session.db rtsp_annex.dbStart AVSDB on Streamers in that Stream Group.
Statsd
•
Symptom:
When any of the Fail Ingest Settings parameters are updated from the CDSM/VVIM page (Configure > System Level > Ingest Tuning), the values are not updated in the /proc file tunables on the Vaults.
Conditions:
Fail Ingest Tuning is enabled from the CDSM/VVIM Setup page, and individual parameters are changed on the Ingest Tuning page.
Workaround:
Update the tunables directly on the Vault by echoing the appropriate values into the tunables, for example:
echo 1 > /proc/calypso/tunables/bRateErrorFailsIngestComplete list of tunables is as follows:
PSI Errors: bPSIErrorFailsIngest (1 = Enabled, 0 = Disabled)Bit Rate Errors: bRateErrorFailsIngest (1 = Enabled, 0 = Disabled)Error Count Method: bEveryNMinutes (1 = Per Minute, 0 = Per Sample)Number Of Minutes: nEveryNMinutes (minutes)Discontinuity Rate: nDiscErrorsFailIngestNumber Of Picture Gaps: nPicGapsFailIngestContinuity Counter Errors: nCCErrorsFailIngestNumber Of Sync Loss Errors: nSyncLossesFailIngestPicture Gap Duration: nPicGapsinHSFailIngest (hectoseconds)Sync Loss Duration: nSyncLossesinHSFFailIngest (hectoseconds)
Note
Vault
•
Symptom:
The CDS server kernel debugger displays the following error:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000818IP: [<ffffffffa036a4c8>] CM::Object::fillSegment+0x468/0x19c0 [avs_cserver]Conditions:
The system must have a heavy load of disk traffic (nearly 100% of capacity) and a heavy load on the network or the remote vaults containing the content. When the system tries to initially read the content and fails, it retries reading both a local copy and filling a remote copy. When the remote read and the local read fail at precisely the right (wrong) time, the data read object leaves the cache data object (ObjectSegment) in an invalid state that allows the null pointer dereference.
Workaround:
None. It is highly unlikely to occur.
Resolved Caveats
This section contains he resolved caveats in Cisco TV CDS Release 3.0.1. Not all resolved issues are mentioned here. The following list highlights resolved caveats associated with customer deployment scenarios.
CServer
•
Symptom:
Streamer goes into kernel debugger (kdb) mode when streaming live nDVR content in the DEBUG build.
Conditions:
Stream Live nDVR content in the DEBUG build.
•
Symptom:
On first-generation hardware (part numbers not starting with "CDE-"), e1000e driver fails to load. The following message can be seen:
Loading e1000e driverFailed to load e1000e driverThis message appears from the /arroyo/test/run script, which is executed from /etc/rc.local.
Conditions:
This error appears at startup or after reboot as the drivers are loading. The /arroyo/test/run script tries to load the e1000e drivers that are not supported on first-generation hardware (part numbers not starting with "CDE-"). First-generation hardware supports e1000 drivers, which should be loaded instead.
•
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.
Monitoring
•
Symptom:
The following symptoms have been observed:
1.
2.
3.
Conditions:
Any CDE250.
Upgrading to Release 3.0.1
The supported upgrade paths are the following:
•
•
•
•
If the CDS is running an earlier software release, you must first upgrade to one of the supported releases before upgrading to Release 3.0.1.
For software upgrade procedures, see the Cisco TV CDS 3.0 Installation, Upgrade, and Maintenance Guide.
Upgrading from Release 2.5.2, 2.5.3, 2.5.5, or 2.5.6 to Release 3.0.1
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 3.0 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-3.0.1.iso /# scp -p <user>@<remote_ip_address>:cdsinstall-3.0.1 /Step 6
# cd /root# ./cdsinstall-3.0.1 /CDS-TV-3.0.1.isoStep 7
Step 8
Step 9
# pgrep avsdb# rebootStep 10
a.
b.
c.
d.
Downgrading from Release 3.0.1
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 3.0 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.6.iso /# scp -p <user>@<remote_ip_address>:cdsinstall-2.5.6 /# cd /root# ./cdsinstall-2.5.6 /CDS-TV-2.5.6.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 3.0:
•
•
•
http://www.cisco.com/en/US/docs/video/cds/cda/tv/3_0/developer_guide/tv_cds_3_0_apiguide.html
•
http://www.cisco.com/en/US/docs/video/cds/cda/tv/3_0/installation_guide/tv_cds_3_0_maint_guide.html
•
http://www.cisco.com/en/US/docs/video/cds/overview/CDS_Roadmap3.x.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/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.
