A SMIL-player supports the HTTP PUT method to upload logs and reports to an HTTP server. The web server must support WebDAV and the PUT method.
There are five reporting functions supported which you can combine.
Inventory reporting
Play logs
Player events
System report
Task execution reports
You can also monitor the heartbeats of your player by storing every fetch request of the smil-index via HEAD.
Inventory Report
Inventory Handler
Add metadata to the head section of the SMIL index which define where the media player should PUT the inventory file. A typical definition looks like this.
In action, there is the path of the file which contains the report. The tags refreshInterval and retryInterval are optional. With these tags, you control the updates frequencies.
Inventory File Format
The file uploaded to the server via PUT looks like this:
Play Report
Play Report Handler
The metadata to the head section of the SMIL index are the same. They only needs PlaylogCollection set as type.
Set Log-Id
The playbacks of media files are not logged by default. If you want to log played media files, you had to specify in SMIL index explicitly. The following example shows how to assign a log ID to an image file, so a log is generated when it is played.
Play Report File Format
The play log files uploaded to the server are similar to the POPAI Log Standard 1.0. Several redundant fields are removed to optimize network performance. A log file uploaded to the server looks like this.
Event logs
The event logs reports various events which can happen on the player. These events can be:
FETCH_FAILED: when a file cannot be downloaded. This is due to network failure or not existing URL.
MEDIA_NOT_AVAILABLE: When a media file does not exist in player's storage. One reason can be the file is not just downloaded. This also can happen due to insufficient space, which causes the player's storage “garbage collector” erasing files least-recently-used (LRU).
MEDIA_OPEN_ERROR: when the header information of the media file describes a format not supported by the player.
MEDIA_PLAYBACK_ERROR: Most likely due to a corrupt media file or stream. Occasionally, this can also indicate a RAM or CPU error.
The event reports are helpful when you need to analyze problems.
Event Report Handler
same as above with EventlogCollection set as type.
Event Report File Format
The event report uploaded to the server looks like this.
Events Reference Listed by Event Source
Player events listed by different event sources as below:
ContentManager
event: LRU_OBJECT_REMOVED
eventType: informational if lastAccessTime is before 30 days
meta "resourceURI": URI for the object that removed
meta "lastAccessTime": object last access time
event:OBJECT_REMOVED
eventType: informational
meta "resourceURI": URI for the object that removed
event: OBJECT_UPDATED
eventType: informational
meta "resourceURI": URI for the object that updated
meta "contentLength": content length in bytes
meta "lastModifiedTime": object last modified time
event: FETCH_FAILED
eventType: error if no other versions available in cache; warning if an earlier version exists
meta "resourceURI": URI for the file that failed to transfer
meta "transferLength": Number of bytes transferred so far
meta "lastCachedLength": If a previous version exists, its length in bytes
meta "lastCachedModifiedTime": If a previous version exists, its modified time
event: FETCH_FAILED : E_CHECKSUM_NOT_MATCHED
eventType: error
meta "xmp:errorMessage": E_CHECKSUM_NOT_MATCHED
meta "md5": MD5 calculated from downloaded media
event: BROKEN_OBJECT_REMOVED
eventType: warning
meta "resourceURI": URI for the object that removed
meta "contentLength": content length in bytes
meta "transferLength": actual file size; -1 means file not found
MediaPlayer
event: MEDIA_NOT_AVAILABLE
eventType: error
meta "resourceURI": URI for the object that not available
event: MEDIA_OPEN_ERROR
eventType: error
meta "resourceURI": URI for the object that fails to open
event: MEDIA_PLAYBACK_ERROR
eventType: error
meta "resourceURI": URI for the object that fails to play
MediaControl
event: SMIL_LOADED
eventType: informational
meta "instanceId": fixed value:"display:0"
meta "resourceURI": URI for the object that loaded
meta "contentLength": content length in bytes
meta "lastModifiedTime": object last modified time
event: SMIL_NOT_AVAILABLE
eventType: informational
meta "instanceId": fixed value:"display:0"
meta "resourceURI": URI for the smil-index that not available
event: SMIL_OPEN_ERROR
eventType: error document error (too large, syntax error, other errors), other internal errors
meta "instanceId": fixed value:"display:0"
meta "resourceURI": URI for the smil-index that not loadable
meta "contentLength": content length in bytes
meta "lastModifiedTime": object last modified time
System Report
System report Handler
Add metadata to the head section of the SMIL index which define where the media player should PUT the inventory file. A typical definition looks like this.
In action, there is the path of the file which contains the report. The tags refreshInterval and retryInterval are optional. With these tags, you control the updates frequencies.
System Report File Format
The system report uploaded to the server looks like this. Formatted for better overview.
Task Execution Report
Task execution reports informs about an execution of a maintenance task like reboot, software refresh, or firmware update. Not every player software supports this, as this is an operating system dependent function. Currently, only android version of garlic-player with garlic-launcher sends this reports.
Task Execution Report Handler
A typical file definition looks like this.
Task Execution Report File Format
The ID is the same which is given on the maintenance task, so you can assign to the right execution to the report.