[FEAT] tsanalyze: add timeout option

[lars18th]

Is your feature request related to a problem?

When using the tsanalyze tool inside a PIPE with multiple tools, the CTRL+ interrupt (could) kill the process before it prints the data. Therefore, a simple method to enforce to print based on a timeout could be useful.

Proposed solution:

My suggestion is to add the parameter --timeout to instruct to the tool to close it after printing the results when the timeout expires. Then it will be easy to do something like this: encoder | tsanalyze --timeout 30s.

Alternatives:

The alternative is to use the tsp tool with the analyze plugin (ie. tsp -P analyze -i 30 -w -c -O drop). But this will be more user friendly.

Additional information:

And perhaps it will be also useful to add the option to "pass through" the stream, like this: encoder | tsanalyze --timeout 30s --passthrough | emitter. In this case, the timeout doesn't close, but it prints at each iteration of the timeout.

[lelegard]

Hi @lars18th

tsanalyze is only a shortcut to analyze a file, nothing more. It exists only because, initially, there was no analyze plugin. Only tsanalyze existed (it was the first program in TSDuck, just for me to understand what is in a TS). Later, I found useful to analyze streams on the fly and I added the plugin, keeping tsanalyze for the sake of compatibility only, moving most of the code from tsanalyze to a class which is used by both. The same story applies to tspsi, tsfixcc and maybe others.

The most general way of analyzing a stream is the plugin. The command is there only for compatibility and simple file analysis. I won't make it more complex to duplicate features which are already present in the plugin.

Using the plugin solves the Ctrl-C case. Ctrl-C is handled by the tsp framework which then signals an end of stream to all plugins. Thus, the analyze plugin can properly display or save the analysis.

Note that, if some plugin hangs and tsp does not terminate shortly after the first Ctrl-C, hit Ctrl-C again. The second Ctrl-C is not handled by tsp and the process is terminated.

[lars18th]

OK. So, I accept (and I agree) with the idea of not improve more the tsanalyze tool.

However, the CTRL-C case is not solved as you think. Using a mixed binaries from Windows and Linux (running the Shell in WSL2, and the tsp.exe tool with other Unix tools), this behaviour is not true. Anyway, I don't suggest to support this "lab testing" use case. But one option to terminate the execution of the tsp process after the analyze plugin prints the report will be useful. With the -i --internval parameter we can force the report. And with a simple --kill-after-reports X where X is the number of reports we can obtain the functionality.

What you think?

[lelegard]

Using a mixed binaries from Windows and Linux (running the Shell in WSL2, and the tsp.exe tool with other Unix tools), this behaviour is not true.

This is certainly an unusual configuration. When WSL2 is active, Hyper-V acts as a bare-metal hypervisor and Windows and WSL2 are two distinct virtual machines running side by side on top of it.

I don't even know how to run processes on the two VM in the same command line. Probably some Microsoft trick which is equivalent to an ssh on the other VM for one of the commands.

We can't of course expect Ctrl-C to be handled consistently on the process running in the other VM.

[lars18th]

Hi @lelegard ,

This is certainly an unusual configuration

In fact, this is not want you think. WSL2 is only the Linux kernel from Microsoft running on Hyper-V in Type 2 mode. Nothing more. Then any process running on it is like a "container" process in the sense that it can interact with any other process without sharing kernel resources (shared memory, for example). However, process can interact using sockets, virtual devices , and of course pipes. So, inside a WSL2 shell (Bash or PS) you can start WIN and WSL2 process inside the same PIPE. It's not magic, and identically to systems with isolated contexts based on virtualization.

That said (which is not relevant to TSDuck) the question is: could you add the --kill-after-reports X option to the analyze plugin? I think it might make sense in other scenarios as well.

[lelegard]

Hi @lars18th

About Hyper-V, sorry but Hyper-V is a type 1 hypervisor, not a type 2. There is plenty of online resources and descriptions on that. Windows is not the "host" as used in type 2 hypervisors. Even though you see it booting immediately when the PC boots, it is in fact "just another VM", side by side with the Linux kernel for WSL2 (when you boot it). There is also a hidden third VM where critical Windows processes run as well as a few drivers. This is active by default in Windows 11 (fresh installation, not upgrade from Windows 10) and can be activated / deactivated in the settings under complicated names such as "core isolation memory" or "hypervisor-based memory isolation", can't remember the exact name (Microsoft is always good at hiding obvious technical concepts behind complicated long names).

If you want to experiment the difference, compare the installation process with VirtualBox. VBox is a type 2 hypervisor. You install it and you can immediately create and boot virtual machines because VBox is "only" an application on the Windows hosts. When you install / activate Hyper-V, on the other hand, you can't use it until you reboot the system. This is not only because of the usual Microsoft mantra "reboot after any modification". This is because the architecture changes completely. Instead of booting Windows, the system now boots Hyper-V first, as a type 1 hypervisor, which in turn automatically boots Windows in the first VM. This is hidden to give the impression that you booted Windows. But the reality underneath is different.

About the termination of analysis, doesn't the until plugin do the job? It is not exactly "terminate after N analyses" but it terminates the stream processing after X seconds or Y packets. It reports an artificial "end of stream" to make sure everything terminates properly (and therefore trigger the last analysis in plugin analyze). This is cleaner than killing the application. I am always reluctant to bloat plugins with features which are already implemented in other plugins.

[lars18th]

Hi @lelegard ,

Thank you for the extense description of how works WSL2.

Regarding the topic of the request...

About the termination of analysis, doesn't the until plugin do the job?

Yes, it could achieve the same behaviour. However, I feel the parameter --kill-after-reports X is intuitive and easy to implement. So, it's user friendly. But the final decision is yours.