@khayoz

I've upped the idle session length to 1 hour so we'll see if that helps.

It's been fixed now.

@ddni

On OS4depot, go to the file readme page and click the "View crashlogs" button followed by a click on the [Submit Crashlog] link.

@Hans

There used to be a sub site on OS4Depot for keeping track of sobjs. Unfortunately it didn't get traction and was severely underused so I decided to remove it.

It's still visible here:

http://sobjs.os4depot.net/

It works. It just took some time for the uploader to find/read/react to it.

@kas1e

The images are provided by youtube. No processing is done locally on the os4depot server.

However it seems they (youtube) do not provide a sddefault.jpg for all videos. I have changed it to use the default.jpg image by .. default.

These files are waiting for the submitter to reply to an email.

Then call it supertuxcart_minigl and supertuxcart_ogles2.

Easiest way is if you upload the old file to replace the current one and the new file not using a version in its name but rather a description of what makes it different like the two above examples.

OS4Depot does not allow version names in the file names, nor several versions of the same file.

@BillE

"What I meant is that without the snowflakes the menu and title bar always stay at the top of the display, whereas with the flakes they scroll out of view so you have to scroll back to the top to click the Home button."

Yes that's how it's intended to work. They are mutually exclusive at the moment. (Incidently it was exactly like that last christmas season as well, but no one noticed/mentioned it ;)

It's nice that someone has noticed the scrolling feature (and misses it!) that I added a while back :)

I wasn't able to quickly combine both the flakes and the scrolling feature with the time I had (and have).

At worst you'll have to live without the scrolling feature for a few weeks until the season is over.

I've added both a plain text part and a html part to the outgoing email.

I've also added a more useful error message if you happen to use the incorrectly formatted URL.

The following files were removed from the upload queue due to incorrect (obfuscated) email addresses:

easytag.lha
easytag-src.lha

Bumping as a reminder.

@nbache

I'm looking at making it a multipart email. With a section for "text/html" and one for "text/plain".

With the help of glames I have identified why some files get stuck waiting for email verification.

It seems that certain email clients aren't decoding HTML properly, specifically the html tag for ampersand in the verification URL.

When using the link from an email client that doesn't decode it properly the server doesn't get all data it needs to verify the email address.

I've temporarily added a log that stores all verification attempts. This will let me verify these emails manually for now.



When the email doesn't get verified the file is removed from the upload queue after a while. So if this has previously happened to you it shouldn't happen any more.

This file is stuck in the upload queue due to not receiving any reply to the email verification mail that was sent out by the server.



(Since files getting stuck in the upload queue is too common for comfort I'll start posting this kind of information here)

We're looking at moving Amigans.net over to SSL.

Just as a heads up:

At the weekend on the 30'th of November and 1'st of December we're going to do some experimentation on the main site to prepare for a move over which might lead to some weird or unexpected behaviour.

May not be relevant at all, but anyway:

https://wiki.raptorcs.com/wiki/Porting/Chromium_(New)
https://wiki.raptorcs.com/wiki/Porting/Chromium/BE

Turned off "KeepAlive" in apache to see what happens.

Getting the headers locally on the server does not include the "KeepAlive" parameter as expected.

However from a remote client it is included.

Reading up a bit on it, without claiming to be an expert om it, and it seems that any router between the client and server can handle this on their own. That is, even if the server does not handle KeepAlive the router that your client is speaking to can have its own rules for keeping connections to it reusable.

So in this case it might just be a router between you and the server that handles the connections you make to it. You get the headers as rewritten by the router and not those sent from the server to the first router in the router chain.

@Thematic

Seems weird. The server is configured with:

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 60

And this is the header I get from wget:

HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Wed, 11 Sep 2019 05:33:57 GMT
Server: Apache/2.4.18 (Ubuntu)
Pragma: public
Expires: 0
Cache-Control: public
Content-Disposition: attachment; filename="amiarcadia.lha"
Content-Description: File Transfer
Content-Transfer-Encoding: binary
Accept-Ranges: bytes
Content-Length: 5000476
Content-Type: application/lha
Connection: Keep-Alive
Length: 5000476 (4,8M) [application/lha]

From:

wget --server-response --spider http://os4depot.net/share/emulation/gamesystem/amiarcadia.lha


What parameters are you using for wget?