When reaching out to BrightSign Support for help, taking the time to write a good support ticket will go a long way towards a timely resolution of your issue. Ambiguous support tickets lacking important details will inevitably result in time-consuming back-and-forth exchanges and a resultant delay in issue resolution.

Support tickets should include the following information:

1. OS version

2. Model number of player(s)

3. Description of issue

   1. Observed behavior

   2. Expected behavior

4. Impact

5. Attachments (Setups, logs, dumps, recordings/screenshots)

6. Reproduction steps

OS Version

The specific version of the OS on the player(s). For example, 9.0.120, 8.5.47, etc.

Model Number

The specific model(s) of the player(s) affected. For example, XC4055, XD1035, HD1025, etc.

Description of Issue

Clearly state the nature of the issue.

Impact

To better help us triage your ticket, please provide the issue’s impact level according to the following:

1 - Critical issue affecting a large number of players.

2 - Significant issue affecting a limited number of players.

3 - Moderate issue affecting any number of players.

4 - Relatively minor issue but should be addressed.

5 - Suggestion, feature request, or general comment.

Attachments (Setups, logs, dumps, recordings/screenshots)

The more info you can provide, the better. Setups, log files, and dump files are all extremely useful to the BrightSign team for troubleshooting and performing root cause analysis. Video recordings of the HDMI output and/or screenshots demonstrating the issue are also very helpful.

Reproduction Steps

The ability of BrightSign engineers to reproduce your issue is essential towards finding a solution. In addition, it is important to isolate whether the problem lies with the CMS or with the BrightSign player or services.

List the exact steps to reproduce the problem, providing as much detail as possible. To facilitate reproduction, please provide the following, listed in order of descending preference.

1. Self-Contained Image (Most Preferred)

• Provide a self-contained image of the storage device (e.g., µSD card). “Self-contained” means that the player is able to run the image independent of the CMS - any required audio/video content is contained in the image and is not required to be downloaded from the CMS.

• Provide details of the operating environment (setup, network configuration, etc.).

BrightSign will try to reproduce the issue by running the provided image on a similar player in a similar operating environment.

2. CMS-Dependent Image for Non-Registered Players

• Provide an image of the storage device (e.g., µSD card) in which the player retrieves audio/video content from the CMS.

• Provide details about the network subscription and the process required to set up the player.

• Provide details of the operating environment (setup, network configuration, etc.).

BrightSign will try to reproduce the issue by running the provided image on a similar, non-registered player (i.e., the player is not registered with the CMS) in a similar operating environment where the player retrieves the necessary content from the CMS.

3. CMS-Dependent Image for Registered Players

This is similar to #2 above with the exception that the player is registered with the CMS.

4. Image Unavailable (Least Preferred)

This is by far the least preferred option and typically results in the longest time to resolution. Not having an image makes it very difficult for BrightSign engineers to reproduce the problem.

If an image cannot be provided, please provide explicit details about the player’s networking setup. If a stream or other type of content is downloaded to the player, provide the exact stream address. If the stream is private or live, please provide PCAPs. If we have difficulty reproducing the issue, we may ask for the player to be shipped back through our standard RMA process.

Testing

As part of verifying potential solutions, BrightSign may require that partners change the registry settings on a particular player or to perform follow-up testing. In some cases, we may request that you have a player available to us in the exact environment where the issue is being experienced.

Implementation

• Any proposed solution should be fully tested before deploying on a larger scale.

  • If deploying across more than one model, it is recommended to test the solution on all models intended for deployment instead of only the affected model.

• We appreciate feedback regardless of whether or not the solution works.

  • If the proposed solution does not fix the problem, please let us know. We may ask for additional info and will continue to work towards alternative solutions.

  • If the proposed solution does work, we want to know that too!

• Workarounds may be suggested until a fix can be implemented. In some cases, the workaround may end up being the recommended resolution.

• Plugins and workarounds may only work on specific versions of the OS.

Adherence to the guidelines above will help minimize the time to resolve your issue. In addition, we recommend that partners be proactive by staying up to date with BrightSign’s ongoing developments. Here are some ways to stay updated.