Custom logger is ignored when demuxing through WebWorker

[dighan]

What version of Hls.js are you using?

v0.13.1

What browser and OS are you using?

Mac OS Catalina and Chrome but the behaviour is the same across user-agents

Steps to reproduce

Specify an object as config#debug to allow proxy-ing logs in demo/main.js:

hlsConfig.debug = {
  log: function myLog(){ /* do anything */ },
  debug: function myDebug() { /* do anything */ }
};

Expected behavior

logger is supposed to be overwritten, no log must be dumped in devtools

Actual behavior

Only logs from logger.log are dumped when demuxing through WebWorker (inline it's fine). Serializing config in the demux/demuxer.js returns en empty {} -> default logger fallback.

Use case

Overwrite hls.js#logger to stack logs in order to report them when playback issues occur

[dighan]

Also debug should be specified as any instead of boolean in config.ts no?

[itsjamie]

Should change debug in config to a union. You're right.

boolean | Logger

interface Logger {
    debug: ...
    log: ...
    info: ...
    warn: ...
    error: ...
}

Given all the ways people could write a custom logger, and take advantage of local scope hoisting before a set of functions. Which trade-off would you perfer @dighan:

• always correct behaviour of custom logger, some timing issues
• timing is always correct, but some loggers with complicated local state would fail

The two approaches essentially boil down two lines. It could ship each function across the web worker context using toString() on the function, re-evaluate the source code on the worker side, and this would work for simple loggers that has no external dependency used in each method call that was fetched through a prototype lookup. This would lead to the timing of logs being thread local, but some logger implementations wouldn't work. They would have to use entirely local scope to the function call.

The alternative approach I see as a possibility is instead notifying the worker context that there is a custom logger, and the implementation used in the web worker for it's logger is one where log messages are shipped back to the main thread for actual logging in this case. The issue here is that the timing of log messages is delayed by the async nature of shipping the log across the worker barrier, but we don't run into an issue with custom loggers.

[dighan]

Thanks for your reply Jamie.

I'd rather go with the second approach to avoid evaluations causing possible side effects at runtime (strict mode). IMHO, having debug-timing a bit delayed is not an issue in the WebWorker context. We can drop a note in the documentation to highlight this behaviour. What do you think?

I can open a PR following your recommendations.

[itsjamie]

@robwalch thoughts on the above?

[robwalch]

Since the goal here is to disable log and debug we could accept a serializable value like false that does just that.

hlsConfig.debug = {
  log: false, /* do nothing */
  ...
};

You can set hlsConfig.debug to false to disable logging completely so why not on each level? For the ask, it's better than messaging from the worker just to call a no-op.

If you want custom loggers that actually log from the worker then yes, we need to get more complex and timing will be on the main event loop. That would be better, but I would strongly advice against no-ops for disabling logs if that's what you want to do.

[dighan]

Actually, my goal is to stack internal logs and report them in case of playback failures (not disabling them via no-ops). In a WebWorker context, some of them were missing because custom loggers are discarded.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[lpommers]

I share a similar use case to @dighan where I would like to track internal hls logs for later use, so I don't want to just disable logging wholesale.

[robwalch]

To get logs out of the worker, you'll need to work on transmuxer-worker.ts so that logs are messaged to and logged from transmuxer-interface.ts. Some care will need to be taken on how utils/logger.ts operates in modules running inside a worker; We can't expect to pass custom log functions into the worker, so the worker should, if debug is anything but false, message logs up to the interface, where logger can act on them as configured.

There's also the comments about config.debug that are unresolved. For now, I think this addresses what is currently missing from the type definitions and export: https://github.com/video-dev/hls.js/pull/3946