TS Analyzer listens to RTP stream and allows to view inbound network, RTP and TS packet details. You can check out a .TS file and scan through it - just drag/drop the .TS file onto the EXE. It makes possible to view into the service description tables, and decode a teletext stream.You can print live Teletext decoding, and you can use the tool to generate input logs for 'big data' analysis.

With its integrated telemetry options, you can stream quality metrics into the Cinegy cloud (or your own).

Cinegy TS Analyzer needs .NET 4.5 to be installed.

- register network shares that refer to the new storage in Cinegy Archive;

- create a new Media Group that will be used to reference the new storage;

- assosiate created network shares with each file type within the created Media Group;

- select the corresponding Media Group in watch folder settings.

If you add network shares that reference the new storage to the existing Media group - the new files will be ingested to both the old and new storage, by the principal of round robin.

For more details please refer to the Cinegy Open documentation,
https://open.cinegy.com/products/archive/15/archive-manager/user-manual/media-storage/types-locations/. 

In case the media file is available in MAM Database or your media storage, a media URL is going to be assigned to the playlist item. If the media file is unavailable in MAM database, a placeholder is going to be created with the corresponding Traffic ID by CAS and the reference to this placeholder is going to be assigned to an item in the resulting playlist. At the same time, PowerShell will try to search the media piece (missing in Archive) in the media folder (specified in TG settings). If PowerShell locates the desired media piece in a media folder, it will create a CineLink link file in Convert Watch folder (the path should be specified in the *.ps1 script). In case PowerShell is unable to locate the media file with the specified Traffic ID in your media folder, Cinelink file will not be created. Resulting MCRlist will contain a dummy item with the corresponding Traffic ID.

CineLink file contains the information about the path to a media file and a GUID of a target placeholder (created by CAS) so that Convert could fulfill the proper placeholder with a proper media. Afterward, Convert Watch folder service surveys the watch folder and picks up the Cinelink file in order to create an import task and pass it to Convert for further processing. As a result, the placeholder is filled with media.

When the MCRlist created by TG is inserted into Cinegy Air, the control application calls CinegyAirPlaceholder.dll which is going to scan Cinegy archive for the placeholders that have been already filled with media. As a result of this scan, in case the placeholders have been filled, each of the playlist items referred to a placeholder is going to be updated with the URL to a media file on your MAM media storage automatically. If the media file for a playlist item has not been imported to the Archive yet, the item is going to remain a dummy until the corresponding placeholder is filled.


The MissingMediaData.txt report file with missing media ID's is located in C:\Watch_folder by default and this path may be changed by a user in .ps script.

Cinegy recommends using the following bitrates for Daniel2 format:

- UHD p50 4:2:0 8 bit: 600 Mbit/sec
- UHD p50 4:2:0 10 bit: 800 Mbit/sec
- UHD p50 4:2:2 8 bit: 800 Mbit/sec
- UHD p50 4:2:2 10 bit: 1 Gbit/sec

Please, note that HDR is only possible in 10-bit formats.

The decoder(s)/encoder(s) work either on the CPU, or they are executed on the GPU if the decoder was created on a video card. Though "GPU acceleration" is a commonly used term, actually it means "GPU offload". If decoding is done on the CPU and it does not cope, when we turn on NVDEC or NVENC, the GPU does not actually starts to "help" or "speed up". Similarly, the CPU does not "help" in case the encoder/decoder is assigned to GPU that does not cope (overflowed). The CPU still continues to be used for various operations related to processing but in much less extent.

It also has additional stability protection against the short-term network disconnection, so there is no need for a local copy when network conditions are expected to be stable.

The main requirement is that your network and storage should provide the sufficient performance and bandwidth for writing the required media in real time.

In Cinegy Capture we have introduced the file write buffer (“Output buffer”), which helps to keep real-time capturing even if the write speed is not enough for writing all the files with the proper speed:

If the file storage has the short-term issue and can’t push the frames on the disk in real-time, the frames are being collected in the buffer(s) and the Capture session does not fail immediately, but continues capturing, until there is free space in the buffers.

If the writing speed is slower than the real-time, filling of the output buffers may increase during the ingest, as they can’t write all the data in time. Then there are two scenarios possible:

1. If the disk speed is close to the real-time and buffers are being filled rather slowly, the session is stopped by the operator before the buffers are completely full. The ingest session will stop correctly in this case but Capture Control will indicate the ‘Session closing’ status and continue writing the data from output buffers to the disk, to avoid any data loss. How long it is going to take depends on the degree of output buffers filling. So, if the disks are slow, and there is a lot of data collected in the buffers during ingest, it may take the reasonable time until all the data are pushed to the disk – this is exactly the ‘Session closing” time. The default buffer size is 2 Gb per each output, so it may be up to 2Gb data to push on the disk in the worst case. But the big advantage is that you won’t lose any data, everything will be saved on the disk.

2. If the disk is clearly slower than the real-time, the output buffer(s) will overflow quite quickly. In this case the ingest session fails with indication in the log file ‘File write buffer overflow’. The Capture will stop pushing the data on the disk, the ‘Session closing’ status will not last long but the session will fail, as mentioned:

Let’s see it on the example.

If just one single channel with 5 outputs is run, the disk works near to the real-time (or even faster), no fails happen and Ingest closing phase is not too long, because the buffers are not filled heavily.

In case of running two channels, the disk system is unable to write all files with the required speed, and one (or more) buffers are filling fast, which leads to the ingest stop with the ‘Buffer overflow’ indication.

Therefore, it’s very important to benchmark the network/disk environment in the ‘concurrent access’ mode. Try to emulate several streams from the same machine, writing to the target storage at the same time, to see whether all of them exhibit enough speed to push uncompressed bit-rate in the real-time.

Create an account with permission to write to network shares as on the screenshot to solve the issue.

For details, please refer to https://open.cinegy.com/products/capture/11/cinegy-capture-manager/user-manual/database/ and https://open.cinegy.com/products/capture/11/cinegy-capture-manager/user-manual/cinegy-capture-archive-adapter/. 

Most possibly that you run Capture services under different user accounts and the "Region and Location" windows settings are taken from the specific user account settings. Make sure that "Region and Location" settings are the same for all user accounts.