This chapter covers general troubleshooting steps to take if something goes wrong in RealServer. Messages-both informational and error-related-are also described.
If you encounter problems when running RealServer, you can narrow down the problem with the following tasks:
These steps are good ones to check whenever you have trouble with any RealServer features.
First, isolate the problem. Is the problem on the RealServer end, or the client end? Or is there difficulty with the production tools?
When you started RealServer, were there any error messages? If so, look up the message in the index of this document.
There are several possible causes of the Server not starting:
RMServer in the list; the word "Started" in the Status field indicates that it's running.
IPBindings section, or change it to use the single 0.0.0.0 address.
Open the configuration file. If this is a new installation of RealServer, and the configuration file has not been customized, you will need to add the following text to the configuration file. The configuration file is named rmserver.cfg, and is located in the RealServer main directory. Add this text to the very end of the file:
<List Name="IPBindings">
<Var Address_01="0.0.0.0"/>
</List>
The address 0.0.0.0 binds the Server to all IP addresses available on this machine. You can substitute the machine's actual address, instead.
Use the appropriate method for your operating system:
ipconfig.
ifconfig.
Rather than remaining visible, the window closes if the Server encounters an error. Use the following steps to find out what the error is:
Bin directory.
Bin\rmserver rmserver.cfg
The Server will attempt to start, and any error messages will appear on screen. The most frequent causes of this type of problem are an expired license or conflicting port use.
Also, compare your system date to the Issue and Expire date shown on the About page of RealSystem Administrator, and make sure your system date is accurate.
If you know the Server is running, but you aren't able to play any content from it, the ports may be unavailable. To find out, go to a Web browser and type the following:
http://address:port
where address is the name or IP address of your Server, and port is one of the ports that the Server uses: either 554, 7070, or 8080.
A response appears in the browser, such as "File not found."
If you do not get a response, or if you get an error message, either the Server is not running, or it needs to be bound to a specific IP address. Refer to "Distributed Licensing" for specific instructions.
If you are not sure what IP address to use for address, use the instructions in "Determining the IP Address of Your Computer".
If your license files have expired, the Server runs with minimal settings. See "Minimum Licensed Features" for a list of the features that are always available. Contact RealNetworks or your reseller to purchase an updated license.
Once the Server is running, use the instructions in this section to narrow down the source of the problem.
In cases where one computer must talk with another, problems may arise if the DNS name does not resolve correctly. By using IP addresses, and binding RealServer to the correct IP address, you can eliminate DNS resolutions as a potential problem.
Try playing the sample files from the same machine as RealServer. An easy way to do this is from RealSystem Administrator. Click Samples in the left-hand frame. Click any of the samples shown in the right-hand frame.
Next, play the sample files from a different machine, but within your network.
If you get a message that RealPlayer needs to download a new plug-in but is unable to, your firewall may not be configured correctly. See Chapter 9, "Firewalls and RealServer" for information.
Try to play one of your files by typing its URL in the Open Location dialog box of RealPlayer.
If a content creator is doing a live encode, check that he or she has used the correct RealServer information. Make sure that any virtual path he or she typed is one that will be recognized by RealServer.
Review Chapter 4, "Sources of Content", or consult the encoding software's documentation.
Read further in this chapter for help with specific features.
Others in your organization may have information you need, such as available port numbers, or information on bandwidth restrictions.
rmserver.cfg and is located in the main RealServer directory, and search the file for AdminPort.
<Var AdminPort="7845"/>
address and the number you found in Step for AdminPort:
http://address:AdminPort/admin/index.html
When you install RealServer, the setup program asks you for a user name and a password. It uses these for RealSystem Administrator and for any content creators who use version 6 and later encoding software to send material to your RealServer.
If you can't remember your password, you must reinstall RealServer, or, if you have purchased an Upgrades and Support contract, contact the RealNetworks Technical Support department (see "Contacting RealNetworks Technical Support").
JavaScript errors are usually due to an older browser version or the wrong version of RealServer for your operating system. RealSystem Administrator is designed to run with Netscape 4.06 or higher, and Internet Explorer 4.01 or higher.
Problems with on-demand content are usually caused by incorrect link references. Chapter 5, "Understanding Link Formats" has detailed information on the correct place to store your content, as well as how to write the URL itself.
Content directory from a Web server.
If you receive the error "Error retrieving URL \Qfile name and path' (Invalid path)" in the error log, either of the following may be true:
Live unicasting is ready to work as soon as you install RealServer-just remember to include /encoder/ in your links.
Live content does not exist in file format. The data packets are discarded as they are broadcast.
To see which live broadcasts are arriving at your RealServer, use the Java Monitor to look at the connections to your Server. (In RealSystem Administrator, click Monitor. Click the Connections tab.)
You can archive live broadcasts as they arrive at your RealServer, and save them for later use. See "Archiving Live Broadcasts".
Check that the broadcast is getting to the Server. Use the Java Monitor to see which encoded streams are arriving. (In RealSystem Administrator, click Monitor. Click the Connections tab.)
From the machine on which RealServer is installed, check that you can connect to the broadcast.
Make sure you are using the correct format for the link.
encoder mount point if the material is coming from RealProducer Plus 6 or later. Use the live mount point if it is earlier encoding software.
Make sure your access control rules aren't preventing anyone from connecting.
Live archiving is turned off by default. Make sure you've selected Enabled on the RealSystem Administrator Broadcasting>Live Archiving page, and that you have restarted the Server if necessary.
Other possible solutions include:
Be sure to run the g2slta.bat file (Windows) or the g2slta.sh file (UNIX), not the g2slta.exe or g2slta file. The .bat and .sh files set the environment variables correctly.
If you get the message "Data type not supported," you're trying to use G2SLTA to broadcast files that are not supported. G2SLTA can only deliver audio and video files.
Steps involved in troubleshooting splitting fall into two general areas:
Splitting is one of several features controlled by the license you purchased. Click About in the RealSystem Administrator of each RealServer to see if each is licensed for splitting; make certain both are licensed. An error message stating that your RealServer is not licensed for splitting will also appear in the error log, if your license does not permit splitting.
Before investigating any receiver-to-client issues, be sure the transmitter-to-receiver connections are working properly.
Problems with splitting may be related to:
On the receiver computer, use a client to connect to the transmitter to make sure the clip exists and is being broadcasted.
Be certain that you have chosen the same transport method on both the transmitter and the receiver.
Check the error log on the transmitter for messages.
Double-check the URL you created for the split broadcast. The link formats are complex, and creating them accurately is a common problem. You may have everything configured correctly, on both the transmitter and the receiver, but if the link is not right, users will not be able to connect.
Make sure that the receiver can receive a regular unicast from the transmitter. If unicasting is not working, splitting will not work, either. On the receiver machine, make sure you can receive the stream directly from the transmitter: in the client, connect to the transmitter using the direct URL. Use the format referenced in "Unicasted Live Content (from Encoders)".
Make certain there aren't any access control rules on the receiver that prohibit the client from receiving any broadcast or stream.
If the receiver is using multicast to distribute the split broadcast inside the network, look for multicast user list rules that insist that the client receive the broadcast in multicast mode. If the client is not configured for multicast reception, it will not be able to receive the broadcast.
Before setting up multicasting, two conditions must exist:
If these two conditions have been met, use the following information to troubleshoot this feature.
Steps in troubleshooting multicasting fall into two areas:
The following error messages, appearing in the error log, indicate either that you have configured a back-channel multicast in RealSystem Administrator with Delivery Only set to Yes (DeliveryOnly=True in the configuration file), or that it is a scalable multicast that does not have a backup unicast configured:
Clients that are not configured for multicast will show an error message if they click a link to a scalable multicast but the user has turned off multicast in the RealPlayer preference tab. The following message appears:
Make certain your license permits scalable multicast. If you configure scalable multicast, yet it is not included in your license, the following error message appears in the error log:
The message "Error in creating Back-channel multicast session. Please increase the AddressRange configuration variable." indicates that RealServer needs more multicast addresses in order to broadcast in back-channel multicast mode. In RealSystem Administrator, use a larger range in the IP Address Range boxes.
If you configure back-channel multicast by editing the configuration file directly, you may inadvertently omit required sections. Without a ControlList section, multicasting will not work. Add it, using the format shown in "Back-Channel Multicasting Configuration Elements", or use RealSystem Administrator to set up the Client Access List. The error message that appears if this section is missing is:
If the configuration file is in the wrong format, or contains an error, this message appears:
If the configuration file is missing the Sources list (it describes which paths will be multicast), the following message appears in the error log: "Scalable Multicast: Could not find Source List in the configuration file." Add this section using RealSystem Administrator.
Similarly, the message "Scalable Multicast: Could not find MountPoint [or AddressRange or PortRange] configuration variable." shows that the scalable multicast section of the configuration file is missing a section. The reliable way to set up this feature is with RealSystem Administrator.
Try to play the clip from the same system on which RealServer is installed.
Problems with multicasting may be related to:
SDP files are generated automatically and sent to the client when the user clicks the scalable multicast link. If you change any of the settings so that they are different from those initially created in the SDP file, the client will not be able to connect. Two key elements to watch out for:
Make sure you have at least three rules, so that you can continue to connect to RealSystem Administrator, as described in "Deciding What Rules to Create".
The first rule to create is always the rule that enables you to access RealSystem Administrator! If you create another rule first, and lock yourself out of RealSystem Administrator, you will need to edit the configuration file, remove the rule manually, and then restart RealServer. See "Access Control" for a guide on what to look for in the configuration file.
If you receive the message, "Invalid player IP Address", it is because this RealServer is configured with access rules that prevent clients from certain IP addresses from playing content. The client that tried to request content is excluded via access rules. Access rules are described in "Limiting Access with the IP Address".
Many of these messages relate to the player validation method of authenticating users, in which the ID of the client software, rather than a user's name, is being verified.
 |
Additional Information |
|---|
| Refer to "Player Validation". |
Another user is already connected to this RealServer with the same user name. You can configure RealServer to allow users to log in from more than one location, using the same user name: in RealSystem Administrator, click Security>Commerce. In the rules list, select the rule that applies to this clip or directory. In the Allow Duplicate IDs list, select Yes.
There is no more time left in the user's account. The user was playing a clip when the account's time limit was reached.
To add more time to the user's account, or to change the type of permissions available for that clip or directory, see the instructions in the "Permission Types" table for values.
The client is not authorized to play the content; applies to user-authenticated content.
An old client, incapable of authentication, tried to access secure content.
|
|
Additional Information |
|---|
| For a list of client software versions that can be authenticated, refer to "Compatible Client Versions". |
A message in the Java Monitor indicating that the Server is unavailable can mean the Server is not running, or that an access control rule does not permit access to the Monitor Port number.
If your RealServer is not licensed for ad streaming, and a client accesses your RealServer with an ad insertion URL, the following message will appear in the error log:
You can verify the features for which your RealServer is licensed by clicking About in RealSystem Administrator.
Incorrect <RealAdInsert/> information in a SMIL file will cause this error message to appear in the error log:
<RealAdInsert/> tag. Automatic Ad Insertion failed."
Consult RealSystem Production Guide for correct syntax of this tag. To view this manual, click Resources under Help in RealSystem Administrator.
|
|
Additional Information |
|---|
| To view this manual, click Resources under Help in RealSystem Administrator. |
If the HTML used to convey the ad URL to RealServer does not contain an anchor tag that contains an IMG SRC entry, the following message appears:
The following messages refer to files and images related to RealServer's ability to access its Target HTML URL. You can troubleshoot them by using the same computer on which RealServer is running, clicking the link, and checking whether the error message still appears. If the error does not appear, the problem is not related to RealServer configuration.
If RealServer cannot access its Target HTML URL, this message, along with the link, appears in the error log:
URL is given here."
If RealServer is unable to make connection to the server specified for Target HTML, this message, and the link, appears in the error log:
URL is given here"
If RealServer and the server (used for the Target HTML) have a connection, but the server has not sent its data in a timely way to RealServer, this message appears in the error log:
URL is given here"
If RealServer cannot retrieve an image, this message appears:
URL is given here"
If you configure the ad streaming feature by editing the configuration file directly, you may inadvertently omit required sections. The ad streaming feature is designed to be configured and modified by RealSystem Administrator, and not by direct editing of the configuration file.
If you edit the configuration file incorrectly, you may receive the following error messages:
Use RealSystem Administrator to configure the ad streaming feature.
Many of these error messages refer to the Image Source tag. These options are not SMIL parameters, but extensions to the image's SMIL source tag. They are described in RealSystem Production Guide. To view this manual, click Resources under Help in RealSystem Administrator.
In general, a message that includes the phrase "URL-encoded" refers to those additional commands that can be typed as part of the image tag in a SMIL file.
You used a command to set the image bit rate, and used non-numeric text for the bit rate. The format for this command is the following:
image.gif?bitrate=value
If you use 0 for value instead of a Kbps value, one of the error message "GIF [or JPEG]: URL-encoded bitrate is zero." appears.
You included the URL command, but omitted a value. It's easy to do, especially when you typed another tag immediately after it:
image.gif?url=&bitrate=12000
You used the bgcolor option to override a GIF transparency color, such as:
image.gif?bgcolor=value
and used an incorrect value or format for bgcolor. The format for bgcolor must be RRGGBB, where RR, GG, and BB are hex values for red, green, and blue, respectively.
You included the target command in the tag, but omitted to give a value for target. This can be overlooked when you type another command immediately after it:
image.gif?target=&bitrate=12000
image.gif?target=value
where value is either _player or _browser.
image.gif?reliable=value
and used an incorrect value for reliable. The value for reliable must be either true or false.
image.gif?url=command:value
and used an incorrect value. The word following command must be stop, seek, and so on.)
You used the image source tag option command:seek(time) and gave a value for time that is greater than the length of the timeline.
You combined the target_browser command and a client seek command, but they cannot be used together.
image.gif?target=_browser&url=command:seek(21)
There are two causes for this message:
The number of simultaneous clients connected to this RealServer has reached its licensed limit. The number of connections to RealServer is limited by your license key file. To read this file, start RealSystem Administrator and click About. License information appears in a second browser window.
|
|
Additional Information |
|---|
| A table of these minimum values is shown in the "License Files". |
Set the MIME types on your Web server to recognize Ram files. See "MIME Types" and your Web server documentation.
You omitted /ramgen/ from the link in a Web page. The Web server, rather than RealServer, is looking for the file. Only RealServer knows where to find the file. Add the word /ramgen/ to the link. See Chapter A, "Summary of Link Formats" for a list of correct syntax.
Or, create a Ram file and point the link to the Ram file. You will need to store the Ram file in a location where the Web server can access it.
Check to make sure that Ramgen is still on the HTTP Delivery list: in RealSystem Administrator, click General Setup>HTTP Delivery and add /ramgen if it is missing.
Messages in this section refer to the feature that lets you choose which client versions can receive your content. Use this feature if your content takes advantage of newer RealSystem features, such as SMIL.
You may have restricted RealServer to serving to only certain versions of RealPlayer. See "Limiting Access by RealPlayer Version" and MinPlayerProtocol in "Allowance".
If you have limited your RealServer to serving in this way, consider posting a note on your Web site so that users know to expect these messages.
The following messages can appear:
In RealSystem Administrator, RealPlayer Plus Only is On. In the configuration file, the PlusOnly variable is set to True. If you want your content to be available only to RealPlayer Plus clients, leave the settings as is. If you want to allow any clients to be able to view your content, change the setting to Off or False.
The client does not have enough bandwidth to satisfy any bandwidth negotiation choice.
If you have many clients who receive this message, consider asking content creators to include lower bit rates when they encode their content. If possible, you might want to use multicasts instead.
These messages indicate that a link begins with pnm://, but it should begin with rtsp://. Since only RealAudio, RealVideo, RealEvents, and RealFlash can be streamed with the PNA protocol, any link that begins with pnm must point to one of those data types.
One of the following is the problem:
rtsp instead of pna.
pnm instead of rtsp.
In the last two items, the content creator must correct the link.
Messages appear as the following:
There are two causes for this message:
For a list of the necessary system requirements for RealPlayer, consult the client documentation. Every enhancement you make to your system will improve the user experience.
Under some circumstances, the client will work even though the system requirements are not met. This can happen because each renderer plug-in uses a different amount of system resources. It is also possible that the minimum requirements are met by a given system, yet a certain renderer will not perform well.
Variables such as the encoded bandwidth of the clip, actual connected modem speed, and the bandwidth setting in RealPlayer must match.
RealServer has many ways to assure that users will receive the highest-quality performance possible. But even if your Server is configured correctly, it is still possible to deliver content in ways that is not the best quality your system is capable of. This section lists common mistakes administrators have made, that cause users to receive poor quality streams.
This section assumes your RealServer is set up correctly and is running well. You might want to share this information with the content creator.
Users will download content if you do either of the following:
See Chapter 5, "Understanding Link Formats".
Users will still be able to view content, but it will arrive slowly and with lots of rebuffering. The best remedy is to modify the firewall to allow streaming media. Refer to Chapter 9, "Firewalls and RealServer".
Referencing content created in RealSystem 6 with SureStream and using pnm:// for the protocol ensures that users will receive the minimum bit rate available and no SureStream switching.
Use rtsp:// for the protocol, instead.
RealServer is case-sensitive. Make sure you use the same capitalization in the links as in the encoding software or the on-demand file name. You might find it easiest to always use lowercase.
Your RealServer may be tuned to run perfectly, but if the clips themselves weren't created using the best production techniques, they may require too much bandwidth.
If you have followed the troubleshooting tips in this chapter and have not been able to solve the problem, check the RealNetworks Knowledge Base for help. The Knowledge Base contains solutions to many problems not covered here:
For technical support with RealSystem, please fill out the form at:
The information you provide in this form will help technical support personnel to give you a prompt response. For general information about RealNetworks' technical support, visit:
In addition to asking for a detailed description of the problem you are experiencing, support technicians will want to know the information shown in the following form.
| Information About Your Server | |
| Exact Server version (see "Determining the Server Version" to find the version number) | 8._._._ _ _ |
| Information About Your System | |
| Operating system | |
| Processor type and speed | |
| Available RAM | |
| Port numbers | |
| Type of connection to the Internet | |
| Is there a Web server on this system? | |
| Information About Other Software | |
| Client software version | |
| Encoding software version | |
| Information About the Problem | |
| Exact text of error message (if any): | |
| What is the bit rate of the content being streamed? | |
| How are you delivering content-are you streaming on-demand clips or broadcasting live clips? | |
| To how many clients are you streaming simultaneously? | |
| If the problem is with a certain feature, when was the last time it worked correctly? What has changed? | |
| Are there any related problems? | |
| What features are you using? | |
| What troubleshooting steps have you already tried? | |
There are two methods for finding the exact version of the server you are running.
At a command prompt, navigate to the Bin directory, and type the following:
rmserver -v
The version number appears, in the form 8.x.x.xxx, where x varies according to your operating system.
In RealSystem Administrator, click About.
A new browser window appears, with information about your Server.
The version number can vary according to the operating system you use. If you are contacting the RealNetworks Technical Support department for assistance, it is important that they know the exact version you have.