Return-Path: X-Spam-DCC: paranoid 1290; Body=2 Fuz1=2 Fuz2=2 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on lipkowski.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DNS_FROM_AHBL_RHSBL, HTML_50_60,HTML_MESSAGE,RATWARE_GECKO_BUILD autolearn=no version=3.1.3 Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by paranoid.lipkowski.org (8.13.7/8.13.7) with ESMTP id u03Bg6vi031618 for ; Sun, 3 Jan 2016 12:42:06 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1aFgxl-0002cq-4t for rs_out_1@blacksheep.org; Sun, 03 Jan 2016 11:36:41 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1aFgxk-0002ch-Qn for rsgb_lf_group@blacksheep.org; Sun, 03 Jan 2016 11:36:40 +0000 Received: from smtpout.karoo.kcom.com ([212.50.160.34]) by relay1.thorcom.net with esmtp (Exim 4.86) (envelope-from ) id 1aFgwg-0003Ef-NL for rsgb_lf_group@blacksheep.org; Sun, 03 Jan 2016 11:36:39 +0000 X-IronPort-AV: E=Sophos;i="5.20,516,1444690800"; d="scan'208,217";a="144751860" Received: from unknown (HELO [127.0.0.1]) ([82.153.100.162]) by smtpout.karoo.kcom.com with ESMTP; 03 Jan 2016 11:35:18 +0000 Message-ID: <56890775.4060808@lineone.net> Date: Sun, 03 Jan 2016 11:35:17 +0000 From: LineOne User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: rsgb_lf_group@blacksheep.org References: In-Reply-To: X-Scan-Signature: b16f5c37bc0c21b41453c2ac5e65973c Subject: Re: AW: LF: Incomplete uploads on WSPR database Content-Type: multipart/alternative; boundary="------------090108020003040005040708" X-SA-Exim-Scanned: Yes Sender: owner-rsgb_lf_group@blacksheep.org Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group X-SA-Exim-Rcpt-To: rs_out_1@blacksheep.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Scanned-By: MIMEDefang 2.56 on 10.1.3.10 Status: O X-Status: X-Keywords: X-UID: 6080 This is a multi-part message in MIME format. --------------090108020003040005040708 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Looking at the "org" website it's passable in the mornings here but if you stay logged on it drops you eventually so I suppose decode reporting suffers much the same fate, congestion on the server(s). Often it takes a long time for decodes to appear. Hugh, M0DSZ On 02/01/2016 18:49, Vincent Stallbaum wrote: > Hi Stefan, > > it's the same behaviour here with me. > I suppose the problem belongs to the WSPR webserver: When the website > is slow or isn't available the uploads are incomplete. You should find > some connection error messages in the shell in this case. > > 74 Vinny > > Von meinem Samsung Gerät gesendet. > > > -------- Ursprüngliche Nachricht -------- > Von: DK7FC > Datum: 02.01.2016 18:23 (GMT+01:00) > An: rsgb_lf_group@blacksheep.org > Betreff: LF: Incomplete uploads on WSPR database > > Hi all, > > For a few times i see now that my local WSPR decodes are not > completely uploaded to the database. Furthermore it often takes very > long (> 15 seconds) until the WSPR map or database site is loaded. > > For example, this was uploaded from my 3 stations on 16:58 UTC: > > 2016-01-02 16:58 HB9ASB 0.475712 +3 0 JN36nu 100 > DK7FC/NE JN49ik 310 22 > 2016-01-02 16:58 DL2WB 0.475777 -15 0 JN39qh 0.2 > DK7FC/NW JN49ik 98 81 > > > However the actual decodes were: > > DK7FC/NW: > 1658 -6 5.7 0.475712 0 HB9ASB JN36 50 > > 1658 6 -1.0 0.475754 0 DH5RAE JN68 17 > > 1658 -15 -1.4 0.475777 0 DL2WB JN39 23 > > > DK7FC/NE: > 1658 3 6.0 0.475712 0 HB9ASB JN36 50 > > 1658 8 -0.6 0.475754 0 DH5RAE JN68 17 > > > DK7FC: > 1658 -7 6.4 0.475714 0 HB9ASB JN36 50 > > 1658 4 -0.2 0.475757 0 DH5RAE JN68 17 > > > So 2 decodes are displayed, 7 were made. What happened to the other 5? > I can see in other time slots that the WSPR instance did not hang up, > i.e. there are uploads for other decodes. But randamly some are lost > regularly. > > > Do some of you observe similar behaviour of the software? Is the > problem on my side or does the database somehow have problems during > the last months? > > > 73, Stefan > > > > --------------090108020003040005040708 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Looking at the "org" website it's passable in the mornings here but if you stay logged on it drops you eventually so I suppose decode reporting suffers much the same fate, congestion on the server(s). Often it takes a long time for decodes to appear.

Hugh, M0DSZ

On 02/01/2016 18:49, Vincent Stallbaum wrote:
Hi Stefan,

it's the same behaviour here with me. 
I suppose the problem belongs to the WSPR webserver: When the website is slow or isn't available the uploads are incomplete. You should find some connection error messages in the shell in this case.

74 Vinny

Von meinem Samsung Gerät gesendet.


-------- Ursprüngliche Nachricht --------
Von: DK7FC <selberdenken@posteo.de>
Datum: 02.01.2016 18:23 (GMT+01:00)
An: rsgb_lf_group@blacksheep.org
Betreff: LF: Incomplete uploads on WSPR database

Hi all,

For a few times i see now that my local WSPR decodes are not completely uploaded to the database. Furthermore it often takes very long (> 15 seconds) until the WSPR map or database site is loaded.

For example, this was uploaded from my 3 stations on 16:58 UTC:

2016-01-02 16:58   HB9ASB   0.475712   +3   0   JN36nu   100   DK7FC/NE   JN49ik   310   22 
 2016-01-02 16:58   DL2WB   0.475777   -15   0   JN39qh   0.2   DK7FC/NW   JN49ik   98   81 

However the actual decodes were:

DK7FC/NW:
1658 -6 5.7 0.475712 0 HB9ASB JN36 50

1658 6 -1.0 0.475754 0 DH5RAE JN68 17

1658 -15 -1.4 0.475777 0 DL2WB JN39 23


DK7FC/NE:
1658 3 6.0 0.475712 0 HB9ASB JN36 50

1658 8 -0.6 0.475754 0 DH5RAE JN68 17


DK7FC:
1658 -7 6.4 0.475714 0 HB9ASB JN36 50

1658 4 -0.2 0.475757 0 DH5RAE JN68 17


So 2 decodes are displayed, 7 were made. What happened to the other 5? I can see in other time slots that the WSPR instance did not hang up, i.e. there are uploads for other decodes. But randamly some are lost regularly.


Do some of you observe similar behaviour of the software? Is the problem on my side or does the database somehow have problems during the last months?


73, Stefan





--------------090108020003040005040708--