---
title: Technical Best Practices
slug: develop/technical-best-practices
docTags: 
createdAt: 2025-03-11T07:00:15.332Z
---

To assist partners in getting up and running as efficiently as possible, we’ve compiled a list of technical best practices to maximize your chances of success.

# brightsign-dumps Folder

When developing your own autoruns, do not forget to include instructions for the autorun to create a *brightsign-dumps* folder on the player. The *brightsign-dumps* folder is used to store crash information and is very useful to BrightSign support when troubleshooting.

# Storage Paths

All partner applications make use of storage device paths, either to indicate where files will be downloaded to, or where to locate certain files present on the storage device.

The BrightSign OS supports multiple storage devices and following is the priority order in which they are mounted:

| **Storage Device (in priority order)** | **BrightScript path** | **JavaScript path** | **Description**                                                                                                                |
| -------------------------------------- | --------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| USB1                                   | USB1:/                | /storage/usb1       | The drive for USB storage devices connected to the player                                                                      |
| SD                                     | SD:/                  | /storage/sd         | The primary SD or microSD drive on the player                                                                                  |
| SD2                                    | SD2:/                 | /storage/sd2        | The internal microSD drive on  players that support this (see [Storage Devices by Player Model](docId\:mGdEFc6YvkIbeiUxH9J1O)) |
| SSD                                    | SSD:/                 | /storage/ssd        | The internal SSD on the player (XT and XD models only)                                                                         |
| Flash                                  | Flash:/               | /storage/flash      | The internal flash storage on the player                                                                                       |

:::hint{type="danger"}
Note that the LGUV5N model only features Flash or USB storage (no SD), and will fall back to the Flash if no other storage is found. Due to popular demand, the FLASH: storage on LG is renamed SD: and references to FLASH: will no longer work as of the BOS 9.1.96 Beta release.
:::

Below are some of the recommended practices when using storage device paths:&#x20;

1. Derive the default mounted storage device path in your application. See the examples for BrightScript and JavaScript below.
2. Validate the derived storage device as needed. See the `DriveIsMounted()` function in the BrightScript example below.
3. If your app uses relative file paths, BrightScript will assume that the file paths are relative to the default storage device.
4. If your app uses different storage for autorun and media, then it should specify a path (as per list above) and validate that the path exists.

### Code Examples

The following examples provide an approach to find the highest priority storage device that is mounted on the player.

**BrightScript**

```none
Function GetMountedDrive() As String
'''''''''''''''''''''''''''''''''''''
    drives = ["USB1:/","SD:/","SD2:/","SSD:/","FLASH:/"]
    for each drive in drives
        If DriveIsMounted(drive) Then
            return drive
        End If
    next
    return ""
End Function

Function DriveIsMounted(driveName$ As String) As Boolean
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''
    du = CreateObject("roStorageInfo", driveName$)
    If type(du) = "roStorageInfo" Then
        return true
    End If
    return false
End Function
```

**JavaScript**

```javascript
const fs = require('fs');
const path = require('path');

function getDefaultStorageDevice() {
  const rootPrefix = '/storage';
  const storage_list = [ 'usb1', 'sd', 'sd2', 'ssd', 'flash' ];
  for(const storage of storage_list) {
    try {
      fs.realpathSync(path.join(rootPrefix, storage));
      return storage;
    } catch(ex) {
      // nop - the dir doesn't exist on this system
    }
  }
  return undefined;
}
```

# Free Tools

BrightSign offers a plethora of free tools and services that greatly ease provisioning and diagnostics. These include the powerful tools available via BSN.Cloud for player provisioning as well as the many tools described in the [Developer Tools](docId\:WFjRzUBBUvewOhJo-Tf3Q) section of this guide. Partners are highly encouraged to take as much advantage of these tools as possible as it accelerates development and also makes support and troubleshooting much easier.

# Memory Management

BrightSign players are purpose-built for digital signage. Players are not general-purpose devices and they do not have, nor do they require, as much memory as a typical Mac or PC. When developing for the BrightSign platform, developers should be cognizant of potential memory limitations that they may not be accustomed to.

# OS Updates

Partners should try to use the latest BrightSignOS builds in order to take advantage of the latest bug fixes and newest features. Keeping up to date with the latest OS build also enables partners to more easily expand their deployments with our latest hardware.

We are continuously improving the firmware on our players, but as is often the case with software, problems are sometimes inadvertently introduced. A stable player is paramount to any BrightSign integration, so we strongly encourage partners to thoroughly test any BrightSign firmware releases prior to upgrading any players being used in a production environment.

# HTML \<video> Elements & Memory

It is fairly common for a presentation to include switching from one video to another. In many BrightSign players, including the Series 4 line, if a video element is not explicitly released, that element will continue to use memory even if it is no longer actively displaying. It is therefore important to reset the source to blank prior to switching videos. If this is not done, the first video(s) will continue to use memory while subsequent videos are playing, potentially resulting in the following log message:

`Failed to find a video decoder`

To release the video element, the `src` attribute of the `<video>` should be set to blank:

`video.src = "";`

Additional detail on this topic can be found [here](docId\:e6uJleH69Q0JmMv8kyTrp).

# Smooth Video Transitions

If multiple videos are being displayed sequentially, it is generally desired for one video to transition smoothly into the other one. To help ensure this, make sure that both the first and last frames of the videos do not consist of a blank frame. The presence of even one blank frame between videos can result in a noticeably jarring transition between videos.

# Upgradeability

Change is inevitable so partners are recommended to design their apps with the ability to push updates to players remotely. This applies not only to the partner app itself, but also to diagnostic scripts which can be very useful for troubleshooting.

[Next - Operational Best Practices >](docId\:NTbn8xiRZFucKFBzWQ_2Z)
