Skip to main content

What Problem Does This Solve?

During development, you want detailed logs to debug issues—what methods are called, what data is passed, when errors occur. In production, you want minimal logging to avoid performance overhead and log spam. LevelFilter controls how much the LCK SDK logs to the console, letting you dial logging verbosity up for debugging or down for release builds.

When to Use This

Set LevelFilter when:
  • Development: Use Debug or Trace to see detailed SDK behavior
  • Testing/QA: Use Info to see important events without noise
  • Production: Use Warn or Error to only log problems
  • Release builds: Use Off to disable all SDK logging

Quick Example


Log Levels Explained

Off

No logging at all. The SDK produces zero console output. When to use:
  • Shipping builds where you don’t want any SDK logs
  • Performance-critical sections
  • Final release to customers

Error

Critical errors only. Only logs when something breaks. When to use:
  • Production/release builds
  • You only want to know when things fail
  • Minimize log noise
What you’ll see:
  • Initialization failures
  • Recording errors
  • Permission denials
  • Platform incompatibility

Warn

Errors + warnings. Problems that might cause issues but aren’t critical. When to use:
  • Staging/beta builds
  • You want to catch potential issues before they become errors
  • Production with monitoring
What you’ll see:
  • Low storage warnings
  • Deprecated API usage
  • Suboptimal configurations
  • Performance concerns

Info

Important events. SDK lifecycle events and state changes. When to use:
  • QA/testing builds
  • You want visibility into what the SDK is doing
  • Troubleshooting user reports
What you’ll see:
  • SDK initialization
  • Recording start/stop
  • Quality changes
  • Camera configuration

Debug

Everything + debug details. Internal SDK operations and parameter values. When to use:
  • Active development
  • Debugging SDK integration issues
  • Understanding SDK behavior
  • Reproducing bugs
What you’ll see:
  • Method calls with parameters
  • Internal state changes
  • Configuration details
  • Data flow

Trace

Maximum verbosity. Frame-by-frame details, extremely detailed logging. When to use:
  • Deep debugging of specific issues
  • Understanding exact execution flow
  • Performance profiling
  • Reporting bugs to LIV support
Warning: Very high log volume, may impact performance. What you’ll see:
  • Every frame’s processing
  • Memory allocations
  • Texture updates
  • Encoder buffer states
  • Network packet details (streaming)


Common Patterns

Build-specific logging

Runtime toggle (debug menu)

Platform-specific

Temporary verbose logging for debugging


Enum Values


API Reference

Set Log Level

Parameters:
  • level — Desired logging verbosity
Example:

Performance Considerations

Trace logging can impact performance — especially at high framerates (60+ fps). Use only for debugging specific issues.
Impact by level:
  • Off, Error, Warn — Negligible impact
  • Info — Very low impact (under 1% typical)
  • Debug — Low impact (1-3% typical)
  • Trace — Moderate impact (5-10% possible)
Best practice: Ship production builds with Error or Off.

Debugging Tips

Capture logs to file

Conditional compilation

Define DEBUG_LCK in Player Settings → Scripting Define Symbols when debugging.

Best Practices

Set early — Configure log level in Awake() before SDK initialization
Build-specific — Use preprocessor directives for different builds
Ship clean — Use Error or Off in production
Debug temporarily — Increase verbosity when debugging, restore after
Don’t leave Trace enabled — High performance cost, huge log files