Version 1.0 of TurboPlayerService does not make use of DigaSystem registry / parameters files or of DPE parameter service. Instead there is only a single configuration file: TurboPlayerService.par. This is a simple XML file. You can open the file with a text editor and you will see that there is an explanation for each parameter.
The connection parameters are very important. They specify the way used by the service to communicate with TurboPlayer. They can be adjusted in the DigaSystem registry. Many of them can also be adjusted in the Settings dialog of TurboPlayer:
We recommend to use IP for communication. On the TurboPlayer side you should check the parameters in the DigaSystem registry whether enough ports are being opened in order to serve multiple GUIs. The two parameters are used even if no IP is used. They simply define how many GUIs can connect:
- TurboPlayer \ Communication \ TreeManager \ PortsForGUIs
- TurboPlayer \ Communication \ RundownKernel \ PortsForGUIs
If you want to use memory-mapped files (MMF) for communication, there is a special problem. If one part of the communication - here TurboPlayerService - runs as a Windows service, the MMF must be created in the global Windows namespace. This is necessary because the name of a MM file will only be visible within the same ring, meaning: a desktop file (in ring 3) will not be visible for the service (in ring 0) and vice versa. The ugly part of using the global namespace is: If you activate it, a desktop program will need a special right to create a file in the global namespace. According to Microsoft the local group policy right "Create global objects" needs to be granted to the account running the desktop program. We have noticed that this right has no effect. It is necessary to start the program with "run as administrator". Therefore, we recommend to use IP for the communication if you have such a setup. If you really want to use MMF please set the DigaSystem registry parameter TurboPlayer \ Communication \ GlobalNamespaceForMMF to TRUE and the parameter of the TurboPlayerService.par file “UseGlobalNamespaceForMMF” to “True”.
Each new full-access client which connects to TurboPlayerService will generate a new connect from the service to TurboPlayer engine. This means that each individual GUI – might it be a standard or a web GUI – is known to the engine. The differentiating factor is the GUI number, which therefore must be unique for each GUI. For the standard GUI you can configure in the settings which number is used. All GUI numbers which should be available to web GUIs must be listed in the parameter “GuiNumbersRange” and all numbers listed here must be included in the “PortsForGUIs” parameter of kernel and TreeManager.
In addition there can be read-only clients. Multiple read-only clients can use the same GUI number. There is no fix limitation in the number of these clients, it is only limited by the power of the computer how many clients can be handled. In the parameter file of the service you can list all GUI numbers which should belong to read-only clients. If you do not have the license dll (see above) all connections will automatically be read-only connections.
This opens 9 ports (and message boxes) to be usable by GUIs. GUI 1 could be the one of the same executable, GUI 2 could be an additional standard GUI and GUI 3 – GUI 9 could be web GUIs.
This parameter should be the contrary to the parameter “ReadOnlyGuiNumbers” below. Here you should list all GUI numbers with full access.
GUI numbers which are available for web GUIs which connect to the service.
GUI numbers which belong to connections which do not have any write/modify access.