Return-Path: X-Spam-DCC: paranoid 1290; Body=3 Fuz1=3 Fuz2=3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on lipkowski.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_AHBL_RHSBL 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 u041dE4C000531 for ; Mon, 4 Jan 2016 02:39:14 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1aFu0x-0004KP-RD for rs_out_1@blacksheep.org; Mon, 04 Jan 2016 01:32:51 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1aFu0x-0004KG-6n for rsgb_lf_group@blacksheep.org; Mon, 04 Jan 2016 01:32:51 +0000 Received: from vms173019pub.verizon.net ([206.46.173.19]) by relay1.thorcom.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aFtzs-0004VP-Sv for rsgb_lf_group@blacksheep.org; Mon, 04 Jan 2016 01:32:50 +0000 Received: from MichaelSappPC ([74.111.108.64]) by vms173019.mailsrvcs.net (Oracle Communications Messaging Server 7.0.5.32.0 64bit (built Jul 16 2014)) with ESMTPA id <0O0E005AJMVZUR60@vms173019.mailsrvcs.net> for rsgb_lf_group@blacksheep.org; Sun, 03 Jan 2016 19:31:12 -0600 (CST) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=MtGvkDue c=1 sm=1 tr=0 a=o0zNHtPt358xAo2xR2HKuQ==:117 a=o1OHuDzbAAAA:8 a=oR5dmqMzAAAA:8 a=N659UExz7-8A:10 a=7aQ_Q-yQQ-AA:10 a=VVlED5B4AAAA:8 a=F3M5lZpKAAAA:8 a=pmXx-AoGAAAA:8 a=4222HEczyj-kDiEG2cQA:9 a=pILNOxqGKmIA:10 Message-id: <16BB43E0F7E4409A8635FC75DFF064AA@MichaelSappPC> From: "Michael Sapp" To: References: <579355A36AEE9D4FA555C45D556003AB25317862@servigilant.vigilant.local> <5255CDA8464845A3B8937A641180CFA4@White> <2965301451575717@web29m.yandex.ru> <579355A36AEE9D4FA555C45D556003AB25318D11@servigilant.vigilant.local> <5688037E.6050803@posteo.de> <56880784.8090105@posteo.de> <56892CF0.6080102@posteo.de> <04E680673AD94D1F82ED0C52D9A5A9D6@MichaelSappPC> <56897DFF.1060601@gmx.net> In-reply-to: <56897DFF.1060601@gmx.net> Date: Sun, 03 Jan 2016 20:31:07 -0500 MIME-version: 1.0 X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 X-Scan-Signature: 982d53dbb4bb82e9ed4f38562b2a1556 Subject: Re: LF: Re: Incomplete uploads on WSPR database Content-type: text/plain; format=flowed; charset=Windows-1252; reply-type=response Content-transfer-encoding: 7bit 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: 6090 Tobias: I'm not sure why it made a difference, but I do not seem to have upload issues with wspr-x since making the change. 73, Mike wa3tts ----- Original Message ----- From: "Tobias DG3LV" To: Sent: Sunday, January 03, 2016 3:01 PM Subject: Re: LF: Re: Incomplete uploads on WSPR database > Hi Mike ! > > This file is never uploaded (to the WSPR servers), so for what reason we > should keep it small? > > HNY & 73 de dg3lv Tobias > > Am 03.01.2016 um 17:58 schrieb Michael Sapp: >> Stefan & All: If you use wsprx, try limiting the size of your ALL_WSPR >> txt file. W1VD pointed this out as the file contains a record of all of >> your captures. Rename the file as ALL_WSPR_OLD and then edit the >> ALL_WSPR file to a few weeks of data. My ALL_WSPR file had grown to >> 6.5MB which is a sizeable upload. I try to keep my ALL_WSPR file to >> under 250KB. >> 73 Mike wa3tts >> >> ----- Original Message ----- >> *From:* DK7FC >> *To:* rsgb_lf_group@blacksheep.org >> >> *Sent:* Sunday, January 03, 2016 9:15 AM >> *Subject:* Re: LF: Re: Incomplete uploads on WSPR database >> >> R Chris, thanks for the feedback. >> >> Well that problem does exist just since a few months. Good to know >> that it is not local. >> Maybe it's due to the permanantly rising usage of the software / >> increasing number of uploaded spots and requested website update? >> See the plot "stations participating per day" at >> http://wsprnet.org/drupal/wsprnet/stats >> Maybe they need a new faster server hardware... >> >> 73, Stefan >> >> Am 03.01.2016 12:55, schrieb Chris: >>> I frequently get the same problem Stefan. The program eventually >>> gives up trying to send the spots to the website and you get a >>> 'timed out' message in the shell. Just before Christmas it was >>> loading up less than half the spots I was getting, so turned it >>> off, couldn't see the point if the reports weren't being sent!! >>> Vy 73 es HNY to All, >>> Chris, G4AYT. >>> >>> ----- Original Message ----- >>> *From:* DK7FC >>> *To:* rsgb_lf_group@blacksheep.org >>> >>> *Sent:* Saturday, January 02, 2016 5:23 PM >>> *Subject:* 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 >>> >>> >>> >>> >