Re: Segment Loss

Alan Sewards <asewards@...>

Hello Arne,
Thank you for your very useful comments. Responses below:
You are right that the &#92;receiving folder on the C: drive is a left over
from before I implemented the RAMdisk - the data in it is over a year old.

The Recycled folder on the RAMdisk is created by Norton Utilities. I
have tried to stop it allotting space for recycling on the Z: drive but
it tries again after a reboot! If it persists, I'll uninstall the lot.
Its useful, but not if it gets in the way of doing what you want to do!

I will keep 0.fsy on the RAMdisk with its existing directory. I
increased the RAMdisk size to 64 MB to hold the update files and larger
.fsy. I may increase it again if necessary. I have suppressed the
&#92;receiving/temp folder and specified z:&#92;received for the received data.
It all seems to be working OK.

I'm still getting the ' Cannot join channel 1 - missing key
messages' but some channel 1 data is getting through.

Best regards - Alan

a_van_belle wrote:

Hello Alan,

The Z:&#92;receiving&#92;temp folder is created automatically by Tellicast.
Your ....&#92;receiving on the C: drive below T-Systems&#92;BusinessTV-IP&#92; is
a "left over" before you configured the RAMdisk and should contain old
data (check the file dates).

There should not be a recycled folder on RAMdisk. Some Windows process
must have deleted something on Z:, causing the recycled to be created.
After a system reboot it should be gone !

Only last week when we discussed the RAMdisk with Eumetsat a new
"insight" came up.
There is no doubt, the 0.FSY file should be on RAMdisk !
And the article on the RAMdisk does tell you that temp_directory is
specified as =Z:&#92;receiving/temp
But when receiving the updates your RAMdisk should hold the larger
0.FSY and the temporary 25 Mb update file !

As David said after the file is received completely it has to be moved
to the received folder.
A move to a different drive is the same as a "copy and if successful
then delete" in Windows !
Placing the receiving/temp on the same drive as the received folder
simply turns a move command into a "rename path" and causes less IO.
As the RAMdisk is very fast I don't think this does worsen performance
, but you never know.

And to complicate this matter even more, we don't really need the
receiving/temp folder. Tellicast can write directly to the received
folder. The temp folder is only to be used if you have a image decoder
that tries to access the received file before it is completed. David's
MDM does wait for the file being completed.

At this moment (but we are in "Beta-phase" !) we can recommend to
disable the temp_directory line(s) in your ini files.
Please note that in TC244 this entry may be called tmp_directory

Arne van Belle

--- In, Alan Sewards <asewards@...> wrote:

Thanks for your comments. I will report the error messages to
find that they started on 30 May at 0902 and there are now several
hundred of them!

I am puzzled by your remarks on the &#92;receiving file setup. I find I
&#92;receiving on the C: drive below T-Systems&#92;BusinessTV-IP&#92;, and
&#92;receiving is on the RAMdrive, Z: Z contains two folders - receiving
RECYCLED. The former contains a folder named temp (which is empty) and
the 0.fsy file. The latter (Recycled) contains a folder named NPROTECT,
which in turn contains a file named NPROTECT.LOG, which is 632k and
attempts to view it are met with the statement that it is in use. I did
not tell the system to create this recycled folder or its contents, nor
did I tell it to create the temp folder. My setup of this structure
dates from about a year ago, when I edited recv.ini and
recv-channels.ini on the basis of what I understood at the time.
recv.ini specifies file_database_directory=Z:&#92;received (that is the
RAMdisk). Recv-channels.ini contains target_directory commented out,
defaulting to ./received, as it actually is, as mentioned above.
temp_directory is specified as =Z:&#92;receiving/temp. [there seems to be a
lot of confusion in this software between the UNIX / and the Windows&#92;,
with both appearing at times, as in the above specification!]
As I understand it, tqrecv puts the files with bits of segments
receiving until it has the complete segment, then it moves (or copies)
it to the received folder. The idea of using a RAMdisk seemed to arise
over this collection process, but I am now puzzled as to why we all
for it! Your comment on 'move' vs 'copy' presupposes that tqrecv is
smart enough to distinguish between the need for one or the other
depending on the source and destination drives, which may be so but I
doubt it. Your point that &#92;received and &#92;receiving should be on the
drive depends on this. Should we be using a RAMdisk for both folders?
And will be it make any difference?

Best regards - Alan

Unsure what a term means? Check the Glossary at:

Computer science
Weather equipment
Science education

Weather stations


* Visit your group "MSG-1 <>"
on the web.

* To unsubscribe from this group, send an email to:

* Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <>.

Alan Sewards

web site:

Join to automatically receive all group messages.