This section provides troubleshooting solutions that are related to the Replay Server, which serves sessions for replay to Browser-Based Replay clients.
If you believe that the Replay Server is struggling to render the content, complete the steps listed here to identify render times per page.
- Log in to the Replay Server interface.
- Click the SessionList link.
- Select a session that was loaded. If no session was loaded, you can use the home page of the interface to load one from your local desktop.
- Select a session with a link like the following:
- Click the NavList link. All pages, their render times, and other information are displayed.
- Select individual pages to review their rendered HTML, looking for irregularities.
- You can also check the Page Load Details (PLD) link for each page, where render times and load times are published. Less than 10 seconds for each page is considered a reasonable time.
- If you see load times that significantly exceed 10 seconds:
- If the excessive load time applies to a single page, there may be problems with accessing content referenced on the individual page. Check out the references on the page, and try to load them in your browser.
- If the excessive load times apply to multiple but not all pages, see if you can identify whether the slow times apply to individual servers, which may indicate connectivity or network issues.
- If the excessive load times apply to all pages on the server, verify that the issue applies to multiple sessions. If so, there may be a problem with Replay Server. Contact Support.
Sessions don't replay in BBR due to proxy errors in Replay Server
You can fix the problem of sessions not replaying in BBR due to proxy errors in Replay Server by configuring the Replay Server to use a named account in the domain.
To diagnose this issue, do the following.
- Replay a session in BBR.
- Log in as an administrator to the server hosting the Replay Server. Typically, this server is the Portal Server, too.
- Open a browser window. Navigate to the following:
http://localhost:38000Note: If you connect from the localhost and if authentication is enabled, you may use ssadmin/ssadmin for the username and password.
- In the Replay Server interface, click Cache.
- Review the Cache listing. If you see multiple entries with a byte length of 0 and no content type, then Replay Server is having difficulty communicating with the origin server through the internal Experience Analytics proxy.
If the above information is present, then the Replay Server was configured to use WinInet to access the server of origin. This method of connection cannot use a proxy when running with the local system account, which is the default setting for Replay Server. WinInet is configured based on the settings that are used by the Internet Explorer instance on the hosting server. These settings cannot be configured for a service running as the local system account.
To configure the Replay Server to use a named account in the domain:
- Log in to the server hosting the Replay Server as an administrator.
- In the Administrator's Control Panels, open the Services panel.
- Right-click Replay Server and select Properties.
- Click the Log On tab.
- Click the This Account radio button.
- Enter the domain and user name of the named account in the following format:
- Enter the password twice.
- Click Apply.
- Restart the Replay Server service.
- Configure Internet Explorer: Open the instance of Internet Explorer.
- Select Tools > Options.
- Configure a Proxy server for use in Internet Explorer.
Note: For more information, the product documentation that is accessible through the installed version of Internet Explorer.
- Clear the IE cache within the browser.
- Click OK to close the Options window.
Note: After you configured Internet Explorer, you must restart Replay Server through the Services control panel so that the cache is cleared.
- To verify configuration, you can test the cache settings by using the following URL. It
is processing a static content URL through the Replay Server on the local machine:
- If the above URL displays an image, then the configuration is working.
- If not:
- Try substituting a different URL after
href=, which points to a known static content object on your web application.
- If that fails, revisit the configuration settings with your IT staff.
- Try substituting a different URL after
Page not rendered
In some cases you might receive a
Page not rendered message when Replay
Server tries to render a page.
During replay, the response content may be replaced by the following error message:
Page not rendered. Pages that contain AJAX responses with a text/html content type or or malformed HTML are not rendered. Consider adding a replay rule to remove this page.
If the above message appears, then the Replay Server was unable to properly render the page. There could be a number of different reasons for why the page was unable to be displayed. The simplest solution is to remove the page from replay.
To remove a page from replay:
- In BBR, right-click the currently selected page in the Navigation List.
- Select Remove This Page from Replay.
- When the session next replays for any Experience Analytics user, it is skipped during replay.
Device size issues in native replay
There might be scenarios where customers visit your mobile application using devices with very small display dimensions, or scenarios where the device dimensions are captured incorrectly.
- removes the mobile skin
- applies no sizing to the replay frame
- presents the following warning
Device size is less than the threshold. Mobile skin is removed. Please refer to the documentation for more details on this warning.
Use the following procedure to adjust replay screen dimension values so that you can replay sessions that were either captured incorrectly, or that were captured from devices with dimensions smaller than the defined threshold.
Go to the Portal\WebApp\js directory and open the file named
- Edit the values in minDeviceWidth and minDeviceHeight
- Save your changes.
- Clear the browser cache to view the changes.
By modifying the variables in
replayConfig.js, Browser Based Replay is able to
replay the session correctly.
Any changes you make to
replayConfig.js will not be overwritten if you upgrade
to a new version.
If you want to apply the edits made to
replayConfig.js to a new release, you can
merge the changes in
replayConfig.js with the file in
Unable to replay sessions that were found in cxReveal database
When results are returned from a cxReveal search, it may not be possible to replay the session. When you select the session to replay from the session list, the session may fail to load in Browser Based Replay.
While there are multiple possible reasons as to why the session cannot be retrieved, the issue may be caused by some of the timestamps in the session data.
When a hit is reassembled by the CX Passive Capture Application, the PCA attempts to locate and
generate timestamp information. If this information is malformed or missing, the PCA writes the
01/01/1970 by default.
When this hit is passed to the Processing Server, the following things happen in the order listed below:
- The session attribute information in the hit is processed and written to the cxReveal search database.
- The hit is written to a session archive file with the above timestamp.
- Once per hour on the hour, the session archive file is purged, as the data in it is considered to be too old for storage in the Processing Server.
So, when a cxReveal user performs a search for this session data, the Search database indicates that the data exists in the Processing Server, yet it might be purged. When cxReveal attempts to access these session files, they are not found because of the bad timestamp values.
To test, complete the following steps:
- Through TMS, locate the directory where the session files are stored.
- Near the end of an hour, log in to the Processing Server as an administrator.
- Navigate to the directory that you found through TMS.
- Locate any files that contain the 1970 timestamp in their file name. The file name
pattern should look like the following:
- Using search, try to retrieve a session from this archive.
- If you are able to locate these sessions, replay the session through BBR and attempt to
ascertain why the timestamp value in the request is corrupted.
Timestamp information is stored in the
[timestamp]section of the request.
Authentication issues with replay
If your Experience Analytics system is operating in an authenticated environment, you may experience some issues during replay. If replay references some files stored on an authentication server whose permissions are not included in Experience Analytics user accounts, Experience Analytics users cannot retrieve those files and may not be able to experience the session as the visitor created it.
- If the file behind the authentication server is an image file, then the image is missing from the screen in the browser-based or RTV replay.
To correct the replay issue with authentication, you can make one of the following changes:
- Move the referenced files outside of the authentication server.
You can place them somewhere within your corporate firewall in a location that is accessible to Experience Analytics accounts.
- Copy the referenced files outside the authentication server.
If you don't want to make changes to the web application, you can create a copy of the referenced files in an accessible location. From within replay, you can create rules to map to this new location.Note: Each time that these files are updated on the live web application, you must make the updates available to Experience Analytics when session data begins to reference and require them.
Error during Replay of Archived Sessions
You might receive an error message indicating that the session could not be loaded during Replay of Archived Sessions.
For archived sessions, you may see the following error message:
The session <session number> in Canister LSSN_* cannot be loaded: LSSN open failure on <Server name>.
- To fix, you can request the corresponding TLX files from Search Server from the index/Portal machine or the Canister machine, or you can use the Canister session ID to access.
- If neither of the above works, request the TLC file from the Search Server.
- If that works, quit Acoustic™ Experience Analytics (Tealeaf) CX and verify that the Acoustic Experience Analytics (Tealeaf) CX Server settings for the two-machine configuration have correct values through the Portal.
- Try to replay again.