TSReader Support Information

Updated April 7, 2008

Support Information

This document is a FAQ. Please scan through it to see if there's an answer - if not, please send us email. We also suggest reading the README file - it contains lots of useful info, including command-line parameters used by TSReader. If you're not familiar with MPEG-2 transport streams, we suggest reading this document.

TSReader Standard and Professional users can download the latest TSReader versions with a valid support license (first year is included). Log into the site at http://www.coolstf.com/support. If you don't remember your username and/or password, send us email and we'll find it for you - always helps if you know your serial number when you ask.

General Issues

What are the two bars at the bottom of the TSReader window labeled in and out buffer?

These both show buffer fullness. If these indicators reach full a buffer overrun has occurred. You should shutdown TSReader and find out which process is taking CPU time up since typically that's what causes these buffers to overrun.

The top indicator shows the fullness of the buffer that's used to keep data coming in from the source (the satellite, cable, terrestrial tuner or a file). If this indicator overflows it's because the main processing thread that TSReader runs to parse the stream can't keep up with the data coming from the source.

The bottom indicator shows the fullness of the buffer that's used to stream a program out of TSReader when you use the Stradis, XNS, VLC or D-VHS interfaces. If this indicator overflows it's because the destination you're stream to can't keep up with the stream TSReader is sending it.

I've got a problem with TSReader. Is there debug trace information available to help diagnose the problem?

Yes, TSReader has a lot of debug output! You can catch this by running a third-party debug trace program such as dbgvnt:

What do the icons superimposed on the thumbnails mean?

Icon Meaning Defined in Used in
4:3 Program video is 4:3 aspect WSS packet DVB
14:9 Program video is 14:9 aspect WSS packet DVB
16:9 Program video is 16:9 aspect WSS packet DVB
422 VBI data carried as 4:2:2 encoded monochrome bitmaps Teletext/VBI stream DVB
cc Program is carrying closed-captions ATSC: User data in the video stream carrying ATSC captions (EIA608)
DVB: Teletext/VBI stream
dtvcc Program is carrying DTV closed-captions User data in the video stream carrying ATSC captions (EIA708) ATSC
itxt Inverted teletext data Teletext/VBI stream DVB
rc Redistribution Control PMT descriptor ATSC
sub Program is carrying subtitles Teletext/VBI stream DVB
txt Program is carrying teletext Teletext/VBI stream DVB
Video has user data Video stream MPEG
vps Program is carrying VPS (Video Program Service) data Teletext/VBI stream DVB
wss Program is carrying WSS (Wide Screen Signaling) data Teletext/VBI stream DVB

Why do some PIDs on the PID chart have ~ between the percentage and data rate and others have - ?

The PIDs that have the "-" between the mutliplex percentage and bit-rate have an accurate bit-rate because the PID is carrying PCR packets. As a result, TSReader is able to calculate the exact data rate for this PID. Those that have the "~" character have the bit-rate calculated by taking the multiplex rate divided the percentage of the multiplex being used by that PID, therefore the results aren't as accurate.

Why do I get thumbnails with big green pixels?

One of the ways MPEG-2 compresses video is by sending only the differences between pictures. Video is sent using one of three picture types - I (Intra) which contains a complete picture, P (Predictive) and B (Backward Predictive) which both only contain difference information between these pictures and the I picture. So in other words, to get a complete picture with none of the green pixels one must ideally wait until an I picture comes along. However, many encoders are setup to generate an I picture once a second or more and waiting for this picture could slow down thumbnail generation.

That said, it's possible to get a full picture without waiting for an I-picture. The combination of usually three pictures (a BPB sequence) is normally enough to get a full picture without any of the green noise because of the way the MPEG-2 encoders are configured. If you do see green pixels, you can change the maximum number of pictures that TSReader decodes. This option is in the Settings/Thumbnail/Refresh rate/maximum pictures dialog . By default, three pictures are processed on MPEG compliant systems, but for cases like this changing the value to four or five might be required to get a full picture. It's worth pointing out that if an I picture does come along, that will be used and the maximum count will be ignored.

There are actually two values for the maximum pictures - one for MPEG-2 video streams and the other for DCII systems. The DCII (Digicipher II) system uses MPEG-2 video but without I pictures. As a result, it can take 40 or more pictures to get a complete frame on a DCII video stream. When you watch a DCII picture (on the PC or a regular STB), you'll see green noise while the picture is built.

Occasionally, TSReader crashes as it's starting up. How can I fix this?

There might be a bug in TSReader! We've followed all the appropriate documentation well, but some SI/PSI inserters can cause TSReader to crash. We pride ourselves on having very few crashes so we would very much like to get a minute or so of the transport stream causing the issue.

There's a hidden registry value in TSReader that turns off all the SI/PSI parsing -- you just get the PID chart. And since that parsing is turned off you probably won't get the crash and can use the Record multiplex feature to grab a minute of the multiplex. Once the minute has been recorded, turn the parser back on again, launch TSReader with Ctrl down and select the File source. Let TSReader run through the recording and if it crashes, then it's time to upload the file so we can investigate and come up with a fix.

The registry value is:

HKEY_CURRENT_USER\Software\COOLSTF.com\TSReader\ParserDisabled DWORD

Set to zero (the default) the parser is enabled - set to one the parser is disabled and only the PID chart will show. There are two shortcuts in the TSReader installation folder - ParserOn.reg and ParserOff.reg - double clicking these is the equivalent of editing the registry.

Once you've got a recording, FTP it to:

Username: anonymous@coolstf.com
Password: (your email address)

Once uploaded, please drop me an email with the filename.

Does TSReader run on Windows NT?

Officially, TSReader is supported only on Windows 2000 and XP. When using TSReader on Windows NT you'll most likely find a number of source modules that display error messages because they use features provided by the operating system that aren't present in Windows NT. If you want to get rid of these error messages, delete or move to a separate folder the source modules you're not using from the TSReader/Sources folder.

What about Windows Vista?

TSReader generally runs on Windows Vista, but there are some issues with various source modules. We are planning on making a future version of TSReader with much improved Windows Vista support.

What do the Thread Priority options do?

TSReader has a number of threads that move bytes through the various processes that are needed to receive and decode MPEG-2 tranport streams. You can control the priority of each of these - for example if the CPU load is tight (you can check this with the Windows Task Manager - type Ctrl+Shift+Esc and look at the Performance tab) you might want to make TSReader run at a higher prority to ensure that TSReader doesn't drop packets.

There are three main threads and the actual Windows program priority:

Name Function
Data Input Thread This thread reads data from the input source module, if required aligns to the MPEG-2 packets and places them into a circular buffer which the Stream Processing thread then reads from. Part of this thread's code will be in the input source module and part of it inside TSReader depending on whether the source module uses TSReader to synchronize to the MPEG-2 packets.
Main Process Priority This is the priority of the Windows application part of TSReader. This part of TSReader does things like draw charts, display thumbnails and so on.
Stream Processing Thread This is the main processing thread in TSReader and listens to each packet sent by the Data Input thread. Here MPEG-2, ATSC, DVB, DCII and other types of network information are also decoded.
Thumbnail Thread This is the priority given to each of the thumbnail decoders. These threads take the ES data for each stream and then attempt to decode the bitstream. In the case of video streams, a thumbnail with a picture will be shown and for audio streams a simple chart showing volume level is created.

Recording Issues

I recorded an entire transport stream because there were two programs I wanted to capture on at the same time. I now want to split out each of these two programs into individual files. How can I do this with TSReader?

This is called demultiplexing and that's what TSReader's Record Program function is for. It generates a single program transport stream by removing packets that aren't part of the current program and builds new tables to tell the decoder what PIDs the single program is using. Follow these steps to demultiplex the file:

When the files have been demultiplexed and you're ready to do the second program simply click on it's PMT entry and drop the file onto TSReader again.

I recorded a stream with TSReader and want to record to DVD. What do I do?

Thomas Lippert from Germany was good enough to write a step-by-step guide to the process. His documentation is at http://www.denton.privat.t-online.de/tut_DVD_Creation.htm

What does the "Force PIDs to be ATSC compatible" option in the record program dialog do?

The ATSC system used to have a requirement that specific PIDs were used for the video and audio streams based on channel number within the multiplex. For example the video stream for program 1 in ATSC should use PID 0x0011 and it's primary audio stream uses PID 0x0014. I'm pretty sure this requirement has now been dropped by the ATSC, but there is probably software out there that uses this model.

Checking this option forces the PMT onto PID 0x0010, the video onto PID 0x0011 and audio to PID 0x0014 which matches channel 1 in the ATSC fixed-PID model. Leaving this unchecked causes PID 0x0020 for the PMT and the video/audio streams use their original PIDs.

What's are the "Defacto" and "ETSI" radio buttons on the record dialog for?

As usual, this MPEG-2 oddity can be blamed on General Instrument which is now part of Motorola. When the MPEG-2 specification was written there was only support for MPEG-1 or MPEG-2 audio. General Instrument wanted to use Dolby AC3 for their audio coding but had no way to tell the receiver that a PID contained AC3 audio because MPEG-2 didn't allocate a PMT type field for AC3 - just for MPEG audio. So General Instrument used one of the user defined PMT types of 0x81 for AC3 and this has now become the standard in North America - it's used on ATSC terrestrial transmissions, Dish Network's Direct-To-Home satellite service in addition to the Digicipher II system from Motorola.

When Australia was deciding which digital terrestrial standard to use (either DVB-T or ATSC), they decided they wanted DVB-T but with the ability to send either MPEG or AC3 audio. The DVB Group wanted to accommodate the Australians so they did a revision to the specs (which are published by ETSI) and now AC3 is officially supported in DVB. The problem though is that DVB used a different way to tell the receiver that an AC3 stream was present - they used PMT type 0x06 which had previously been used pretty much only for Teletext in Europe. To let receivers know that there's an AC3 stream there (and not Teletext), a special descriptor is included with the PMT - if the receiver sees this registration descriptor and it's the right value, then the receiver can conclude the stream is AC3.

On the input side, when TSReader looks at a stream it can handle either "Defacto" or "ETSI" ways of doing non-MPEG audio. The following table lists the additional audio formats supported by TSReader:

PMT Type Descriptors Resulting Audio
0x06 AC-3 descriptor AC3
0x06 BSSD descriptor LPCM
0x06 DTS1/DTS2/DTS3 descriptor DTS
0x81 None AC3
0x83 None LPCM
0x85 None DTS

The "Defacto" and "ETSI" options are only used for recording or streaming from TSReader. TSReader always adds descriptors to the stream regardless of whether the PMT type is Defacto or ETSI.

Audio Stream Defacto/ETSI Resulting PMT Type
AC3 Defacto 0x81
AC3 ETSI 0x06
DTS Defacto 0x85
LPCM Defacto 0x83

Playback & Streaming Issues

How do I play a channel with XBox Media Player?

This assumes you've already got XBox Media Player operational and you know how to FTP into your XBox.

 <name>TSReader via XNS</name>

How to do I play a channel with XBox Media Center?

Same guidelines for XBox Media Player, but the XML is slightly different. You need to:

 <name>TSReader via XNS</name>

What are the steps to stream over a network using TSReader and VLC?

Let's imagine your PC with the card running TSReader has an IP address of and the computer you want to stream to is


<IP> :sout=#duplicate{dst=std{access=udp,multiplex=ts,url=}}

You now may want to experiment with the Stream Output settings. For example you can check the audio and video transcode options and reduce a high-bandwidth MPEG-2 stream into an MPEG-4 stream to send over the Internet. Obviously lots of bandwidth and fast processors on both ends are required to make this reliable.

What are the steps required to stream to a Roku HD-1000?

Follow these steps:

Roku HD1000 IP/Name IP address of the Roku HD-1000. This can be obtained by selecting the Setup option on the Roku HD-1000. It's shown at the top the screen.
Username root
Password (blank)
CinemaSix Location /mnt/flash1/CinemaSix

How about streaming video to remote clients?

TSReader and VLC can do that very easily. Make sure you're using build 2.6.44 of TSReader or later though since there was a bug with long VLC command-strings in prior builds.

<IP> :sout=#transcode{vcodec=mp4v,vb=256,scale=1,width=320,height=240,fps=15,sfilter=time:logo,acodec=mp3,ab=48,channels=2}:duplicate{dst=display,dst=std{access=http,multiplex=asf,url=:1235}} --time-format="%H:%M:%S" --time-x=10 --time-y=15 --time-size=30 --time-color=0xfefefe --time-opacity=255 --logo-file="c:\osd-logo.png" --logo-x=10 --logo-y=10 --logo-transparency=255

VLC will start and you should get a screen with the MPEG-2 source transcoded to MPEG-4 along with a TSReader logo and the current time. Provided you're watching NASA TV, it'll look very similar to this:

But that's not all - VLC is also running an HTTP server on port 1235 of your PC with the same stream. So go to another PC (or anything that runs VLC) and open http://your-pc-ip-address:1235 and you'll see the same video. If you also configure your router correctly, this stream can be shared over the internet.

I see TSReader Professional has a still video mosaic function, but I want a live mosaic with audio. How can I do that?

VLC's mosaic feature can do this - it takes a number of streams, decodes them, loads them onto a background and runs this through a video encoder so the mosaic can be streamed just like any other video/audio stream. The following steps generate a 640x480 MPEG-2 encoded mosaic that runs at 5Mbps:

VLC won't play some H.264 content. How can I work around this?

The current versions of VLC don't support an H.264 feature called MBAFF. This results in a gray looking picture along with a quick crash. Its obviously worthwhile keeping an eye out for new builds of VLC to see if this problem is fixed, but a workaround (although not perfect) is to use Media Player Classic along with a commercial H.264 codec.

You'll need to get Media Player Classic (MPlayerC from now on) from Sourceforge at http://sourceforge.net/projects/guliverkli/x and unless you've already got a video card that comes with a codec for H.264, purchase a license for CoreAVC at http://www.coreavc.com/. Once this has been done, try recording the program to the hard drive and then opening it up with MPlayerC to ensure it plays correctly.

Then in TSReader, tell it to use MPlayerC rather than VLC for playback. Click Playback/VLC/Settings... and change the VLC executable to MPlayerC.exe in the appropriate folder and then ensure the default playback command just <IP>. You should then be able to double click on the thumbnail for the program you want to watch and MPlayerC rather than VLC will now handle playback.

Stream Issues

Please explain what continuity errors mean?

An MPEG-2 transport stream contains data in 188-byte packets. The first four byes of each packet are header and flags and then there's 184 bytes of payload data - video, audio, tables, IP data -- you name it.

In the header, there's a 13-bit field (range 0-8191 decimal) which is the Packet ID (PID) of the packet currently being sent. There is also a four bit field (range 0-15) called the continuity counter. This field increments for each packet sent on that PID. For example, one might see a sequence like:

PID 0 - continuity 0
PID 1 - continuity 0
PID 0 - continuity 1
PID 0 - continuity 2
PID 0 - continuity 15
PID 0 - continuity 0
PID 1 - continuity 1
PID 0 - continuity 1

This field is used by receivers (and programs like TSReader) to make sure that the transport stream data is continuous, i.e. it hasn't lost packets. If a receiver tracks the continuity it can determine if packets on a particular PID were lost -- for example if the satellite signal is interrupted. It handles cases except the case when exactly 16 packets (or multiples of 16 packets) were lost on a single PID which is unlikely.

So, given that they indicate packet loss, there are a few reasons why you might see continuity errors displayed in TSReader:

The general rule is that if you see only one or two continuity errors per second you're probably OK but if the continuity counter increments quickly, there's something wrong.

What about TEI errors?

Most MPEG-2 networks use some form of forward error correction on the stream as it is transmitted so that errors in stream as seen by the receiver can be corrected. Some MPEG networks use multiple error correction schemes because they "do better" handling different types of interference to the transmitted signal. Generally speaking most MPEG networks use at least the Reed-Solomon error correction algorithm. On MPEG networks this error correction code can fix up to eight errored bytes in each transport stream packet with only a 16 byte overhead.

However, if the Reed-Solomon decoder isn't able to correct the errors (too many of them), demodulators change a bit in the transport stream header to tell the demultiplexer that the packet has an uncorrectable error. This is flag is called the Transport Error Indicator or TEI.

What causes "ES has been blacklisted" when I click on an elementary stream?

TSReader tries to figure out encoder parameters for video and audio streams it encounters in the multiplex. To do this, it demultiplexes the transport stream packets associated with the stream down to PES packets which is what's really carried on the PID. Once TSReader has built a PES packet, it scans the packet to find the encoder parameters - resolution and frame rate for video, bit-rate and sampling frequency for audio for example.

There are a number of things that can prevent TSReader from doing this right. For example, if the transport stream packets being looked at have the scrambled bits set (indicating a scrambled stream), TSReader ignores that stream. This situation doesn't cause blacklisting because the stream might later be scrambled, but say for example that an encoder is setup to generate a video stream and two audio streams and both are described in the PAT/PMT in the multiplex. Imagine the encoder has a problem and is actually only outputting one audio stream - TSReader has been told via the PAT/PMT that a stream is there but no packets are received on that PID and as a result, the code that's trying to parse the elementary streams hangs waiting for that data on the PID.

So, ES blacklisting occurs when TSReader encounters a stream that:

What are manual channels and how do I define them?

TSReader is able to determine which PIDs are carrying the video and audio streams that make up an MPEG-2 delivered channel by looking at the PAT and PMT that are carried as part of a standard MPEG-2 transport stream. Sometimes broadcasters elect not to send these tables - TSReader can't figure out which are audio and video without manual defining them.

For this example we'll define two channels that are in the Warner Brothers multiplex on Galaxy 11 3720 H 26.700 MSps. These channels will not show up on any receiver unless you manually define the channel since the multiplex doesn't contain a PAT or PMTs.

Looking at the Galaxy 11 page on Lyngsat we see that thw two channels use the following PIDs:

Channel Video PID Audio PID
CW East 101 102
CW West 201 202

Lyngsat shows PIDs in decimal, so if you're running TSReader in its default hexadecimal mode, you need to convert the PIDs to hex. Below we've shown them for these channels, but if you need to do it in the future and don't know, it can be easily done using the calculator that comes with Windows. You need to switch it to Scientific mode which is on the View menu. Once this is done, make sure the Dec button is selected, type the PID in decimal and then click the Hex button - you'll then see the PID in hex.

Channel Video PID (hex) Audio PID (hex)
CW East 65 66
CW West c9 ca

Now launch TSReader and click on File, Define Manual channels. On the dialog that's shown, click the Add... button and you'll see this dialog:

Follow these steps to setup the first manual channel:

If you wanted to add more elementary streams to the channel (for example multiple audio streams for multi-lingual channels) you'd continue as shown above, but since we've added all the elementary streams, hit OK for now.

You can now define the remaining channels and once done, we suggest saving the manual channels to a file should you tune that multiplex again. This feature is on the File menu.

These manual channels can be treated just like regular channels - recording and streaming will work just like other channels provided you got the parameters right of course. There are also command-line options to automatically load a manual channel definition file. This is documented in the command-line page.

MultiDec API

How do I make plug-in modules written for MultiDec (and a bunch of other programs like MyTheater and ProgDVB) work with TSReader?

Simply put the files into a folder called MDPlugins in the TSReader folder. The plug-in's menu should then show up in TSReader next time it's launched.

Please note that TSReader does not contain a descrambler implementation such as the DVB Common Scrambler since we don't have rights to implement this patented algorithm. However, CSA descrambling can be achieved in TSReader by locating either ffdecsa_64_mmx.dll or csa.dll on the Internet and placing either file into the MDPlugins folder. ffdecsa_64_mmx.dll has a significantly lower load on the CPU as csa.dll does, so its obviously preferred.

What MD-API commands are supported by TSReader?

wParam Supported Function
MDAPI_GET_PROGRAMM_NUMMER Yes Returns current program number. User must select a program by clicking on a PMT entry in TSReader for this to return meaningful data.
MDAPI_GET_VERSION Yes Returns API version number. TSReader sends "MD-API Version 01.02 - 1.04"
MDAPI_START_FILTER Yes Allows a plug-in to receive transport stream packets from a specified PID. TSReader allows up to 256 filters active at any one time. Data is sent as 184 byte packets (i.e. no transport stream header) with 9 packets sent at a time.
MDAPI_STOP_FILTER Yes Stops data flow as a result of the MDAPI_START_FILTER.
MDAPI_DVB_COMMAND Partial TSReader only supports CA key messages that will be passed to a DLL that provides Common Scrambling Algorithm decoding. Such DLLs are not included with TSReader because we do not have a license from the patent holders to include such code. However, software that implements such functions can be found on the Internet. TSReader supports both the original csa.dll and significantly faster FFDecsa_64_MMX.dll which should be placed in the MDPlugins folder.

What special MD-API commands are supported by TSReader?

The following special sequences are supported in non-Lite versions of TSReader.

Mnemonic lParam Value Function
TSREADER_MDAPI_GET_PIDS 0x01030000 Returns the PID list. The list is 8192 bytes long, one byte per PID. If the PID is active a 1 is returned - if the PID is active and scrambled a 2 is returned. 0 means no activity on that PID. You should provide a pointer to your 8K array in lParam.
TSREADER_MDAPI_SWITCH_IP_MODE 0x01030001 Switches in and out of IP mode. lParam points to an array of integers (4 byte, sign unimportant) which specify the PIDs to parse as MPE packets either in ATSC or DVB encapsulation mode. The array should end in 0x1fff and to switch back to MPEG-2 transport stream, provide a pointer to an array with a single element with value of 0x1fff.
TSREADER_MDAPI_DIALOG_MESSAGE_ENABLE 0x01030002 Plugins that have an hWnd receive their messages through TSReader's main message pump which does not use the IsDialogMessage() Win32 API call. By using this message and specifying your plugin's hWnd in lParam, TSReader will use IsDialogMessage() before dispatching the message to your message pump.
TSREADER_MDAPI_DIALOG_MESSAGE_DISABLE 0x01030003 Disables the IsDialogMessage() processing. You should make this call as your plugin's hWnd closes, typically in the WM_DESTROY event. lParam should contain your plugin's hWnd.

How can I receive the entire transport stream packet in a MultiDec plugin?

When you setup the PID filter in your plugin, set the top bit of the 16-bit PID field, i.e. nPID |= 0x8000. You'll then receive 188 byte packets in the filter one at a time (or 131 bytes if in DSS mode). Without this bit set, MultiDec plugins get five transport packets with the four byte transport packet header from each packet missing for a total of 920 bytes at a time.

Source Issues

I selected the wrong source - how can I change it?

Launch TSReader with the Ctrl key held down - you'll then be asked to choose a source again.

I've built my own satellite interface. How can I get TSReader to communicate with it?

Write a TSReader source module. This is a standard DLL that provides the interface between TSReader and all hardware. There's a sample TSReader source provided in source-code format in the TSReader\SampleSource folder.

I'm using a BDA-based source module on Windows MCE. Sometimes my card won't tune and TSReader locks up. Why?

Most likely, the Windows MCE Receiver Service is running and that's using the card TSReader is attempting to use. Stop the Receiver Service by going to the command prompt and typing:

net stop ehrecvr

Scheduler Issues

I entered my username & password in the EPG Grid Settings dialog, but when I try to schedule a recording, TSReader says it couldn't create the schedule. Why?

You probably are logged onto a Windows domain controller. You have to specify your username as DOMAIN/Username.

Why whenever I schedule a DVB-T recording does TSReader report that it couldn't lock the signal?

You're probably receiving your signals through a relay station. Most of the relays don't correctly update the network table (NIT) to reflect the frequencies they're actually transmitting on, but rather use a thing called a frequency list descriptor - if you click on an NIT entry you'll see these listed in the TSReader text window. So, TSReader is scheduling recordings based on the NIT frequency and has no way that we currently know of to find which relay frequency to actually tune to.

To work around this, create a file called DVBT.INI in the folder where TSReader is installed. The format of this file is simply the full frequency from the NIT and an equal sign along with the relay frequency for the same multiplex along with a [DVBT] tag at the start of the file. Here's a sample for the UK for a DVB-T relay that covers a town near London:


TSReader is recording the wrong channel on Sky when used with a Cielplus interface. How can I fix this?

This problem seems to occur because BBC1 London is listed as channel 6301 in the EPG, but actually the correct program number is 6903. So this mixup causes TSReader to not record anything when the scheduler is used. To fix the problem, make a text file called EPGMAP.INI in the TSReader folder with the following text: