Ever since the database reorg, I have been getting either the permanent download error or missing header error. The ERR_XML_PARSE error would make the third type of database error we've seen.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

ERR_XML_PARSE

Is not a database error, but an parser error - part of the code that is being accessed is poorly formed and so the parser can't do its job. Looking back in the thread it would appear to be connected with download errors in a somewhat perverse way, so may be a transmission error that is corrupting the odd task.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

I don't like errors and not only do I still have 1 of them download errors left on my main rig, but now I have 3 of them "ERR_XML_PARSE" or "Bad Work Header" jobs on my backup rig. :-(

Cheers.

Been hit with a "Bad WU header" error myself.
:-/

---

Grant
Darwin NT

ERR_XML_PARSE

Is not a database error, but an parser error - part of the code that is being accessed is poorly formed and so the parser can't do its job. Looking back in the thread it would appear to be connected with download errors in a somewhat perverse way, so may be a transmission error that is corrupting the odd task.

The component most likely to be implicated is the splitter - that knows the recording parameters of the tape it's working on, and writes out first the parameters and processing instructions (in XML format), and then the actual data, into a combined workunit file. If I wasn't scheduled to be out at a meeting all day, I'd download one of the files and try to read the XML bit with my own eyes.

Edit - OK, here's my example for y'all to play with. http://boinc2.ssl.berkeley.edu/sah/download_fanout/d9/05my18aa.15528.2934.10.37.56

When you get time Richard, here are seven of them I got on one machine in a burst.

https://setiathome.berkeley.edu/workunit.php?wuid=2964747334
https://setiathome.berkeley.edu/workunit.php?wuid=2964747322
https://setiathome.berkeley.edu/workunit.php?wuid=2964747350
https://setiathome.berkeley.edu/workunit.php?wuid=2964747179
https://setiathome.berkeley.edu/workunit.php?wuid=2964747156
https://setiathome.berkeley.edu/workunit.php?wuid=2964747312
https://setiathome.berkeley.edu/workunit.php?wuid=2964747516

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Mine was WU 2964747029. It had a normal header, but only about 20 lines of data, and no XML to say that the end of the data had been reached - it should end

</data>
</workunit>

And as a consequence, it was a tiny file - 12 KB instead of 700-odd

A result of the pre-outage outage where the server status data stopped up dating, then several hours later there was no work other than resends?

---

Grant
Darwin NT

Could be. Maybe "created 7 May 2018, 23:58:30 UTC" is significant?

OK, I've got to get ready to go out. If anyone else wants to play, a reminder of WOW! Where on earth did that come from?

9/05/2018 17:07:06 | SETI@home | Project has no tasks available

With 180k Ready-to-send, i'm hoping that was just a one off glitch.

Edit-
Just a glitch, next couple of requests got work.
*fingers crossed*

---

Grant
Darwin NT

Remember, the buffer that actually sends you work is only about 400 WU long - when that runs out, it has to dip into the database for more WU's to send...

This is why you will get the dreaded "no work to send" on occasion, when the status page says there are plenty of WU's... (also check to see that the "status" page is up-to-date...)

---

.

Hello, from Albany, CA!...

. . It may just be me but my downloads are r.e.a.l slow.

Stephen

??

Remember, the buffer that actually sends you work is only about 400 WU long - when that runs out, it has to dip into the database for more WU's to send...

This is why you will get the dreaded "no work to send" on occasion, when the status page says there are plenty of WU's... (also check to see that the "status" page is up-to-date...)

That may be the case after an extended outage, but with the much shortened outages once there is work available i'm able to get some. So it shouldn't be the case at any other time.

---

Grant
Darwin NT

. . It may just be me but my downloads are r.e.a.l slow.

Might depend on the download server you got for that download. For the last few weeks my downloads have either been very fast, or just OK (other than when we had that system issue).


I notice the Ready-to-send buffer has settled around the 500k level. So either they've changed it, or the Splitters can't quite keep up their output to fill in that last 100k.

---

Grant
Darwin NT

Anyone else finding the web site slower than a month of Sundays for the last 10min or so? Threads load OK, but clicking on any link results in a very long wait for something to actually happen.

EDIT- and now it's OK again.
(should have posted about it sooner).

---

Grant
Darwin NT

Arecibo file appears to be stuck. Been 9 channels done, 5 in progress for several hours now.

---

Grant
Darwin NT

Sorry to all, I've had a major issue with comp/seti and have a lot of work that has been deemed abandoned, spent all day since early hours trying to figure out
what went wrong..Again sorry to all..

Sorry to all, I've had a major issue with comp/seti and have a lot of work that has been deemed abandoned, spent all day since early hours trying to figure out
what went wrong..Again sorry to all..

. . Abandoned is better than ghosted, they will be resent and with luck soon completed.

. . My attempts to run SoG r3584 have had several failures with eventual success, but I have ghosted a couple of hundred tasks along the way. It will take me most of the week to recover and complete them. Hopefully my wingmen will not be too put out by the delay.

Stephen

:(

In our discussions of app_info.xml, did we ever say "Set small cache levels when testing, until you're sure that it's working"?

In our discussions of app_info.xml, did we ever say "Set small cache levels when testing, until you're sure that it's working"?

. . Yep, and Bruce even advocated running the cache down to zero. But I am fatalistic and becoming quite adept at the ghost recovery procedure. I find practice helps me improve ... :)

. . I only have this machine online a few times a day unlike the Linux boxes, so I have to keep the cache large enough to keep it busy between online times. And that number of ghosts is from several failed attempts. Thankfully all the help I got resolved the problem before it went into 4 digits ...

. . At the end I would set NNT before reporting and then try the next rewrite of app_info. Otherwise the number would be bigger ...

. . It'll all be OK in the end.

Stephen

:)

Use local preferences to set 0.01 day.

Try new app_info.

If result 'Oh f...', edit and try again.

If result 'Yeah!', revert to normal settings, walk away, pour beer.

:)