This page describes each incident, providing details about how Broadsign detects it. Also, if possible, we describe what the software does to resolve the incident.
There are ten types of player incidents.
Incidents that are reported by the player are only communicated to the server when the player polls. If an incident is reported and resolved on the player between polls, it is logged in the player database, but it is not communicated to the server. The Unexpected Shutdown incident is a notable exception to this.
|MIA||This is detected by the server and can be due to a multitude of different reasons, including a power outage at the site where the player system is situated, a cut or disconnected network cable or a malfunction on the player. If the player’s display unit has the “Enforce Day Parts” option enabled, an MIA incident will be opened if the player does not contact the server when its day part begins. An MIA incident will be automatically resolved when the player system reestablishes contact with the Server.|
|Unexpected Shutdown||Unexpected Shutdown incidents occur when a player is forced to shut down by abnormal means. In other words, these incidents are meant to provide a record of those occasions when a player machine has been shut down improperly, e.g. a power outage or manual intervention. This incident is reported in the resolved state only. It is meant as a log item to help troubleshooting.|
|Difficulties Polling||If the player cannot successfully complete its poll, it will report a Difficulties Polling incident on the next poll to the Server. If you see several of these on a player, it indicates that the connectivity on-site is very unreliable. When reported, the player has submitted a complete poll thus this incident has resolved itself but serves as a warning for any network disturbances at the player site.|
|Application Fault||This incident is triggered when the player encounters a critical error and must terminate. The Broadsign Shell process (bspsh.exe) will detect that the process has exited and will restart it. When the player next polls the Server, an Application Fault incident will be reported. This incident is reported in the resolved state only. It is meant as a log item to help troubleshooting.|
|Memory Exhausted||This incident is triggered by the memory usage monitor exceeding its specified thresholds. By default, the memory threshold is set at 10% free resident and virtual memory. If the system exceeds this amount, it will reboot and report an incident when it next polls the server. Typically, memory over-consumption issues are caused by third party applications running alongside the player, of third party plug-ins loaded by the player that Broadsign has no control over. A typical example is Adobe Flash. Flash/Actionscript is a complete development stack and it is quite easy to create flash applications that leak memory. For this reason, please test your flash applications rigorously before deploying them. This incident must be resolved manually or allowed to be automatically resolved after 14 days.|
|Deadlock||This incident is triggered by the Broadsign Shell process (bspsh.exe) that monitors the player periodically. If the shell process determines that the player has become unresponsive for any reason, it will terminate the process and start a new instance of the bsp.exe process. When the next polls the Server, a Deadlock incident will be reported. This incident must be resolved manually or allowed to be automatically resolved after 14 days.|
|Performance Problem||This incident is related to the CPU usage monitor exceeding the threshold specified in a configuration profile sent to the player. The default values are set to report an incident when 90% CPU usage is exceeded for an average period of 15 seconds. This incident must be resolved manually or allowed to be automatically resolved after 14 days.|
|Offline During Business Hours||This incident is opened when a display unit has the “Enforce day parts” option enabled and the system is in the offline state after the opening hours defined for it indicate that it should be online and playing. A typical use case for this is locations where the player is manually powered down, often, site staff forget to power it back on in the morning.|
|URL Sync Failed||This incident is generated when monitor_sync fails to synchronize with an associated URL. Typically this means that the remote feed server is suffering an outage of some type.|
|Backup Master Activated||This incident is generated when Broadsign Control Player activates a backup master from a Synchronized Set. With this incident, a network operator can monitor issues that prevent synchronization. A backup master rejoining a Synchronized Set as a slave is part of this incident, as well.|
There are five types of playback incidents.
When the attempts to display an ad copy and this fails because the content is not one of its registered content types, a Content Error incident is reported. This could occur if a video clip uses an unsupported codec, for instance. Content Error incidents are resolved either when the ad copy plays successfully or when the ad copy is no longer scheduled to that player.
For a full list of supported formats, see Content Formats.
|Missing Ad Copy||Missing Ad Copies will be reported if the attempts to display an ad copy but cannot, because the file has not yet been downloaded or it has been deleted on disk. Missing ad copy incidents become resolved when the player system downloads the content and the ad copy undergoes a successful verification process.|
|Truncated Ad Copy||Truncated ad copy incidents are triggered when a ad copy is played in a slot with a shorter duration than the duration assigned in the ad copy bundle. This would mean that either the content should be replaced with a shorter one or that the ad copy should be programmed to override the slot duration in the ad copy bundle. Truncated ad copy incidents are resolved when a bundle is played to its full specified duration successfully; this can be accomplished by reducing the bundle Duration so that it is not cut off by the slot length.|
|Disk Space Error||Disk Space incidents occur when the size of the active content scheduled to a specific exceeds the amount of disk space allocated for content as configured in the player. This situation will cause the player to continually delete and re-download content as it goes through its playlist. Disk Space incidents are also triggered if the Content Manager encounters write errors when writing to a player's hard drive. The Disk Space incident is resolved by increasing the amount of disk space allocated to content storage or by adjusting scheduling so the layer synchronization has less active content in its playlist.|
|Ad Copy Expired||
This incident is generated when an ad copy is removed from the loop because its associated monitor_sync feed has become unfetchable or hasn’t changed in the defined expiry period.
For more details, see Ad Copies.
There are five types of display incidents.
|Not Full Screen||By default, the layer synchronization runs in full screen mode. If someone plugs in a keyboard and hits the ESC key, the layer synchronization will display as a normal windowed application and it will show a menu. If the layer synchronization polls in this state, it will open a Not Full Screen incident. This can help you track if maintenance is being performed on the layer synchronization. This incident is resolved when the layer synchronization polls while it is in full screen mode again.|
Device monitoring makes it possible to control and monitor a digital display using an RS-232 link. The layer synchronization software communicates with the display device using the display's own machine language, and reports incidents if one of the scheduled device control commands does not respond as expected. It will also report an incident if the settings for Device Controls are not configured properly, such as the command being directed on COM port 3 if there is no COM port 3 available on that PC. An incident report related to a device error will include information about the command that failed as well as the hexadecimal codes sent to the screen and the expected response. A device error incident is resolved when the display receives the expected respond for the same Device Control Operation or when the operation is removed from the display unit configuration.
Here is an example of the information associated to a device error: Action "assert_power", value 1 failed on COM port "com_port1".The Device Opcode Id of the failed action is 3119124.Command sent: "0236453031303030303030303003", Expected response: "023030303103", Actual response: nothing
For more information about device control, see Device Control.
|Resolution Mismatch||If “enforce resolution” is enabled on the display type, but the graphics card/screen will not allow this resolution to be set, this incident will be reported.|
|Temperature Critical||If the display’s temperature is higher than the specified critical temperature threshold in the device control operation, this incident will be opened. It will be automatically closed once the display cools down.|
|Temperature Warning||If the display’s temperature is higher than the specified warning temperature threshold in the device control operation, this incident will be opened. It will be automatically closed once the display cools down.|
You can program a device control operation with error handling routines. For more information, see Error Handling.
This permits the layer synchronization to respond to display errors in a way that may immediately resolve the issue. Error handling routines also permit the layer synchronization to halt playback on device error which ensures that proof of play statistics only contain ads where display monitoring verified that the content was being shown on the display.