Date   
Re: not yet perfect, but...

ernstlobsiger
 

--- In MSG-1@..., "Ulrich G. Kliegis" <Ulrich.Kliegis@...> wrote:



An: MSG-1@...
Von: "ernstlobsiger" <ernst.lobsiger@...>
Datum: Sun, 06 Mar 2011 16:13:27 -0000
Betreff: [MSG-1] Re: not yet perfect, but...
Antwort an: MSG-1@...

I think it should read "tmp_directory" instead of "temp_directory" in
recv-channels.ini.
Ernst,
danke für den Kommentar, but temp... seems to be the pregiven spelling in
the original sample, as I have it here.

Reducing the max rate to 20E6 did not change anything.

I also commented out EPS 5 temporarily - (almost) no effect. at least, in this
phase (about 15:50 UT) the rate of not-recovered packets grew.
Switching off a Dexatrek USB receiver (same as the world box) being
connected to a different PC two meters (about 6.7 ft) away, - no effect (I
suspected the open output socket, but it wasn't the culprit yet.) Connecting
the LNB cable shielding to a solid ground - nothing.

Ernst, the (temporary) temp_directory in recv.ini was derived from David's
question.

Alan, the board "looks good", no bad elcaps.

I feel a bit embarassed that just mine (out of millions of PCs running David's
software) makes such troubles. Hadn't I installed MRTG, everything would
look fine... :)

Cheers,
U.
Ulrich

When I google for "tmp_directory" or "temp_directory" and "recv.ini" I still beleive it should read "tmp_directory" ...

I looked up the proposal of a common "tmp_directory" under [parameters] in recv.ini on David's site. It seem possible but as you have the MSG1 and EPS data on different paritions or even Disks, this is really a bad idea. You must have the tmp_directory on the disk and partition where you finally put the data: As soon as a file is complete in the "tmp_directory" it will be moved to it's final place. If this is on the same partition only the "name" entry will be adjusted. If it's an another partition the whole data has to be recopied and the original data deleated. Not good ...

Hope this helps.

Ernst

Re: not yet perfect, but...

Ulrich G. Kliegis
 

An: <MSG-1@...>
Von: "David J Taylor" <gm8arv@...>
Datum: Sun, 6 Mar 2011 17:29:20 -0000
Betreff: Re: [MSG-1] not yet perfect, but...
Antwort an: MSG-1@...

Just to check, you /do/ have a tmp_directory entry in your
recv.ini:

_____________________________________
[parameters]
tmp_directory=temp
_____________________________________

pointing to the same partition as all the other receive
directories?
How could this box run for years without the tmp definition in the
parameters section - don't ask me why, when, how, this recv.ini file
was ported from installation to installation... At least, there was
no tmp_directory entry.
Yes, it may be that you need to add this entry by hand.

Hmm, Alan Sewards says it is not necessary since the pointers are in the
recv-channels.ini file.

I don't dare to ask, who's right, but rather, what is recommended?


...

_____________________________________
[EUMETSAT Data Channel 2]
target_directory=F:&#92;received
tmp_directory=F:&#92;receiving&#92;tmp
_____________________________________


You are correct that with the data on different disks, one common entry in
recv.ini would not provide the best solution. By the way: I hope that is
two different physical disks, otherwise you will have the disk head madly
Yes, two drives, physically different. E: ist 250 GB, F: 400 GB.


Cheers,

U.

Re: not yet perfect, but...

Ulrich G. Kliegis
 

An: <MSG-1@...>
Von: "David J Taylor" <gm8arv@...>
Datum: Sun, 6 Mar 2011 17:29:20 -0000
Betreff: Re: [MSG-1] not yet perfect, but...
Antwort an: MSG-1@...

Just to check, you /do/ have a tmp_directory entry in your
recv.ini:

_____________________________________
[parameters]
tmp_directory=temp
_____________________________________

pointing to the same partition as all the other receive
directories?
How could this box run for years without the tmp definition in the
parameters section - don't ask me why, when, how, this recv.ini file
was ported from installation to installation... At least, there was
no tmp_directory entry.
Yes, it may be that you need to add this entry by hand.

Hmm, Alan Sewards says it is not necessary since the pointers are in the
recv-channels.ini file.

I don't dare to ask, who's right, but rather, what is recommended?


...

_____________________________________
[EUMETSAT Data Channel 2]
target_directory=F:&#92;received
tmp_directory=F:&#92;receiving&#92;tmp
_____________________________________


You are correct that with the data on different disks, one common entry in
recv.ini would not provide the best solution. By the way: I hope that is
two different physical disks, otherwise you will have the disk head madly
Yes, two drives, physically different. E: ist 250 GB, F: 400 GB.

I'll purge some 'e's from the temp-trm then and see...

Changing the architecture altogether could be one of the next steps.

The reason for coupling the temp and target files on the same disk / partition
was given here some years ago: That the files that would land in the target
directory in the end are composed piece by piece in the temp files, and that
moving them to the target then means just a change in the FAT. Isn't that
true any more on NTFS formatted disks (not sure to which generation this
old wisdom related).

Cheers,

U.

Re: not yet perfect, but...

ernstlobsiger
 

--- In MSG-1@..., "Ulrich G. Kliegis" <Ulrich.Kliegis@...> wrote:



An: <MSG-1@...>
Von: "David J Taylor" <gm8arv@...>
Datum: Sun, 6 Mar 2011 17:29:20 -0000
Betreff: Re: [MSG-1] not yet perfect, but...
Antwort an: MSG-1@...

Just to check, you /do/ have a tmp_directory entry in your
recv.ini:

_____________________________________
[parameters]
tmp_directory=temp
_____________________________________

pointing to the same partition as all the other receive
directories?
How could this box run for years without the tmp definition in the
parameters section - don't ask me why, when, how, this recv.ini file
was ported from installation to installation... At least, there was
no tmp_directory entry.
Yes, it may be that you need to add this entry by hand.

Hmm, Alan Sewards says it is not necessary since the pointers are in the
recv-channels.ini file.

I don't dare to ask, who's right, but rather, what is recommended?


...

_____________________________________
[EUMETSAT Data Channel 2]
target_directory=F:&#92;received
tmp_directory=F:&#92;receiving&#92;tmp
_____________________________________


You are correct that with the data on different disks, one common entry in
recv.ini would not provide the best solution. By the way: I hope that is
two different physical disks, otherwise you will have the disk head madly
Yes, two drives, physically different. E: ist 250 GB, F: 400 GB.

I'll purge some 'e's from the temp-trm then and see...

Changing the architecture altogether could be one of the next steps.

The reason for coupling the temp and target files on the same disk / partition
was given here some years ago: That the files that would land in the target
directory in the end are composed piece by piece in the temp files, and that
moving them to the target then means just a change in the FAT. Isn't that
true any more on NTFS formatted disks (not sure to which generation this
old wisdom related).

Cheers,

U.
Ulrich

What I recommend is to # comment out the "tmp_directory" entry in recv.ini and use "tmp_directory" entries in recv-channels.ini only.

[EUMETSAT Data Channel 2]
target_directory=F:&#92;received
tmp_directory=F:&#92;receiving&#92;tmp

For the data that go to drive E: you use accordingly
...
tmp_directory=E:&#92;receiving&#92;tmp


Then you start end check whether these tmp_directories exist and work.

The files are assembled in the file on your ram-disk. Then they are written to the "tmp_directory". Finally they are moved out to the final position which is just a "rename" as long as the tmp_directory is on the same partition as the final "target" data directory. That's why you have to use at least 2 tmp_directories if you have 2 disks.

Hope this helps. And again, please try "tmp_directory" and not "temp_directory" ...

Cheers
Ernst

Re: not yet perfect, but...

David J Taylor
 

Hmm, Alan Sewards says it is not necessary since the pointers are in the
recv-channels.ini file.

I don't dare to ask, who's right, but rather, what is recommended?
Both are correct.

- If you have a single &#92;received&#92; directory tree, then only the recv.ini entry is required, but it is not provided by default.

- With separate disks for certain &#92;received&#92; directories, then a per-channel tmp_directory entry is required, pointing to the same partition as the &#92;received&#92; directory.

- Having two partitions on the same hard disk, for separate &#92;received&#92; directories is not recommended.

Nothing new in the above, but perhaps clarifying what I said before. Yes, it's still true even with NTFS that a rename (on the same partition) is a much cheaper operation than a disk-to-disk copy.

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...

Re: not yet perfect, but...

Alan Sewards
 

Hi folks,
I'd just like to note that in the early T-Systems software the syntax for the temp_directory was temp_directory= in the recv.ini and recv_channels.ini file comments. A few years ago, during one of the updates of the software, this got re-spelled as tmp_Directory= . My recv_channels.ini still has the temp spelling but I may well still be running the older software, that computer has been running for three years now.

I think with most OS, a move is easier than a copy.

Best regards - Alan S

On 06/03/2011 8:21 PM, David J Taylor wrote:
> Hmm, Alan Sewards says it is not necessary since the pointers are in the
> recv-channels.ini file.
>
> I don't dare to ask, who's right, but rather, what is recommended?

Both are correct.

- If you have a single &#92;received&#92; directory tree, then only the recv.ini
entry is required, but it is not provided by default.

- With separate disks for certain &#92;received&#92; directories, then a
per-channel tmp_directory entry is required, pointing to the same
partition as the &#92;received&#92; directory.

- Having two partitions on the same hard disk, for separate &#92;received&#92;
directories is not recommended.

Nothing new in the above, but perhaps clarifying what I said before. Yes,
it's still true even with NTFS that a rename (on the same partition) is a
much cheaper operation than a disk-to-disk copy.

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...
<mailto:david-taylor%40blueyonder.co.uk>

--
Alan Sewards
email: alan@...
web site: http://asewards.free.fr

Re: not yet perfect, but...

Ulrich G. Kliegis
 

An: MSG-1@...
Von: "ernstlobsiger" <ernst.lobsiger@...>
Datum: Sun, 06 Mar 2011 19:15:23 -0000
Betreff: [MSG-1] Re: not yet perfect, but...
Antwort an: MSG-1@...

What I recommend is to # comment out the "tmp_directory" entry in
recv.ini and use "tmp_directory" entries in recv-channels.ini only.
Done already hours ago... :) Even more: I deleted the line!

When I had changed all temp...-entries to tmp* in recv-channels.ini, I first
thought, bingo!, that was it! several minutes no missed packet appearing in
the tellicasts statistics.

Then, all of a sudden, "hell broke lose" again - and I saw that that was the
same time that the life AVHRR data from NOAA came in. At least a coarse
coincidence. Then a non-maskable interrupt happened: My wife called me
for dinner. So, I couldn't pursue it any further at that time...

Cheers,
U.

Re: not yet perfect, but...

Ulrich G. Kliegis
 

I'd just like to note that in the early T-Systems software the syntax
for
the temp_directory was temp_directory= in the recv.ini and
recv_channels.ini file comments.
Alan,
that's what my memory also told me. I kept the ini-files through the version
change, if I remember correctly.

What could have happened when the T-Systems-software didn't find it's
t(e)mp folders? It works with tmp... now, but also worked with temp - and
since I upgraded to the Big Toro dish, I had no missing frames any more
(had them with the old Thomson dish).

But this doesn't cure my (diagnosis-induced) symptoms yet...
Sorry, can't deny my background... ;/

Cheers,

U.

Re: not yet perfect, but...

David J Taylor
 

Hi folks,
I'd just like to note that in the early T-Systems software the syntax
for the temp_directory was temp_directory= in the recv.ini and
recv_channels.ini file comments. A few years ago, during one of the
updates of the software, this got re-spelled as tmp_Directory= . My
recv_channels.ini still has the temp spelling but I may well still be
running the older software, that computer has been running for three
years now.

I think with most OS, a move is easier than a copy.

Best regards - Alan S
Alan,

Thanks for the note on the syntax on earlier versions.

If you are not running either version 2.4.4 B or version 2.4.4a of the TelliCast client I would suggest that you update. Either of those two versions is OK, but older versions may have problems with some of today's data. 2.4.4a appears to date back to October 2006.

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...

Re: not yet perfect, but...

Alan Sewards
 

David,
Thank you for the info on the Tellicast versions. I have checked and am running 2.4.4a, which gives me no trouble and as it ain't broke, I'm not going to fix it. When the new release is finally made with all the improvements, I will probably upgrade.

Best regards - Alan S

On 07/03/2011 8:13 AM, David J Taylor wrote:
Hi folks,
I'd just like to note that in the early T-Systems software the syntax
for the temp_directory was temp_directory= in the recv.ini and
recv_channels.ini file comments. A few years ago, during one of the
updates of the software, this got re-spelled as tmp_Directory= . My
recv_channels.ini still has the temp spelling but I may well still be
running the older software, that computer has been running for three
years now.

I think with most OS, a move is easier than a copy.

Best regards - Alan S
Alan,

Thanks for the note on the syntax on earlier versions.

If you are not running either version 2.4.4 B or version 2.4.4a of the
TelliCast client I would suggest that you update. Either of those two
versions is OK, but older versions may have problems with some of today's
data. 2.4.4a appears to date back to October 2006.

Cheers,
David
--
Alan Sewards
email: alan@...
web site: http://asewards.free.fr

Re: not yet perfect, but...

David J Taylor
 

What could have happened when the T-Systems-software didn't find it's
t(e)mp folders? It works with tmp... now, but also worked with temp - and
since I upgraded to the Big Toro dish, I had no missing frames any more
(had them with the old Thomson dish).

But this doesn't cure my (diagnosis-induced) symptoms yet...
Sorry, can't deny my background... ;/

Cheers,

U.
Ulrich, without the tmp_directory, TelliCast will build up the final files in situ, so that there is a danger that programs will try and use the data before it is complete. My own software tries to guard against this, of course, but having the tmp_directory helps ensure file integrity.

On one underpowered PC I have put the tmp_directory on RAMdisk to reduce losses, but that was a single-core PC receiving all the data, including a full Metop stream. (This with the newer 2.5.17 client which does not use FSY files).

Your losses seem to be strongly correlated with data throughput. I do notice that your throughput seems a lot higher than I would expect for a SkyStar card. My main PC, which takes Meteosat-9 full scan, EARS AVHRR, Metop AVHRR, and MODIS-L1 data, has a daily throughput of 400kB/s, whereas yours seems to be in excess of 800kB/s.

http://www.satsignal.eu/mrtg/feenix_dvb.html
http://eumetmon.rummelecke.de/windbuedel_dvb.html

No chance you've left the "*" entry somewhere in recv-channels.ini? It seems unlikely, as you would rapidly run out of disk space! But why is your throughput twice mine? If you aren't using IASI or GOME data, I would suggest commenting out the entries in recv-channels.ini for the moment.

What version of the SkyStar and TelliCast software do you have?

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...

Re: not yet perfect, but...

David J Taylor
 

David,
Thank you for the info on the Tellicast versions. I have checked and am
running 2.4.4a, which gives me no trouble and as it ain't broke, I'm not
going to fix it. When the new release is finally made with all the
improvements, I will probably upgrade.

Best regards - Alan S
2.4.4a is the latest released version, Alan, so there's no suggestion that you should upgrade. I did not mean to give that impression. There /will/ be a new version at some point in the future, and it's possible that it will eventually become a mandatory update some time after its release.

2.4.4a works a little better than the 2.5.17 version, in fact!

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...

Re: not yet perfect, but...

Ulrich G. Kliegis
 

An: <MSG-1@...>
Von: "David J Taylor" <gm8arv@...>
Datum: Mon, 7 Mar 2011 07:42:33 -0000
Betreff: Re: [MSG-1] not yet perfect, but...
Antwort an: MSG-1@...

No chance you've left the "*" entry somewhere in recv-channels.ini?
Nope, even not in white print on white paper.

I am just experimenting a bit now - directed the tmp to 50 MB of free space
on the RAM disk for Eumetsat Channels 1 ad 2 - and commented out EPS-
5.

Cheers,
U.

Re: not yet perfect, but...

David J Taylor
 

No chance you've left the "*" entry somewhere in recv-channels.ini?
Nope, even not in white print on white paper.

I am just experimenting a bit now - directed the tmp to 50 MB of free space
on the RAM disk for Eumetsat Channels 1 ad 2 - and commented out EPS-
5.

Cheers,
U.
Ulrich,

If you are taking MODIS-L1 data (or VGT4Africa) 50MB may not be enough - I have seen files up to 85MB. But for a test, it's a start. [EPS-11] (IASI) is another major data throughput source.

I might suggest starting small and building up - a fairly comprehensive list would be something like:

[DWDSAT]
[EPS-10]
[EPS-15]
[EPS-18]
[EUMETSAT Data Channel 1]
[EUMETSAT Data Channel 2]
[EUMETSAT Data Channel 3]
[EUMETSAT Data Channel 4]
[EUMETSAT Data Channel 11]
[Info-Channel-1]
[Info-Channel-2]
[SAF-Africa]
[SAF-Americas]
[SAF-Europe]
[SAF-Global]

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...

Re: not yet perfect, but...

ernstlobsiger
 

--- In MSG-1@..., "Ulrich G. Kliegis" <Ulrich.Kliegis@...> wrote:



An: <MSG-1@...>
Von: "David J Taylor" <gm8arv@...>
Datum: Mon, 7 Mar 2011 07:42:33 -0000
Betreff: Re: [MSG-1] not yet perfect, but...
Antwort an: MSG-1@...

No chance you've left the "*" entry somewhere in recv-channels.ini?
Nope, even not in white print on white paper.

I am just experimenting a bit now - directed the tmp to 50 MB of free space
on the RAM disk for Eumetsat Channels 1 ad 2 - and commented out EPS-
5.

Cheers,
U.
Ulrich

I may be wrong but I don't think putting the "tmp_directory" on a RAM disk does any good. The data must be moved to the hard disk E: or F: later anyway. This move will then be a full data copy that you postponed with "tmp_directory" on the RAM disk only.

As David pointed out, you have a high troughput on your DVB interface. I had a longer discussion with David about what throughput means on Windows and GNU/Linux. If my brain serves me right I think the bottom line was that under Windows with a SkyStar and MRTG you see the trougput that finally (maybe with some TelliCast decompression) will reach your hard disks. With an USB box under Windows and MRTG throughput seems to be as with GNU/Linux, see below.

If this is right so far, it means that you have licensed a real lot of data with EUMETSAT and try to get them all. The recv-channels.ini you posted is allmost like take all ("*").

Under GNU/Linux I see the whole traffic on my dummy interface which is even 50% higher than yours but I only take about 30% of it to disk. You can look at my receivers under

See http://www.gymalp.ch/~eumetcast

at the bottom of the page. Monitoring is done with RRDTool/Eluna here (not MRTG).

This all means that the SkyStar 2.6D can cope with the full traffic without problems while the TelliCast Client may get in trouble assembling, decompressing and writing everything to disk. So David's advice to slowly build up your recv-channels.ini is certainly a good thing.

I noted one more thing: It appears to me that your FSY file on RAM disk reaches it's top very fast all the time. You posted something like seeing error free reception for some minutes when you started. If you rebooted and your FSY file was recreated with 0 bytes first, this could have been some 5-7 minutes until your 325MB FSY file is full if it cannot be emptied to the tmp_directories as normal.


So here is some points you can follow if not already done long ago:

1)
It seems that older TelliCast Clients really used "temp_directory" which is now "tmp_directory". So double check what it is for your TelliCast Client I don't know the version of. Look under the TelliCast WEB interface, Help, File Formats.

2)
Try to direct everything to one HD (F:?) before using both (F: and E:). Newer SATA drives use AHCI and the like ... As I understood it worked on F: before without problems.

3)
Are the tmp_directories really generated and used? Is there a slight chance that your client has an access problem because it has not sufficient rights somewhere? It seems you had a problem of that kind with MRTG before?! Same when run as administrator?

4)
In recv.ini under [logging] set "log_level=normal" and restart with an empty FSY (reboot). Then wait some minutes and look what the "recv.log" file says ...

5)
Instead of using "tmp_directories" in "recv-channels.ini" at all you could use an entry in "recv.ini"under "[parameters]" "tmp_suffix=.tmp". This is from my GNU/Linux version, so please check that this exists with the same syntax in your Windows Client (Again check on your TelliCast WEB interface, Help, File Formats, ...).


Happy testing.

Cheers
Ernst


P.S.
Your post of the recv.ini and recv-channels.ini showed "[recv.ini]" "[recv-channels.ini]"
as head and "[EOF]" as tail. You probably added that to clarify the post, it should not be in these ini files otherwise ...

Re: not yet perfect, but...

David J Taylor
 

I may be wrong but I don't think putting the "tmp_directory" on a RAM disk does any good. The data must be moved to the hard disk E: or F: later anyway. This move will then be a full data copy that you postponed with "tmp_directory" on the RAM disk only.
Ernst, it does help with the 2.5.17 client as the tmp_directory is used instead of the FSY files, but whilst it is an extreme measure, writing to the RAMdisk will be faster and use less resources than writing to HD. It /may/ be worth trying.

[]
I noted one more thing: It appears to me that your FSY file on RAM disk reaches it's top very fast all the time. You posted something like seeing error free reception for some minutes when you started. If you rebooted and your FSY file was recreated with 0 bytes first, this could have been some 5-7 minutes until your 325MB FSY file is full if it cannot be emptied to the tmp_directories as normal.
[]
4)
In recv.ini under [logging] set "log_level=normal" and restart with an empty FSY (reboot). Then wait some minutes and look what the "recv.log" file says ...
[]
Happy testing.

Cheers
Ernst
Yes, I had been assuming that Ulrich had checked the log file for obvious errors like; "No space in FSY database", but whether I asked or not I now forget!

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...

Re: not yet perfect, but...

Ulrich G. Kliegis
 

An: MSG-1@...
Von: "ernstlobsiger" <ernst.lobsiger@...>
Datum: Mon, 07 Mar 2011 12:04:37 -0000
Betreff: [MSG-1] Re: not yet perfect, but...
Antwort an: MSG-1@...

Ernst,
again, thanks for your comments and helpful hints.


Ulrich

I may be wrong but I don't think putting the "tmp_directory" on a RAM
disk does any good. The data must be moved to the hard disk E: or F:
later anyway. This move will then be a full data copy that you
postponed with "tmp_directory" on the RAM disk only.
Well, that's true, the data have to be moved. But what happens in the tmp-
phase? The final blocks are composed from fragments dropping in in a
fuzzy sequence and not necessarily well ordered. Composing them piece by
piece on a hard disk takes - at least if my image of this composition process
is correct - a number of disk accesses. These are the most time consuming
when working with HDDs - I am not sure how a writing cache buffer will
handle such portioned write actions if the file is kept open by the OS.
So, the question is: is the composing part consuming more time and
ressources than the shift of the data from RAM to a physical, classical
HDD? (bypass thought: would the new SSDs be able to handle the job, or
are they not yet ready for the very high troughput?)

I just tested it empirically and undoumented, so don't beat me! :)
I first moved all EPS related handling of tmp-stuff to the RAMdisk. Worse
results than keeping all linked paths on the same partition (=physical drive).

Then vice versa, all EPS stuff back to disk, non EPS-tmp-stuff on the
RAMdisk. Much more quiecy, but still considerable missed packets counts.

Next, I tested EPS on its disk, non-EPS on drive D: missed-packet-wise, no
siginificant difference or improvement.

Comment-switching off EPS 5 and 11 reduced the traffic, of course, and
also the error rate. But again, I am miles away from your nearly zero error
rate.


As David pointed out, you have a high troughput on your DVB interface.
I had a longer discussion with David about what throughput means on
Windows and GNU/Linux. If my brain serves me right I think the bottom
line was that under Windows with a SkyStar and MRTG you see the
trougput that finally (maybe with some TelliCast decompression) will
reach your hard disks. With an USB box under Windows and MRTG
throughput seems to be as with GNU/Linux, see below.

If this is right so far, it means that you have licensed a real lot of
data with EUMETSAT and try to get them all. The recv-channels.ini you
posted is allmost like take all ("*").
Yes, and until a few days ago, I had no idea that I had any problems getting
them... :)

....

[ ... ]

So here is some points you can follow if not already done long ago:

1)
It seems that older TelliCast Clients really used "temp_directory"
which is now "tmp_directory".
Done yesterday.
So double check what it is for your
TelliCast Client I don't know the version of. Look under the TelliCast
WEB interface, Help, File Formats.
Will look again, from memory: 2.4.4 A - but I'll check.


2)
Try to direct everything to one HD (F:?) before using both (F: and
E:). Newer SATA drives use AHCI and the like ... As I understood it
worked on F: before without problems.
I've had the bifurcation for the data now for a couple of years.


3)
Are the tmp_directories really generated and used? Is there a slight
chance that your client has an access problem because it has not
sufficient rights somewhere? It seems you had a problem of that kind
with MRTG before?! Same when run as administrator?
All run with admin rights. The MRTG-problems came for a buggy version I
happened to get just after it had come out a few days ago. Corrected, no
more problems on that side.


4)
In recv.ini under [logging] set "log_level=normal" and restart with an
empty FSY (reboot). Then wait some minutes and look what the
"recv.log" file says ...
That's a point! :) Will do that next.


5)
Instead of using "tmp_directories" in "recv-channels.ini" at all you
could use an entry in "recv.ini"under "[parameters]"
"tmp_suffix=.tmp". This is from my GNU/Linux version, so please check
that this exists with the same syntax in your Windows Client (Again
check on your TelliCast WEB interface, Help, File Formats, ...).
But only if I collect everything on one disk - which is not given right now. I
am considering to replace the two disks with one large one, merging te
directories also into one. But not yet.

Happy testing.
Well, yes... Thanks! :)


P.S.
Your post of the recv.ini and recv-channels.ini showed "[recv.ini]"
"[recv-channels.ini]" as head and "[EOF]" as tail. You probably added
that to clarify the post, it should not be in these ini files
otherwise ...
Exactly. If I understand it right, you are a teacher. And obviously one with an
eagle's eye for small glitches... :)

I know, my wife is a teacher too...

Cheers,
U.

Re: not yet perfect, but...

Ulrich G. Kliegis
 

So double check what it is for your TelliCast

2.4.4.B (!)

Cheers,
U.

Re: not yet perfect, but...

Ulrich G. Kliegis
 

An: <MSG-1@...>
Von: "David J Taylor" <gm8arv@...>
Datum: Mon, 7 Mar 2011 12:14:44 -0000
Betreff: Re: [MSG-1] Re: not yet perfect, but...
Antwort an: MSG-1@...


Yes, I had been assuming that Ulrich had checked the log file for
obvious errors like; "No space in FSY database", but whether I asked
or not I now forget!
The log file is presently mirrored to this URL:
http://eumetmon.rummelecke.de/recv.log

Update every 10 minutes.

Cheers,
U.

Re: not yet perfect, but...

David J Taylor
 

So double check what it is for your TelliCast

2.4.4.B (!)

Cheers,
U.
That's fine - 2.4.4 B is slightly earlier than 2.4.4a (don't ask, must be Unix logic!), but both versions have the same core and either is fine.

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...