This guide will show best practices for handling and troubleshooting playback logs for Unique's clients. We will cover how to log any issues with support, how to view the playback logs and also some known issues.
Reporting issues to Unique support
As we want to separate playback log tickets from regular cinema technical tickets in our ticket system, we need to put triggers in place to catch the tickets when they come in.
If possible, please use the following format on the subject field when sending the email:
<Client> Missing Playback Logs - <Site name><Screens>
Exqample: DRF Missing Playback Logs - Cinemaxx Aarhus 1,3,7
(if all screens are missing, leave the screens section blank)
Viewing playback logs in Integrator Accord (IA)
Please note that if you are not registered as an application user with Unique, please ask for this to be set up before proceeding. Full name and a valid email address is needed.
1. Log onto Unique's application portal (https://login.uniquedigitalcinema.com/cas/login) and access "IA International (live)"
2. Go to Reports -> Content Reports -> Content Playback Report
3. Choose an exhibitor (example Cinemaxx), Site and screen in that order
4. Choose a valid date range that you want to view played back content for and click apply
This will yield a list of all content that has been played in the selected screen for the given time frame. If you want to filter out unwanted content, please use the 'Content Type' drop down to sort by what content you want displayed.
If you want custom sorting, please use the export function and export to a format you would like to sort the results in.
Known Issues
In this section we will cover know issues with both collecting and parsing collected playback logs
API communication
As there are several TMS and player types in the field, all using different logic both for API communication and handling of smpte logs, results will vary in the way the units speak to each other. The TMS needs to know exactly what model player each screen has to make sure it uses the correct API language to ask for the logs to be polled. In some cases the API communication for a player type might also change due to software/firmware changes on the unit, so the firmware package the server is running might also need to be tracked in some cases.
Network issues
The TMS or MovieTransits need to communicate both externally on a broadband/fibre line where it can communicate with the webservices that parse the logs, but also internally on the cinema network so that it can speak to the screen players and pull the logs. This is separated between two network interfaces on the unit.
As there are two different networks in play, there is also two chances of network issues affecting the service. If there are network issues locally at the cinema, the TMS/MT will still appear online in AA/IA etc, but won't be sending logs as none have been collected from the screen(s). If the external network goes down, the TMS/MT might still be online on the cinema network locally and be collecting logs normally from the screens, but will not be able to send them to the webservices for parsing.
Other common issues that can effect the playback log service network wise include DNS and port issues. These issues might not always be noticable until you go through the logs from the TMS or MT server.
Server/kit swaps
One of the most common issues when one screen is not displaying logs while the others work fine, is that the server in the screen has been swapped locally either due to technical issues or an upgrade from the cinema's side. If the server is swapped with a new unit of the same type, the logs will continue to be collected, but will fail parsing as the serial number of the unit will no longer match what is expected.
If swapped for a different model, the model type will also have to be updated on the TMS/MT side to make sure the correct API communication (discussed above) is used to pull the logs.
Empty logs
In some cases, no logs will be displayed for the site/screens in IA, but when looking at the logs folder on the TMS, playback log polling is working fine, but the smpte logs extracted from the player is empty. This could either indicate that the smpte service on the screen player has crashed or is not running properly, or the screen has in fact not played anything on these dates.
Partial logs
Sometimes when viewing the playback logs for a site/screen in IA, the playback log data doesn't match what is expected to be played. The most common reasons for this will be either that the screen server in question is running a different firmware package than the TMS/MT is set to communicate with for that model, or that there are time differences in regards to when the show was booked to play and what time they are displayed. Time zones, secure clock drifting or parsing errors could be potential factors in these cases.
0 Comments