TSReader Software Support
TSReader Software Support
TSReader Software Support
1 of 4
http://www.tsreader.com/tsreader/support.html
TSReader
Support Information
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:
Download this tool
Run the executable inside
Click on Capture/Capture Kernel and Capture/Passthrough to disable these features
When you run TSReader, you'll see a bunch of debug info.
What do the icons superimposed on the thumbnails mean?
Icon
Meaning
Defined in
Used in
WSS packet
DVB
WSS packet
DVB
WSS packet
DVB
Teletext/VBI stream
ATSC: User data in the video stream carrying ATSC captions (EIA608)
DVB: Teletext/VBI stream
User data in the video stream carrying ATSC captions (EIA708)
DVB
ATSC
DVB
ATSC
Teletext/VBI stream
DVB
Redistribution Control
PMT descriptor
ATSC
Teletext/VBI stream
DVB
Teletext/VBI stream
Video stream
Teletext/VBI stream
DVB
Teletext/VBI stream
DVB
DVB
MPEG
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:
ftp://ftp.coolstf.com/incoming
Username: [email protected]
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
Data Input Thread
Main Process Priority
Stream Processing Thread
Thumbnail Thread
Function
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.
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.
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.
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:
Make a very short recording of the multiplex - this should only be long enough to get the PAT/PMT tables decoded.
Open this file with TSReader and after TSReader has decoded it, you'll get a message saying "Reached the end of the transport stream file".
Now select the program you want to demultiplex and click the Record Program button. Fill in the appropriate fields in the dialog.
After hitting OK, the status bar at the bottom of the TSReader window will saying "Recording to" and your filename.
Now locate the file you want to demultiplex using the Windows Explorer and drop that file onto TSReader's window.
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.
17/03/2015 11:22
TSReader Support
2 of 4
http://www.tsreader.com/tsreader/support.html
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
0x06
0x06
0x06
0x81
0x83
0x85
Descriptors
AC-3 descriptor
BSSD descriptor
DTS1/DTS2/DTS3 descriptor
None
None
None
Resulting Audio
AC3
LPCM
DTS
AC3
LPCM
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
AC3
AC3
DTS
DTS
LPCM
LPCM
Defacto/ETSI
Defacto
ETSI
Defacto
ETSI
Defacto
ETSI
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.
root
(blank)
/mnt/flash1/CinemaSix
Click OK to close the dialog and click on the PMT entry for the channel you want to stream
Click on Playback/Roku HD-1000. You should see a popup window displaying trace information and after a few seconds (depending on bit-rate) video should start playing.
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.
In TSReader, click on Playback/VLC/Settings (or type Alt+V) and choose an empty streaming configuration.
Set the description to MPEG-4
Paste this in for the command - all one line:
<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
Save this file to the root of your C: drive as c:\osd-logo.png.
Click OK and then click Playback/VLC/MPEG4.
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:
17/03/2015 11:22
TSReader Support
3 of 4
http://www.tsreader.com/tsreader/support.html
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:
Launch TSReader Professional and tune to the multiplex. Use the UDP Forwarder function to forward four channels to 127.0.0.1:1234, 127.0.0.1:1235, 127.0.0.1:1236 and 127.0.0.1:1237. This will not actually generate any network traffic - it's all internal to Windows.
Unzip this file into a folder and double-click the RunMosaic command-file. This will start VLC in command-line mode. Right now, you won't see any additional network traffic but you will see an increase in CPU load. If in doubt about the performance required, type
Ctrl+Shift+Esc to display the Windows Task Manager - select the Performance tab and ensure the CPU load is well below 100% - if its not, you need a faster processor!
Now launch VLC again using the start menu or a shortcut and tell VLC to open the HTTP network stream 127.0.0.1:1235. To do this, click File/Open Network Stream, click the HTTP/HTTPS/FTP/MMS button and in the URL field, enter 127.0.0.1:1235. After clicking OK,
you should now see a live mosaic and hear audio from the first channel. Use Audio/Audio Track to select between the four audio streams.
If you find out your PC's IP address, you can go to other computers on your network and open VLC against HTTP port 1235 on your PC and see the same stream.
The configuration for the mosaic is in the mosaic.vlm file which can be edited with any text-editor.
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
PID
PID
PID
...
PID
PID
PID
PID
0
1
0
0
continuity
continuity
continuity
continuity
0
0
1
2
0
0
1
0
continuity
continuity
continuity
continuity
15
0
1
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:
Data was lost from the satellite -- for example you have too low a signal to receive data from the multiplex reliably.
The interface card has a problem with it's DMA engine or the transport stream file is corrupt.
The packet's continuity field is being filled in incorrectly. Many multiplexers are incorrectly configured and generate a few continuity errors from time-to-time.
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:
Times out at the PID level - if no packets from the PID are received within 3 seconds
The PID doesn't contain PES data (TSReader was unable to locate PES headers in the stream)
The PES packets are scrambled (there is an option for either/both the transport and PES packets to be scrambled in MPEG-2)
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
CW East
CW West
Video PID
101
201
Audio PID
102
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
CW East
CW West
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:
17/03/2015 11:22
TSReader Support
4 of 4
http://www.tsreader.com/tsreader/support.html
Supported
Yes
Yes
MDAPI_START_FILTER
Yes
MDAPI_STOP_FILTER
Yes
MDAPI_DVB_COMMAND
Partial
Function
Returns current program number. User must select a program by clicking on a PMT entry in TSReader for this to return meaningful data.
Returns API version number. TSReader sends "MD-API Version 01.02 - 1.04"
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.
Stops data flow as a result of the MDAPI_START_FILTER.
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.
lParam Value
TSREADER_MDAPI_GET_PIDS
0x01030000
TSREADER_MDAPI_SWITCH_IP_MODE
0x01030001
TSREADER_MDAPI_DIALOG_MESSAGE_ENABLE
0x01030002
TSREADER_MDAPI_DIALOG_MESSAGE_DISABLE
0x01030003
Function
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.
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.
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.
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:
[DVBT]
481.833=746.000
505.833=690.167
529.833=777.833
537.833=826.000
561.833=786.167
578.167=802.000
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:
[EPGMAP]
6301=6903
17/03/2015 11:22