Date   

Re: Missed Packets minimized - Where are in-pe* data channeled??

Ulrich G. Kliegis
 

An: <MSG-1@yahoogroups.com>
Von: "David J Taylor" <gm8arv@yahoo.co.uk>
Datum: Wed, 29 May 2013 12:35:35 +0100
Betreff: Re: [MSG-1] Missed Packets minimized - Where are in-pe*
data channeled??
Antwort an: <MSG-1@yahoogroups.com>

As I thought INPE* files are from DevCoCast, so you could simply
comment out that channel in your recv-channels.ini if you aren't using it.
I believe some of the guys do find that data interesting, though.
David, thanks again. I don't blame anybody for collecting uninteresting data (except
the tax office...) ! :) But presently, I prefer to keep the option to switch them back on
when my curiosity wins..

Likewise, I'll skip the AutoClean option - too dangerous.

Cheers,
U.


Re: Missed Packets minimized - Where are in-pe* data channeled??

David J Taylor GM8ARV ๐Ÿด๓ ง๓ ข๓ ณ๓ ฃ๓ ด๓ ฟ ๐Ÿ‡ช๐Ÿ‡บ
 

David,
for example this:

INPE_GMC_201305290515.jpg

or

INPE_GMC_201305290515.jpg,

INPE_RFS_201305282130.tif.gz

etc.



And then also the JA* - data like

JA1_IPN_2PcP535_042_20130525_220001_20130525_220419.nc

JA2_OPN_2PdS180_179_20130528_223436_20130529_002949.nc.bz2

etc.





I presume you do have your
recv-channels.ini splitting different channels down into different directories?
Sure, from the very beginning!


The MSG Data Manager can handle DevCoCast data, or alternatively set
a non-zero value for the Auto-clean minutes (at least 90 minutes, I
would suggest), and the program will automatically remove unprocessed data
from your &#92;received&#92; directory tree.
There, I will probably select a much longer time to not loose data when the viewing
machine remains off for a day or two, or even for the night. Is there any ceiling
value for that parameter (in a reasonable range of course)?

Thanks and cheers,

U.
==============================================

Ulrich,

As I thought INPE* files are from DevCoCast, so you could simply comment out that channel in your recv-channels.ini if you aren't using it. I believe some of the guys do find that data interesting, though.

The maximum for Auto-clean is 32000 minutes (22 days if I have the maths correct!) but, needless to say, it's never been tested for that duration! Likely memory for the file list it maintains would run out first! It's not really suitable for intermittent running.

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk


Re: Missed Packets minimized - Where are in-pe* data channeled??

Ulrich G. Kliegis
 


Can you please confirm the full file name for those IN files? They
may be from [DEVCOCAST-1] data.
David,
for example this:

INPE_GMC_201305290515.jpg

or

INPE_GMC_201305290515.jpg,

INPE_RFS_201305282130.tif.gz

etc.



And then also the JA* - data like

JA1_IPN_2PcP535_042_20130525_220001_20130525_220419.nc

JA2_OPN_2PdS180_179_20130528_223436_20130529_002949.nc.bz2

etc.





I presume you do have your
recv-channels.ini splitting different channels down into different directories?
Sure, from the very beginning!


The MSG Data Manager can handle DevCoCast data, or alternatively set
a non-zero value for the Auto-clean minutes (at least 90 minutes, I
would suggest), and the program will automatically remove unprocessed data
from your &#92;received&#92; directory tree.
There, I will probably select a much longer time to not loose data when the viewing
machine remains off for a day or two, or even for the night. Is there any ceiling
value for that parameter (in a reasonable range of course)?

Thanks and cheers,

U.


Re: Missed Packets minimized - Where are in-pe* data channeled??

David J Taylor GM8ARV ๐Ÿด๓ ง๓ ข๓ ณ๓ ฃ๓ ด๓ ฟ ๐Ÿ‡ช๐Ÿ‡บ
 

After deleting some 16.000 ja1*, ja2* and in-* files from the received folder here last
night, the system seems to have found its breath back.

See <eumetmon.rummelecke.de> , missed packets rate.

The ja* - data seem to belong to the jason package, which I just unsubscribed -
due to lack of application or interest. Now, what package do the in-* files belong to?
I'd like to cut them at the source too. Is that the Indian Ocean data package from
Eumetsat (Meteosat 7?)? Should then normally be handled my MSG data manager,
shouldn' it?

Thanks in advance, and yes, of course, the rss animations are smooth again now!

Cheers,
U.
=======================================

Ulrich,

Great that you are now back to lossless!

Can you please confirm the full file name for those IN files? They may be from [DEVCOCAST-1] data. I presume you do have your recv-channels.ini splitting different channels down into different directories?

The MSG Data Manager can handle DevCoCast data, or alternatively set a non-zero value for the Auto-clean minutes (at least 90 minutes, I would suggest), and the program will automatically remove unprocessed data from your &#92;received&#92; directory tree.

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk


Missed Packets minimized - Where are in-pe* data channeled??

Ulrich G. Kliegis
 

After deleting some 16.000 ja1*, ja2* and in-* files from the received folder here last
night, the system seems to have found its breath back.

See <eumetmon.rummelecke.de> , missed packets rate.

The ja* - data seem to belong to the jason package, which I just unsubscribed -
due to lack of application or interest. Now, what package do the in-* files belong to?
I'd like to cut them at the source too. Is that the Indian Ocean data package from
Eumetsat (Meteosat 7?)? Should then normally be handled my MSG data manager,
shouldn' it?

Thanks in advance, and yes, of course, the rss animations are smooth again now!

Cheers,
U.


Re: The Earth - a disk! Or not?

David J Taylor GM8ARV ๐Ÿด๓ ง๓ ข๓ ณ๓ ฃ๓ ด๓ ฟ ๐Ÿ‡ช๐Ÿ‡บ
 

Good advice, you seem to know the program pretty well... :) I'll try that first.


Is it possible that your display size has changed?
Nope. Same machine, same drivers, no change.


With large numbers of files, the FAT and FAT32 systems can perform
poorly, and even NTFS can struggle. I would recommend that after an
extended outage the older data is purged, as you did. My software is,
generally, intended to work with real-time data, or gaps of not more than (say)
one day.
Well, even a few days are well handled mostly, but if you look at my statistics on
eumetmon.rummelecke.de, you'll see a correlation between an event happening
about every 100 minutes and the appearing of missed data peaks. Now, what can
that be? ;)

Admittedly, my hardware is not the latest and most powerful one, the ethernet
interface has no buffering, and the animations are also eating their share of CPU
time.

And due to the limitations of the PCI controllers, all SATA disks run on 150 Mbit/s
only, with the PCI bus itself not really acceletaring things... Sigh.

All disks are NTFS here.

Thanks and cheers,

U.
===================================

Ulrich,

100 minutes sounds like a polar orbit time. Perhaps you might consider (as I am) just taking Metop-B now that it is the prime satellite, and keeping Metop-A for standby use? There are changes planned in the Metop distribution from Svalbard and perhaps Antarctica (I don't recall without checking) which may make the data more timely, but may also increase the instantaneous bandwidth it needs.

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk


Re: The Earth - a disk! Or not?

David J Taylor GM8ARV ๐Ÿด๓ ง๓ ข๓ ณ๓ ฃ๓ ด๓ ฟ ๐Ÿ‡ช๐Ÿ‡บ
 

David,

just tried that - no avail.

Then I selected a totally new entry in the selection table and set up all data to
display the whole disk from the 1.6รฏยฟล“m data. After starting, the window remains
blank.
The image data are there, they look totally normal. As said, all other animations
work as advertised, just the "whole disk" variant won't.

Cheers,
U.
================================================

Ulrich,

It could be a memory allocation issue. I would suggest removing /all/ animations, and adding back just the full-disk one as the first animation.

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk


Re: The Earth - a disk! Or not?

Ulrich G. Kliegis
 

An: <MSG-1@yahoogroups.com>
Von: "David J Taylor" <gm8arv@yahoo.co.uk>
Datum: Thu, 23 May 2013 15:54:07 +0100
Betreff: Re: [MSG-1] The Earth - a disk! Or not?
Antwort an: <MSG-1@yahoogroups.com>

If you are
seeing odd issues, it may be worth closing down the MSG Animator,
and deleting the existing animation and any temporary bitmaps associated
with the animation, to force the program to rebuild the animation from
scratch.
David,

just tried that - no avail.

Then I selected a totally new entry in the selection table and set up all data to
display the whole disk from the 1.6ยตm data. After starting, the window remains
blank.
The image data are there, they look totally normal. As said, all other animations
work as advertised, just the "whole disk" variant won't.

Cheers,
U.


Re: The Earth - a disk! Or not?

Ulrich G. Kliegis
 

An: <MSG-1@yahoogroups.com>
Von: "David J Taylor" <gm8arv@yahoo.co.uk>
Datum: Thu, 23 May 2013 15:54:07 +0100
Betreff: Re: [MSG-1] The Earth - a disk! Or not?
Antwort an: <MSG-1@yahoogroups.com>

With the MSG Animator, it may reply on adding frames to an existing
animation rather than building the animation from scratch. If you
are seeing odd issues, it may be worth closing down the MSG Animator,
and deleting the existing animation and any temporary bitmaps associated
with the animation, to force the program to rebuild the animation from
scratch.
Good advice, you seem to know the program pretty well... :) I'll try that first.


Is it possible that your display size has changed?
Nope. Same machine, same drivers, no change.


With large numbers of files, the FAT and FAT32 systems can perform
poorly, and even NTFS can struggle. I would recommend that after an
extended outage the older data is purged, as you did. My software is,
generally, intended to work with real-time data, or gaps of not more than (say)
one day.
Well, even a few days are well handled mostly, but if you look at my statistics on
eumetmon.rummelecke.de, you'll see a correlation between an event happening
about every 100 minutes and the appearing of missed data peaks. Now, what can
that be? ;)

Admittedly, my hardware is not the latest and most powerful one, the ethernet
interface has no buffering, and the animations are also eating their share of CPU
time.

And due to the limitations of the PCI controllers, all SATA disks run on 150 Mbit/s
only, with the PCI bus itself not really acceletaring things... Sigh.

All disks are NTFS here.

Thanks and cheers,

U.


Re: The Earth - a disk! Or not?

David J Taylor GM8ARV ๐Ÿด๓ ง๓ ข๓ ณ๓ ฃ๓ ด๓ ฟ ๐Ÿ‡ช๐Ÿ‡บ
 

Hi all,
strange phenomenon here: After getting my boxes back on the track here
(SATA-controller failure in the receiver PC, RAM failure in the viewing machine),
almost everything works fine and smooth again - except: The animation of the
"whole disk" view. I did not change anything in the configuration, it works in the
same way it did before the double-failure. All other animations (subsections of the
various channel images) work flawlessly, only the whole disk views not. I've treid to
change them to partial views, to other channels - no avail.

I guess something's been broken in the registry part of the setup, although it
sounds unlikely.

Anyone with an idea?

Another observation: The receiver PC had continued to collect data for some
weeks before I switched it off. Some directories hat collected monstrous content:
Specially the EPS-Global contained about 12 GB in about 60.000 files - in one
directory. Then the very long file names - I can imagine that our good old XP
systems are suffering under that burden - and need their time to get it all sorted. I
finally purged most of it but the most recent data - when I finished that last night,
the missed data rate immediately fell down to zero.

The third observation concerns the AVHRR-manager - more on that in the
SatSignal group.

Cheers,
U.
========================================

Ulrich,

With the MSG Animator, it may reply on adding frames to an existing animation rather than building the animation from scratch. If you are seeing odd issues, it may be worth closing down the MSG Animator, and deleting the existing animation and any temporary bitmaps associated with the animation, to force the program to rebuild the animation from scratch. Is it possible that your display size has changed?

With large numbers of files, the FAT and FAT32 systems can perform poorly, and even NTFS can struggle. I would recommend that after an extended outage the older data is purged, as you did. My software is, generally, intended to work with real-time data, or gaps of not more than (say) one day.

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk


The Earth - a disk! Or not?

Ulrich G. Kliegis
 

Hi all,
strange phenomenon here: After getting my boxes back on the track here
(SATA-controller failure in the receiver PC, RAM failure in the viewing machine),
almost everything works fine and smooth again - except: The animation of the
"whole disk" view. I did not change anything in the configuration, it works in the
same way it did before the double-failure. All other animations (subsections of the
various channel images) work flawlessly, only the whole disk views not. I've treid to
change them to partial views, to other channels - no avail.

I guess something's been broken in the registry part of the setup, although it
sounds unlikely.

Anyone with an idea?

Another observation: The receiver PC had continued to collect data for some
weeks before I switched it off. Some directories hat collected monstrous content:
Specially the EPS-Global contained about 12 GB in about 60.000 files - in one
directory. Then the very long file names - I can imagine that our good old XP
systems are suffering under that burden - and need their time to get it all sorted. I
finally purged most of it but the most recent data - when I finished that last night,
the missed data rate immediately fell down to zero.

The third observation concerns the AVHRR-manager - more on that in the
SatSignal group.

Cheers,
U.


Re: Unusual tc error condition

James Brown
 

At one time, I was plagued by intermittent EKU errors when I changed to a new motherboard (sorry, but I can't remember the exact errors reported). The cure was to run the EKU on its own via an externally-powered USB hub.

I am using one of the early EKUs - just what combination of hardware needed the extra buffering provided by the hub I have no idea, but it might be worth a try if this becomes too troublesome.

Francis Breame

Thanks Frances - I have a newer EKU as of a few years ago, and haven't had this problem before in all the years of running the station. It is remotely possible the PSU is giving problems, or even the MB, but I would have expected to see more general errors. It happened overnight, and on a machine I go to very infrequently as it is dedicated to 24hr recption of EUMETCAST and a small weather station programme.
Cheers

James


Re: Unusual tc error condition

fbreame
 

--- In MSG-1@yahoogroups.com, James Brown <satellite@...> wrote:

On 15/05/2013 12:33, Ian Deans wrote:
Hello James.

I occasionally get a critical Dongle error probably averaging about twice a
year although I am not sure if it was a critical dongle "server" error.

I have no idea what causes the problem and usually it re-starts itself
without intervention, although data is lost until re-start.

Sorry I cannot be of more help.

Regards
Ian.

Many thanks Ian - it's helpful just to know I am not alone!
Unfortunately the process didn't start again, I lost about 5 hours. I
did wonder if the defrag programme had taken too much processor power,
though the CPU graphs don't seem to show that I am approaching maximum
usage.
James
At one time, I was plagued by intermittent EKU errors when I changed to a new motherboard (sorry, but I can't remember the exact errors reported). The cure was to run the EKU on its own via an externally-powered USB hub.

I am using one of the early EKUs - just what combination of hardware needed the extra buffering provided by the hub I have no idea, but it might be worth a try if this becomes too troublesome.

Francis Breame


Re: Permanent yellow T icon

Neil <neilthackrey@...>
 

Thanks to everyone for all the advice on how to get windows 7 64 bit working.
Just a quick review for any other budding windows 7 64 bit installers based on all the valued feedback I have received over the past few days;
1) make sure you install into a separate directory and NOT into the default installation folders
2) install the 64 bit etoken driver
3) run msconfig.exe then untick PKImonitor in start up to prevent the password window coming up each time you power up
4) make sure the IP address in your network settings for the DVB receiver is the same as the recv.ini file i.e. 192.168.238.238
5) if you have a LAN which maybe conflicting with your IP addresses run David's DOS prompt command line under administrator.
6) don't know why but allow five minutes to connect.. in XP pro it was almost straight away. I can live with though.
7) once connected and only getting the announcement channel go into windows firewall and tick all the tc-rcv boxes to allow bypassing the firewall.

Hope this summary is useful for others upgrading.

atb Neil ea7vpg/gm0vpg

--- In MSG-1@yahoogroups.com, "Ian Deans" <iandeans142@...> wrote:

Hello Neil,

I am not sure if you looked at the page on David Taylor's site which James
Brown mentioned in a mail to you. I have pasted it below again for
reference.

If you page down to the section "Using a LAN at the same time as the
DVB/TelliCast software" and follow the instructions you may find your
problem is resolved. It is important to note that once you have entered
the command and completed the procedure you need to reboot the computer.
Hope that helps.

http://www.satsignal.eu/wxsat/Dexatek/ip-address.html

Regards
Ian.

-----Original Message-----
From: Neil
Sent: Tuesday, May 14, 2013 6:13 AM
To: MSG-1@yahoogroups.com
Subject: [MSG-1] Permanent yellow T icon

Hi John....
Well putting everything into a separate directory certainly worked. The
red icon has now gone... unfortunately it is sitting in a state of yellow
trying to connect permanently. I have checked my recv.ini and compared it
to others which look identical. I have edited my recv-channels.ini to
reflect the new computer configuration. If the recv-channels.ini file is
incorrect would it prevent connecting.


from the log file in the html shell
MSG:2013-05-14 04:43:52.951:Starting new child...
MSG:2013-05-14 04:43:52.951:Started new child [4484].
MSG:2013-05-14 04:43:52.951:Starting new child...
MSG:2013-05-14 04:43:52.951:Started new child [4484].

atb Neil


Re: Unusual tc error condition

James Brown
 

On 15/05/2013 12:33, Ian Deans wrote:
Hello James.

I occasionally get a critical Dongle error probably averaging about twice a
year although I am not sure if it was a critical dongle "server" error.

I have no idea what causes the problem and usually it re-starts itself
without intervention, although data is lost until re-start.

Sorry I cannot be of more help.

Regards
Ian.

Many thanks Ian - it's helpful just to know I am not alone! Unfortunately the process didn't start again, I lost about 5 hours. I did wonder if the defrag programme had taken too much processor power, though the CPU graphs don't seem to show that I am approaching maximum usage.

Many thanks

James


Re: Unusual tc error condition

Ian Deans
 

Hello James.

I occasionally get a critical Dongle error probably averaging about twice a year although I am not sure if it was a critical dongle "server" error.

I have no idea what causes the problem and usually it re-starts itself without intervention, although data is lost until re-start.

Sorry I cannot be of more help.

Regards
Ian.

-----Original Message-----
From: James Brown
Sent: Wednesday, May 15, 2013 11:24 AM
To: MSG-1@yahoogroups.com
Subject: [MSG-1] Unusual tc error condition

Folks, I haven't seen this before, wonder if anyone else has encountered
this - the client log runs like this:

MSG:2013-05-15 09:49:06.637:tc-recv.exe shutting down... [4000]
MSG:2013-05-15 09:49:06.740:tc-recv.exe stopped [4000].
MSG:2013-05-15 09:49:06.980:Watchdog child requested restart.
MSG:2013-05-15 09:49:06.984:Watchdog child quits properly. Restarting.
MSG:2013-05-15 09:49:07.985:Starting new child...
MSG:2013-05-15 09:49:07.985:Started new child [352].
MSG:2013-05-15 09:49:08.198:Log level is "normal".
MSG:2013-05-15 09:49:55.824:tc-recv.exe starting... [352]
MSG:2013-05-15 09:49:55.824:tc-recv.exe version is 2.5.17
(200906051529668) win32-i86pc ( 6.1.7601, Service Pack 1 on a
4-processor (GenuineIntel, Pentium III (Model 30, Stepping 5)) system)
ERR:2013-05-15 09:49:55.824:The eToken manager timed out after start.
ERR:2013-05-15 09:49:55.824:Critical dongle server error (EToken server
timed out). Trying to restart child.
MSG:2013-05-15 09:49:55.824:tc-recv.exe shutting down... [352]
MSG:2013-05-15 09:49:55.945:tc-recv.exe stopped [352].
MSG:2013-05-15 09:49:56.217:Watchdog child requested restart.
MSG:2013-05-15 09:49:56.221:Watchdog child quits properly. Restarting.
MSG:2013-05-15 09:49:57.221:Starting new child...
MSG:2013-05-15 09:49:57.221:Started new child [3884].
MSG:2013-05-15 09:49:57.438:Log level is "normal".
MSG:2013-05-15 09:50:45.107:tc-recv.exe starting... [3884]
MSG:2013-05-15 09:50:45.107:tc-recv.exe version is 2.5.17
(200906051529668) win32-i86pc ( 6.1.7601, Service Pack 1 on a
4-processor (GenuineIntel, Pentium III (Model 30, Stepping 5)) system)
ERR:2013-05-15 09:50:45.107:The eToken manager timed out after start.
ERR:2013-05-15 09:50:45.107:Critical dongle server error (EToken server
timed out). Trying to restart child.
MSG:2013-05-15 09:50:45.107:tc-recv.exe shutting down... [3884]
MSG:2013-05-15 09:50:45.240:tc-recv.exe stopped [3884].

And thereafter remains in this loop. I stopped the tc processes and
re-started them and for now all seems to have returned except RSS.

Any thoughts folks?

Cheers
Jamess


Unusual tc error condition

James Brown
 

Folks, I haven't seen this before, wonder if anyone else has encountered this - the client log runs like this:

MSG:2013-05-15 09:49:06.637:tc-recv.exe shutting down... [4000]
MSG:2013-05-15 09:49:06.740:tc-recv.exe stopped [4000].
MSG:2013-05-15 09:49:06.980:Watchdog child requested restart.
MSG:2013-05-15 09:49:06.984:Watchdog child quits properly. Restarting.
MSG:2013-05-15 09:49:07.985:Starting new child...
MSG:2013-05-15 09:49:07.985:Started new child [352].
MSG:2013-05-15 09:49:08.198:Log level is "normal".
MSG:2013-05-15 09:49:55.824:tc-recv.exe starting... [352]
MSG:2013-05-15 09:49:55.824:tc-recv.exe version is 2.5.17 (200906051529668) win32-i86pc ( 6.1.7601, Service Pack 1 on a 4-processor (GenuineIntel, Pentium III (Model 30, Stepping 5)) system)
ERR:2013-05-15 09:49:55.824:The eToken manager timed out after start.
ERR:2013-05-15 09:49:55.824:Critical dongle server error (EToken server timed out). Trying to restart child.
MSG:2013-05-15 09:49:55.824:tc-recv.exe shutting down... [352]
MSG:2013-05-15 09:49:55.945:tc-recv.exe stopped [352].
MSG:2013-05-15 09:49:56.217:Watchdog child requested restart.
MSG:2013-05-15 09:49:56.221:Watchdog child quits properly. Restarting.
MSG:2013-05-15 09:49:57.221:Starting new child...
MSG:2013-05-15 09:49:57.221:Started new child [3884].
MSG:2013-05-15 09:49:57.438:Log level is "normal".
MSG:2013-05-15 09:50:45.107:tc-recv.exe starting... [3884]
MSG:2013-05-15 09:50:45.107:tc-recv.exe version is 2.5.17 (200906051529668) win32-i86pc ( 6.1.7601, Service Pack 1 on a 4-processor (GenuineIntel, Pentium III (Model 30, Stepping 5)) system)
ERR:2013-05-15 09:50:45.107:The eToken manager timed out after start.
ERR:2013-05-15 09:50:45.107:Critical dongle server error (EToken server timed out). Trying to restart child.
MSG:2013-05-15 09:50:45.107:tc-recv.exe shutting down... [3884]
MSG:2013-05-15 09:50:45.240:tc-recv.exe stopped [3884].

And thereafter remains in this loop. I stopped the tc processes and re-started them and for now all seems to have returned except RSS.

Any thoughts folks?

Cheers
Jamess


Re: Permanent yellow T icon

Ian Deans
 

Hello Neil,

I am not sure if you looked at the page on David Taylor's site which James Brown mentioned in a mail to you. I have pasted it below again for reference.

If you page down to the section "Using a LAN at the same time as the DVB/TelliCast software" and follow the instructions you may find your problem is resolved. It is important to note that once you have entered the command and completed the procedure you need to reboot the computer.
Hope that helps.

http://www.satsignal.eu/wxsat/Dexatek/ip-address.html

Regards
Ian.

-----Original Message-----
From: Neil
Sent: Tuesday, May 14, 2013 6:13 AM
To: MSG-1@yahoogroups.com
Subject: [MSG-1] Permanent yellow T icon

Hi John....
Well putting everything into a separate directory certainly worked. The red icon has now gone... unfortunately it is sitting in a state of yellow trying to connect permanently. I have checked my recv.ini and compared it to others which look identical. I have edited my recv-channels.ini to reflect the new computer configuration. If the recv-channels.ini file is incorrect would it prevent connecting.


from the log file in the html shell
MSG:2013-05-14 04:43:52.951:Starting new child...
MSG:2013-05-14 04:43:52.951:Started new child [4484].
MSG:2013-05-14 04:43:52.951:Starting new child...
MSG:2013-05-14 04:43:52.951:Started new child [4484].

atb Neil


Permanent yellow T icon

Neil <neilthackrey@...>
 

Hi John....
Well putting everything into a separate directory certainly worked. The red icon has now gone... unfortunately it is sitting in a state of yellow trying to connect permanently. I have checked my recv.ini and compared it to others which look identical. I have edited my recv-channels.ini to reflect the new computer configuration. If the recv-channels.ini file is incorrect would it prevent connecting.


from the log file in the html shell
MSG:2013-05-14 04:43:52.951:Starting new child...
MSG:2013-05-14 04:43:52.951:Started new child [4484].
MSG:2013-05-14 04:43:52.951:Starting new child...
MSG:2013-05-14 04:43:52.951:Started new child [4484].

atb Neil

--- In MSG-1@yahoogroups.com, "Neil" <neilthackrey@...> wrote:

Cheers John.... I will give it a go.

atb Neil

--- In MSG-1@yahoogroups.com, "seggins@..." <seggins@> wrote:

Install all in a separate folder eg Eumesat, preferably on its own partition. Not in either program files.
Cheers
John

Sent from my HTC

----- Reply message -----
From: "Neil" <neilthackrey@>
To: <MSG-1@yahoogroups.com>
Subject: [MSG-1] Re: EKU no being recognised and the red T icon
Date: Mon, May 13, 2013 09:18
Thanks to all for your constructive replies. Yes, I agree I wish I had stayed with XP pro now. This issue is driving me nuts.

The password issue was resolved via msconfig, startup. The problem now is the T icon in task is permanent red indicating tc-recv Connect failed. I have checked in the html shell under licence which shows the following;

Client identification appears all correct with user and a host 1 to 4 all showing some parameters. The Active Clients shows the TSL announcement channel with a status of error. Under licence, not sure about this one;

Tellicast server licence, server address not yet received, OEM and description the same.

The tick boxes under what I can get and what is activated are Tellicast, File Broadcast, Datastreams.



The only anomaly I can see is the actual Client licence with Version 2.4.4q 200610301329200 win32-i86pc. Being a 64bit OS here could this be a problem?



In the top left of the HTML it indicates config problem. Now here is the weird one. When I copy my recv.ini file into the program I lose the red T in the task bar all together even though it is identical to the one generated when you load the Tellicast client software. The only way I can get the red T back is to re-install the Tellicast.

And yet another weirdy is I cannot edit the original rcv.ini file as when I come to save I get a window saying Access denied. The only way I can do is to replace the file with my original which I can edit in notepad.

When I installed the three applications (DVB, Etoken, Tellicast) some went into programs files whilst one defaulted into programs files (x86). I then uninstalled the lot and re-installed everything into program files which made no difference.



So all in all it is becoming annoyingly frustrating.



If there any windows 7 64 bit users out there it would be appreciated if you could send me a sample of your recv.ini and recv.channels.ini file to compare. I suppose ultimately I will have to send this to the eumetcast support desk.



I look forward to your comments.



atb Neil



--- In MSG-1@yahoogroups.com, Alan Sewards <alan@> wrote:

Hello James,
Thank you for your comment. From the subsequent postings my effort
appears to be rather inadequate: perhaps I should have said it was for
Windows XP. Clearly Win 7 introduces a new lot of problems, not the
least being poor availability of suitable software (3 years after it
appeared!). Many people find the installation process too arcane or
complicated - it is a pity that Eumetsat did not pull all the items
together with a single Installer that leads users through the
installation process, preferably all on one CDROM. Sometimes, I think it
is miraculous that it works at all! I'm glad I stayed with XP on my
Eumetcast machine.
Best regards - Alan S
On 12/05/2013 5:10 PM, James Brown wrote:
That would be useful as a 'sticky' somewhere Alan - I have archived it
for future reference.
Cheers
On 12/05/2013 13:47, Alan Sewards wrote:
Hi Neil,
I have a feeling that you have used the wrong order in installing the
software. Some notes I have on this are as follows
------------------------------------
Unsure what a term means? Check the Glossary at:
http://www..satsignal.eu/wxsat/glossary.htm
Join GEO - the Group for Earth Observation
for the informative GEO Quarterly magazine:
http://www.geo-web.org.uk/
Yahoo! Groups Links
--
Alan Sewards
รƒยฉmail: alan@
web site: http://asewards.free.fr










[Non-text portions of this message have been removed]


Re: EKU no being recognised and the red T icon

James Brown
 

Would this page be of help Neil?

http://www.satsignal.eu/wxsat/Dexatek/ip-address.html

Cheers
James

On 13/05/2013 20:21, Neil wrote:
Hi Ian,
I have changed the IP address.. what subnet mask, default gateway, preferred DNS and alternative DNS server should I use ?

atb Neil

--- In MSG-1@yahoogroups.com, James Brown <satellite@...> wrote:
On 13/05/2013 09:31, Ian Deans wrote:
If you have a permanent red "T" then either your interface address is wrong
or your firewall is causing a problem.

Your IPv4 address in your network connection should be fixed and not
automatic and should of course be the same as that showing in your recv.ini
( usually 192.168.238.238 ). If that is all correct then your firewall must
be the problem.

Hope that helps.
Ian.

I imagine that will probably be the trouble - although when I was
changing to a Windows 7 machine I also installed the wrong software for
the EKU and ended up with a dead EKU which needed replacing. I then
needed one extra tweak to set the route.

All the best

james


------------------------------------

Unsure what a term means? Check the Glossary at:
http://www.satsignal.eu/wxsat/glossary.htm

Join GEO - the Group for Earth Observation
for the informative GEO Quarterly magazine:
http://www.geo-web.org.uk/

Yahoo! Groups Links



14981 - 15000 of 31500