Class: shaka.log

A console logging framework which is compiled out for deployment. This is only available when using the uncompiled version.
Source:

Members

(static) currentLevel :number

Type:
  • number
Source:

(export, static) Level :number

Log levels.
Type:
  • number
Properties:
Name Value Type Description
NONE 0 number
ERROR 1 number
WARNING 2 number
INFO 3 number
DEBUG 4 number
V1 5 number
V2 6 number
Source:

Methods

(static) alwaysError()

This always logs to the console, even in Release mode. This should only be used for deprecation messages and things the app should never ignore.
Source:

(static) alwaysWarn()

This always logs to the console, even in Release mode. This should only be used for deprecation messages and things the app should never ignore.
Source:

(static) debug()

This log is to aid *users* in debugging their content. This should be for logs about the content and what we do with it. For example, when we change streams or what we are choosing.
Source:

(static) error()

This log is for when an error occurs. This should always be accompanied with an error event, thrown exception, or rejected Promise. Logs are disabled in Release mode, so there should be other methods of detecting the error.
Source:

(static) info()

This log is for messages to the user about what is happening. For example, when we update a manifest or install a polyfill.
Source:

(export, static) setLevel(level)

Change the log level. Useful for debugging in uncompiled mode.
Parameters:
Name Type Description
level number
Source:

(static) v1()

This log is for debugging Shaka Player itself. This may be logs about internal states or events. This may also be for more verbose logs about content, such as for segment appends.
Source:

(static) v2()

This log is for tracing and debugging Shaka Player. These logs will happen a lot, for example, logging every segment append or every update check. These are mostly used for tracking which calls happen through the code.
Source:

(static) warning()

This log is for possible errors or things that may be surprising to a user. For example, if we work around unusual or bad content, we should warn that they should fix their content. Deprecation messages and messages the app shouldn't ignore should use alwaysWarn instead.
Source: