Technical Best Practices

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 hard coded storage if you use relative storage paths, brightscript will assume that the storage paths are relative to whatever storage device you are using if you want to use different storage for autorun and media, then you need to specify a path and validate that the path exists if your code uses hard coded values for storage, validate the storage volumes and make sure you are selecting the expected storage ( sd / , sd2 / , ssd / , usb1 / , or flash / ) the lguv5n features flash storage or usb storage, and will fallback to the flash if no other storage is found 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 control 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 html video 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 operational best practices docid\ ntbn8xirzfuckfbzwq 2z