Welcome to Inkbunny...
Allowed ratings
To view member-only content, create an account. ( Hide )
Inkbunny

Help needed! Upload issues.

Hi everyone,

Many people have reported upload issues when sending files over about 3MB to Inkbunny.

This problem has gone on for quite a while and we still have no idea what is causing it.

It does not effect everyone, which is the biggest mystery. This leads us to believe it is a network hardware issue or some really obscure network setting issue. It is definitely not an Inkbunny code issue, as you will see from our testing pages.

I have never seen the upload error ever, and I have uploaded 200MB+ files to Inkbunny many times. Yet other people see it all the time without fail, any time they try to upload over 3MB.

I have created two test pages to make upload testing easy.

The Test Pages

The pages are:

https://inkbunny.net/simpletest.php - A very basic HTML form that just uploads the file. Only Apache is involved. No Inkbunny site code is used.

https://inkbunny.net/progresstest.php - Includes Inkbunny site headers, and AJAX progress meter using the APC PHP plugin. Requires a valid login.

If you use either page, it will upload the test file but then do nothing with it, so feel free to try them as much as you like. They won't affect your account.

To help us out

1. Please reply to this journal stating whether you got any errors or odd progress meter behavior while testing both upload pages. Also tell us if it worked just fine for you!

2. Please tell us your location if you can (just a country or city is fine).

3. For advanced users: Please try traceroute and ping, and tell us if there is any unusual delays or packet loss.

4. For really advanced users: Please use Wireshark or something similar and see if you can figure out what might have reset the connection, or if there is any more useful information at the packet level.

5. If anyone has any suggestions as to how to debug this issue or settings we can try in Apache 2 that might fix it, we'd love to hear from you! Is this a problem anyone has seen before on other sites? How did they fix it? Please discuss it here!

Thanks very much!

Starling
Viewed: 289 times
Added: 7 years, 10 months ago
Site News Item: yes
 
dracorey
7 years, 10 months ago
Uploaded from android smartphone, no problem (its a samsung captivate)
PeanutButterEvil
7 years, 10 months ago
I know with PHP there are some memory configurations that can be changed, might it be a php error due to running out of memory for that specific task?
starling
7 years, 10 months ago
Hi!

It's a good suggestion. But this error is occurring before PHP even gets to execute, as it happens during the data transmission phase. And it happens only to selected people! PHP memory settings should effect everyone. Hmmmmm. :o
ottering
7 years, 10 months ago
What is driving the upload process itself?
starling
7 years, 10 months ago
If you use the Simpleform, it is just your browser and Apache 2. Nothing else!
ottering
7 years, 10 months ago
From the source, it appears that the form's data is being handed over to PHP.  Trying to hit the file spits out a completion string, so I'm assuming this is what's driving the upload process (handling whatever actually initiates the transfer).

Since IB already calculates an MD5 hash for uploads, would it be a wise idea to have the client use a "local" script to perform a hash before the upload and report this as part of the form data?  These could be compared and logged (with other client parameters) to see what might be causing it.
starling
7 years, 10 months ago
It never gets to execute the destination PHP script sadly. The errors occur during the upload process which means it's actually before Apache even tries to run the destination script. It's still waiting to get all the submitted data from the browser first. PHP may be involved in saving the file to disk as a temporary file, but the script isn't run at that point.
ottering
7 years, 10 months ago
I'm thinking it might be packet problems, then.  PHP would make sense if it was handling the recording of the file, but since it gets the data AFTER the upload, then it's probably not that.

From what I saw with my last upload, packets (or something similar) may just be the cause.  I'm going to assume that what I saw is "typical" of the error in that only sections of the upload are damaged, and not an outright failure/corruption.  The dropping of a packet might explain why a chunk of text suddenly disappeared or why another section came out as gibberish... and would be visible in an image as gray regions similar to horizontal bars in a best-case scenario...

Is the upload to the server (Client -> Apache) TCP or UDP?  The latter might explain anonymous loss of packets, since there's no handshake between transmissions.
starling
7 years, 9 months ago
Our host changed the routing and it magically seems to work now! Wheeee! Official announcement soon.
mirage
7 years, 10 months ago
PHP has a variable for max file upload size. Have you guys checked that?

If memory serves correctly, its the upload_max_filesize and post_max_size variables in your php.ini file.
starling
7 years, 10 months ago
We allow up to 300MB max size, and I can upload a file that big right now with no probs! If affects only selected people during the upload phase, before PHP even executes. So it's probably not a PHP setting issue.
ottering
7 years, 10 months ago
Just uploaded a .doc file recently and found some of the characters stripped or in the wrong encoding (came out as unrecognized garbage).

I think it might actually be something with the server/host process for the upload, since the damage was actually variable in length (first instance was about 10 words, the second 30).  It's possible that something is happening concurrently that's causing the file data to mutate or get damaged ... my best estimate is that it's not network based (and is likely either server-side or protocol-based... perhaps dropped packets for the latter?)

Sadly, I don't know enough about (both) Apache implementations or the PHP back-end (namely how code is dispatched) to give you guys any valuable tidbits of thought outside of observations.

Hope you guys can resolve it!
ChipmunkClunk
7 years, 10 months ago
the first one didn't seem to be uploading. stopped after a few minutes.

the second one with the progress meter revealed that it was uploading incredibly slowly. not too slowly for the usual picture perhaps, but certainly too slowly for me to wait for a 43 megabyte file. i'd say, roughly .04 mb/s.
Buck
7 years, 10 months ago
Tried on two different browsers with two different types of files. In SeaMonkey, the files started to upload, but it went very slowly. In Safari, the files never got past the "Initializing" stage.

I could try Chrome, too, but I'd have to log out and in again, so maybe later because I'm terribly lazy x3
Krechevskoy
7 years, 10 months ago
Uploads fine here from windows 7 and linux, as well as my iphone.

Tested with firefox, safari, opera, and even IE.  I couldn't replicate the issue.

Uploaded from Norman, Oklahoma.  Tested on my personal WiFi and 3G.

No clue as to what could be causing it... any chance you could post some demographic info about the ones having the issue?
fluffdance
7 years, 10 months ago
My first instinct is to look at the ISPs of the users having this issue.  A lot of dialup services still impose download/upload limits specific to individual file size, rather than daily usage, etc.  Satellite providers, and non-North American providers should also be taken into account.  If it's the same people every time, that would point towards a user-end/user-ISP-end error, rather than an internal networking error on InkBunny's side of things.  Just to be sure, though, double-check InkBunny's ISP's peering and make sure there aren't any conflict-of-interest issues going on.  Spending time in a private datacenter at One Wilshire in LA, I can tell you that often times, competing backbone providers -will- occasionally force DNS and packetloss problems upon their supposed peers.
xpanther
7 years, 10 months ago
hmmm i agree with this. since it seems to be a selective problem, i would want to see both the region and the ISP info before i asuming inkbunny or apache code issues.
Rhumba
7 years, 10 months ago
Both seem to have uploaded fine for me. In Chrome 8 the fanciful never had a progress bar rendered, it just said "Initializing..." until the upload was complete. It did appear in the latest Firefox 4 nightly so it could just be a browser specific issue on that.
Meko
7 years, 10 months ago
The upload worked perfectly fine for me. I thought it might have been an AJAX problem reading it over the first time but considering you've provided a basic HTML form and the issue still occurs that rules that out.

One thing I would recommend and I'm sure you know already is that you should disable the upload button once an upload has started. In terms of what the issue could be I'm pretty sure the people above have given plenty incite. I don't think anyone on the outside could honestly deduce the problem without seeing the source code and picking it apart.

Specs:
- Windows 7
- Firefox 3.6.12
- AT&T 256k DSL
- Michigan, USA
Avilayoq
7 years, 10 months ago
A successful upload from each test page.

Specs:
Windows XP
Firefox 3.6.12
San Diego, USA
Shakeidas
7 years, 10 months ago
Tried it on the complex page a couple times.  First attempt with a 36 MB file eventually got me to a "connection reset" page in Firefox.  Tried again with a 30 MB file and the meter keeps resetting itself to 0 after a random amount is uploaded (made it up to ~19 MB at one point), usually below 3 MB though. O.o

Living in Hawaii, with Time Warner's Road Runner service for an ISP.  Latest version of Firefox on Windows 7 x64, etc.
Shakeidas
7 years, 10 months ago
Oh, and the second attempt (yes, I've left it running this whole time) just turned into another "connection reset" page.
FakerFace
7 years, 10 months ago
Sorry if this isnt any help, but I just tried uploading a .zip bulk file of 3.99 MB to my gallery (not with the test page), and as soon as it uploaded to 3.99 MB, it gave me a "Server took too long to respond" error and it didn't go through.

Location: Texas
FakerFace
7 years, 10 months ago
Well, I tried again and it went through this time. :\ Now I feel like an idiot. lol
arthurvandijk
7 years, 10 months ago
Successfully Uploaded a ~40 MB File to both pages. No progress indicator whatsoever, hangs on "Initializing..." Upload itself works just fine though...

Specs:
OS: Windows XP SP3
Browser: Google Chrome
Behind a NAT Router (shouldn't affect anything, but I don't have any use for an incoming firewall because of my NAT so I don't have one... Since only some users are affected, it might be a firewall related issue? Like some A-OK Packet that burns)

Other info:


Bezig met het traceren van de route naar inkbunny.net [62.212.67.22]
via maximaal 30 hops:

  1   <1 ms   <1 ms   <1 ms  <REMOVED>
  2    11 ms    39 ms    16 ms  <REMOVED>
  3     9 ms    42 ms    24 ms  p3129.net.upc.nl [212.142.3.129]
  4    47 ms    58 ms    39 ms  84.116.244.73
  5    30 ms    37 ms    11 ms  84.116.134.73
  6    32 ms    14 ms    19 ms  crs-evo.leaseweb.net [195.69.145.215]
  7    44 ms    19 ms    40 ms  po100.sr1.evo.leaseweb.net [85.17.100.226]
  8    24 ms    39 ms    21 ms  te5-1.sr5.evo.leaseweb.net [85.17.129.210]
  9    86 ms   108 ms   120 ms  inkbunny.net [62.212.67.22]

De trace is voltooid.

Pingen naar inkbunny.net [62.212.67.22] met 32 byte gegevens:

Antwoord van 62.212.67.22: bytes=32 tijd=20 ms TTL=56
Antwoord van 62.212.67.22: bytes=32 tijd=31 ms TTL=56
Antwoord van 62.212.67.22: bytes=32 tijd=14 ms TTL=56
Antwoord van 62.212.67.22: bytes=32 tijd=6 ms TTL=56
Antwoord van 62.212.67.22: bytes=32 tijd=12 ms TTL=56
Antwoord van 62.212.67.22: bytes=32 tijd=24 ms TTL=56
Antwoord van 62.212.67.22: bytes=32 tijd=8 ms TTL=56
Antwoord van 62.212.67.22: bytes=32 tijd=12 ms TTL=56
Antwoord van 62.212.67.22: bytes=32 tijd=54 ms TTL=56
Antwoord van 62.212.67.22: bytes=32 tijd=14 ms TTL=56

Ping-statistieken voor 62.212.67.22:
    Pakketten: verzonden = 10, ontvangen = 10, verloren = 0
    (0% verlies).De gemiddelde tijd voor het uitvoeren van ‚‚n bewerking in milliseconden:
    Minimum = 6ms, Maximum = 54ms, Gemiddelde = 19ms

Hope this helps!

Regards, Arthur
Perberos
7 years, 10 months ago
File 23.6MB on both pages with Firefox and GNU/Linux, all fine. I am from Argentina.

" network-tools.com wrote:

62.212.67.22 is from Netherlands(NL) in region Western Europe


TraceRoute to 62.212.67.22 [inkbunny.net]
Hop (ms) (ms) (ms) IP Address Host name
1 30 29 129 72.249.128.5 -
2 59 38 24 206.123.64.81 -
3 43 30 13 4.69.145.180 ae-83-80.ebr3.dallas1.level3.net
4 118 93 82 4.69.145.180 ae-83-80.ebr3.dallas1.level3.net
5 41 42 54 4.69.134.22 ae-7-7.ebr3.atlanta2.level3.net
6 40 46 54 4.69.134.138 ae-81-81.csw3.washington1.level3.net
7 42 55 74 4.69.134.153 ae-82-82.ebr2.washington1.level3.net
8 153 135 42 4.69.134.153 ae-82-82.ebr2.washington1.level3.net
9 149 131 130 4.69.143.177 ae-48-48.ebr1.dusseldorf1.level3.net
10 136 133 134 4.69.141.150 ae-1-100.ebr2.dusseldorf1.level3.net
11 144 141 153 4.69.143.209 ae-48-48.ebr1.amsterdam1.level3.net
12 137 134 135 4.69.139.137 ae-1-51.edge3.amsterdam1.level3.net
13 138 135 137 212.72.33.94 leaseweb-crs-evo.amsterdam1.level3.net
14 141 138 139 212.72.33.94 leaseweb-crs-evo.amsterdam1.level3.net
15 149 149 134 85.17.129.210 te5-1.sr5.evo.leaseweb.net
16 167 137 148 62.212.67.22 inkbunny.net

Trace complete
Sethvir
7 years, 10 months ago
Both upload mechanisms worked for me with a 22MB file.

The second mechanism was over SSL as I have full site encryption turned on.

I'm sending this from a university network in the UK, and have not experienced any connection problems before (though I've not needed to upload anything yet).
I get a very respectable 12ms ping time from here.

The next logical test I can think of would be to run another instance of Apache on a different port with default/different settings and see if that experiences upload issues too.
Is there anything fishy in the various logs?
voxelbunny
7 years, 10 months ago
Fail.

Simple version, Chrome 7 status bar said "Uploading (xx%)..." but counted up to 100% in a few seconds (unreasonable for a 100mb file, so not sure what data it was referring to), then status bar went to "Waiting for inkbunny.net...", then after some minutes, page went to Chrome's "Page cannot be found".

Login version, got the "Initializing..." message, no graphical bar, status bar says "Waiting for inkbunny.net...", then no change.

Ping is 380 ms, but ping to google is 240ms ... sounds like I need to call comcast again x_x
Giza
7 years, 10 months ago
Forgive me for stating something that's kinda obvious, but what is your max_execution_time setting in PHP?  If you're running into timeouts, that would explain why different upload sizes are working for different people, because everyone's upload speed will be slightly different.


starling
7 years, 10 months ago
Max execution time is at 600 secs. But it never gets to execute the destination script so that timeout isn't used. The error seems to occur during the data transmission phase as the data is being sent to Apache and before the script is actually executed.
AlexReynard
7 years, 10 months ago
Uploaded from an old, tempermental Mac in lower Michigan. No problems, though it did take quite a while.
Gedrean
7 years, 10 months ago
Chrome, no progress bar (it's Chrome, what can you say), Win 7 64bit, Time Warner in Ohio, it seems to be uploading albeit slowly ... cancelled at 30% of a 46MB file (well past 3 MB) cuz I got sick of waiting but maybe that'll help. ;)
EDIT: cancelled actually at 55%.  I forgot to cancel it. lol.
hydrowing
7 years, 10 months ago
Chrome on Mac, cannot see the progress bar, but can upload without problem.
I am from Beijing, China.
fanafox
7 years, 10 months ago
Okay, so I tried both pages in both Chrome and Firefox, and I tried each test a minimum of twice in each browser. I was using a 40 MB or so .mov file each time. Every time I tried, the connection was either reset or aborted a short ways in (Chrome claims the error codes were 101 and 103 respectively). I usually couldn't get past around 10 to 15%. In Firefox it would happen almost right after I hit "upload". Additionally, Chrome never got past "initializing" on the progress meter, but I could tell the progress of the upload from the status bar of the browser.

I'm using Windows 7, I'm in Palmdale, California, and my ISP is Time Warner. Here's the results of the traceroute and ping:

C:\Users\Julia Grammer>tracert inkbunny.net

Tracing route to inkbunny.net [62.212.67.22]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.2.1
  2    12 ms    11 ms     6 ms  cpe-24-24-132-1.socal.res.rr.com [24.24.132.1]
  3    30 ms    22 ms     7 ms  76.167.11.89
  4     8 ms     6 ms     5 ms  cpe-76-167-11-105.socal.res.rr.com [76.167.11.1
5]
  5     7 ms     6 ms     7 ms  cpe-66-75-145-178.socal.rr.com [66.75.145.178]
  6     8 ms     9 ms     7 ms  ae9.chswca1-rtr2.socal.rr.com [66.75.145.44]
  7     *       13 ms    11 ms  BE11-tustca1-rtr1.socal.rr.com [66.75.145.191]
  8    10 ms    11 ms    10 ms  ae-5-0.cr0.lax30.tbone.rr.com [66.109.6.64]
  9    13 ms    14 ms    12 ms  ae-1-0.pr0.lax00.tbone.rr.com [66.109.6.129]
 10    18 ms    17 ms    16 ms  TenGigabitEthernet4-1.ar4.LAX1.gblx.net [64.209
93.65]
 11   167 ms   167 ms   167 ms  204.245.38.170
 12   170 ms   170 ms   169 ms  po80.sr2.evo.leaseweb.net [62.212.80.74]
 13   162 ms   164 ms   164 ms  te5-1.sr6.evo.leaseweb.net [85.17.129.214]
 14   168 ms   170 ms   170 ms  inkbunny.net [62.212.67.22]

Trace complete.

C:\Users\Julia Grammer>ping inkbunny.net

Pinging inkbunny.net [62.212.67.22] with 32 bytes of data:
Reply from 62.212.67.22: bytes=32 time=169ms TTL=43
Reply from 62.212.67.22: bytes=32 time=166ms TTL=43
Reply from 62.212.67.22: bytes=32 time=170ms TTL=43
Reply from 62.212.67.22: bytes=32 time=174ms TTL=43

Ping statistics for 62.212.67.22:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 166ms, Maximum = 174ms, Average = 169ms


Let me know if there's any other info I could possibly give. Usually I don't upload large files but if I ever wanted to upload animations of mine in the future, I could see where this issue would be prohibitive, so here's hoping you guys mange to resolve it. XD
PraeTheUnicorn
7 years, 10 months ago
Upload complete at 2010-12-03 07:12:52 (server time).

Seems ok, from Great Britain
Choxy
7 years, 10 months ago
I am currently uploading the 69mb background I have made.  So far the only thing I can think of is do you have the server configured to allow larger files for uploading?  I had a similar problem on my site and the server company had it blocked past 2mb uploads unless it was directly via ftp.
Choxy
7 years, 10 months ago
Page went unavailable for the https://inkbunny.net/progresstest.php  page.  Uploading to the simple html form.

This webpage is not available.

The webpage at https://inkbunny.net/progresstest_process.php might be temporarily down or it may have moved permanently to a new web address.

Error 101 (net::ERR_CONNECTION_RESET): Unknown error.
Choxy
7 years, 10 months ago
Simple html page:

This webpage is not available.

The webpage at https://inkbunny.net/simpletest_process.php might be temporarily down or it may have moved permanently to a new web address.

  More information on this error
Below is the original error message

Error 101 (net::ERR_CONNECTION_RESET): Unknown error.
RobbyTiger
7 years, 10 months ago
traceroute to inkbunny.net (62.212.67.22), 30 hops max, 60 byte packets
 1  10.10.1.1 (10.10.1.1)  5.216 ms  8.830 ms *
 
 6  * ae-93-90.ebr3.Dallas1.Level3.net (4.69.145.244)  24.241 ms  24.031 ms
 7  ae-7-7.ebr3.Atlanta2.Level3.net (4.69.134.22)  41.290 ms  41.681 ms  41.738 ms
 8  ae-71-70.ebr1.Atlanta2.Level3.net (4.69.138.18)  43.490 ms  43.528 ms  43.512 ms
 9  ae-6-6.ebr1.Washington12.Level3.net (4.69.148.106)  55.573 ms  55.571 ms  55.638 ms
10  ae-1-100.ebr2.Washington12.Level3.net (4.69.143.214)  54.608 ms  55.555 ms  55.538 ms
11  ae-5-5.ebr2.Washington1.Level3.net (4.69.143.221)  55.916 ms  56.316 ms  48.906 ms
12  ae-41-41.ebr2.Frankfurt1.Level3.net (4.69.137.49)  141.581 ms  137.366 ms  143.705 ms
13  ae-47-47.ebr1.Dusseldorf1.Level3.net (4.69.143.173)  145.185 ms  142.366 ms  142.645 ms
14  ae-1-100.ebr2.Dusseldorf1.Level3.net (4.69.141.150)  141.451 ms  141.602 ms  139.469 ms
15  ae-46-46.ebr1.Amsterdam1.Level3.net (4.69.143.201)  147.284 ms  145.746 ms  146.117 ms
16  ae-1-51.edge3.Amsterdam1.Level3.net (4.69.139.137)  145.620 ms  148.329 ms  148.346 ms
17  leaseweb-crs-evo.Amsterdam1.Level3.net (212.72.33.94)  148.987 ms  144.731 ms  144.819 ms
18  po100.sr1.evo.leaseweb.net (85.17.100.226)  145.622 ms  147.013 ms  146.879 ms
19  te5-1.sr5.evo.leaseweb.net (85.17.129.210)  146.865 ms  146.813 ms  147.277 ms
20  inkbunny.net (62.212.67.22)  150.520 ms  144.382 ms  147.752 ms

PING
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=1 ttl=46 time=146 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=2 ttl=46 time=145 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=3 ttl=46 time=145 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=4 ttl=46 time=151 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=5 ttl=46 time=142 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=6 ttl=46 time=145 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=7 ttl=46 time=146 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=8 ttl=46 time=146 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=9 ttl=46 time=147 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=10 ttl=46 time=145 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=11 ttl=46 time=145 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=12 ttl=46 time=147 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=13 ttl=46 time=153 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=14 ttl=46 time=147 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=15 ttl=46 time=145 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=16 ttl=46 time=146 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=17 ttl=46 time=148 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=18 ttl=46 time=149 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=19 ttl=46 time=149 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=20 ttl=46 time=145 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=21 ttl=46 time=161 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=22 ttl=46 time=156 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=23 ttl=46 time=146 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=24 ttl=46 time=146 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=25 ttl=46 time=154 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=26 ttl=46 time=150 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=27 ttl=46 time=147 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=28 ttl=46 time=147 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=29 ttl=46 time=143 ms


--- inkbunny.net ping statistics ---
31 packets transmitted, 31 received, 0% packet loss, time 30044ms
rtt min/avg/max/mdev = 142.776/147.946/161.403/3.825 ms

both uploads complete 25 MB file Lawton OK, firefox, Ubuntu 9.10
RobbyTiger
7 years, 10 months ago
Just ran a 200 packets ping and after 100 pings i got this

64 bytes from inkbunny.net (62.212.67.22): icmp_seq=100 ttl=46 time=147 ms
(101 lost)
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=102 ttl=46 time=1038 ms
(103 lost)
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=104 ttl=46 time=144 ms
64 bytes from inkbunny.net (62.212.67.22): icmp_seq=105 ttl=46 time=167 ms
IamRy
7 years, 10 months ago
For me, the upload error may be linked to my recent internet troubles, since I was able to upload from a different computer under a different connection, so I won't say anything unless I get my good connection back and still face a problem.
OnyxKitty
7 years, 10 months ago
Using Firefox on Ubuntu 10.04 LTS:
1. Both worked.
2. US
SwiftKit
7 years, 10 months ago
Both worked just fine.

Kansas City, Time Warner Cable
Windows 7, Firefox 3.6.12
from behind a NAT router
Stars
7 years, 10 months ago
Both worked for me
Firefox, Windows XP
Australia
Bigpond DSL service
Quiet269
7 years, 10 months ago
I got "The connection to the server was reset while the page was loading." on both tries.

Though the internet here is rather fickle at times
Giza
7 years, 10 months ago
I created a file full of zeros as such:

" dd if=/dev/zero of=inkbunnytestfile.dat bs=1m count=25

I was able to upload that in both scripts successfully in Chrome on Mac OS/X.

One interesting thing I saw is that the progress meter did NOT work in Chrome.  It did not break the upload, however.

Now, a possible solution/workaround: why not do something similar to what Photobucket does, and allow users to specify a URL of an existing file on the web to be uploaded?  This would also give users the ability to port their content from Photobucket, Imgur, or any other website in a much easier manner.


Rorroh
7 years, 10 months ago
Hm... I personally think it's a timeout problem.  If the server was tinkered with, it might simply be cutting off connections because it's taking too long.
That's all I got.
I don't have my tools with me, else I probably would be a lot more help.
Rorroh
7 years, 10 months ago
GEEZ!  Or it may well be something else.  It took 5 minutes just to post that one comment.  My connection's been known to be bad and my computer isn't the best, but that was ridiculous!
Mechasquirrel
7 years, 10 months ago
In Opera on up to date Debian Squeeze, the simpletest page gave me an error page "Connection closed by remote server" on https://inkbunny.net/simpletest_process.php using a 25MB file of zeros (ibzerotest.bin)

Progresstest got up to 3.93mb before doing the same thing too.

Firefox, progresstest restarted the upload at 1.51MB, again at 2.11MB, again at 2.20MB and I canceled it. Simpletest quietly restarted the upload a couple times, then popped up a file save dialog box, "You have chosen to open simpletest_process.php which is a: PHP file.....open/save/etc" Saving it resulted in a zero byte file.

Second computer, same local network, with Firefox on Debian Lenny worked fine with same file on progresstest "Upload complete at 2010-12-04 07:12:08 (server time)."  and simpletest at 7:12:16..

Third computer, same network, Firefox on WinXP, progresstest succeeded at 7:12:34.

In other words, if I wanted to upload anything I can do it from anything but my primary computer, lol.


Similar traceroutes from all boxes, #18 fails...

~$ traceroute inkbunny.net
traceroute to inkbunny.net (62.212.67.22), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  1.183 ms  1.659 ms  2.093 ms
 2  69-29-33-1.dyn.centurytel.net (69.29.33.1)  9.621 ms  10.153 ms  11.835 ms
 3  208.54.220.26 (208.54.220.26)  12.881 ms  14.508 ms  15.744 ms
 4  host.lightcore.net (208.110.249.246)  20.818 ms  21.238 ms  34.212 ms
 5  bb-nlrkargp-jx9-02-ae2.lightcore.net (206.51.69.113)  23.982 ms  24.836 ms  26.078 ms
 6  bb-shptlayo-jx9-02-xe-1-1-0.core.centurytel.net (206.51.69.29)  33.567 ms  14.889 ms  15.937 ms
 7  bb-shptlayo-jx9-01-ae0.core.centurytel.net (206.51.69.61)  17.244 ms  18.099 ms  19.689 ms
 8  bb-dllstx37-jx9-01-xe-1-1-0.core.centurytel.net (206.51.69.33)  25.334 ms  26.898 ms  28.146 ms
 9  bb-dllstx37-jx9-02-ae0.core.centurytel.net (206.51.69.58)  29.184 ms  30.287 ms  32.233 ms
10  te1-1-0d0.cir1.dallas2-tx.us.xo.net (65.47.204.9)  34.277 ms  34.736 ms  36.905 ms
11  vb2001.rar3.chicago-il.us.xo.net (207.88.13.130)  64.350 ms  65.672 ms  66.623 ms
12  ae0d1.cir1.chicago2-il.us.xo.net (207.88.13.5)  52.339 ms  45.007 ms  45.896 ms
13  206.111.2.226.ptr.us.xo.net (206.111.2.226)  47.443 ms 206.111.3.10.ptr.us.xo.net (206.111.3.10)  48.828 ms  50.661 ms
14  nyk-bb2-link.telia.net (80.91.246.165)  62.172 ms nyk-bb1-link.telia.net (80.91.248.193)  63.832 ms  65.200 ms
15  ldn-bb2-pos7-1-0.telia.net (213.248.65.93)  137.045 ms ldn-bb2-link.telia.net (80.91.248.253)  141.442 ms ldn-bb2-link.telia.net (80.91.253.117)  141.938 ms
16  adm-bb2-link.telia.net (80.91.253.19)  150.815 ms adm-bb1-link.telia.net (80.91.245.223)  153.186 ms adm-bb4-link.telia.net (80.91.253.146)  152.478 ms
17  adm-b4-link.telia.net (80.91.247.67)  203.237 ms adm-b4-link.telia.net (80.91.253.156)  195.355 ms adm-b1-link.telia.net (80.91.253.165)  157.317 ms
18  * * *
19  po80.sr2.evo.leaseweb.net (62.212.80.74)  146.541 ms  147.588 ms  147.366 ms
20  te5-1.sr6.evo.leaseweb.net (85.17.129.214)  148.648 ms  151.006 ms  151.700 ms
21  inkbunny.net (62.212.67.22)  153.503 ms  154.433 ms  157.149 ms
Loupy
7 years, 10 months ago
I uploaded the picture on the two test pages, but when trying to upload on my own inkbunny page it keep telling me it was too big.
Tupsu
7 years, 10 months ago
I was able to upload only small files but when I tried something bigger on test pages uploads failed. Every time when I was uploading file on progress meter page, upload speed slowed significantly about after 1 MB.

I'm from Finland

Progress meter test 1: Uploaded 9.99MB of a total 127.25MB FAILED
Progress meter test 2: Uploaded 3.31MB of a total 127.25MB FAILED
Progress meter test 3: Uploaded 1.74MB of a total 71.45MB FAILED

ping inkbunny.net -t -l 65500
Pinging inkbunny.net [62.212.67.22] with 65500 bytes of data:
Reply from 62.212.67.22: bytes=65500 time=462ms TTL=56
Reply from 62.212.67.22: bytes=65500 time=461ms TTL=56
Reply from 62.212.67.22: bytes=65500 time=462ms TTL=56
Reply from 62.212.67.22: bytes=65500 time=461ms TTL=56
Reply from 62.212.67.22: bytes=65500 time=462ms TTL=56
Reply from 62.212.67.22: bytes=65500 time=461ms TTL=56
Reply from 62.212.67.22: bytes=65500 time=461ms TTL=56
Reply from 62.212.67.22: bytes=65500 time=461ms TTL=56
Reply from 62.212.67.22: bytes=65500 time=462ms TTL=56
Reply from 62.212.67.22: bytes=65500 time=462ms TTL=56
Reply from 62.212.67.22: bytes=65500 time=461ms TTL=56

TRACEROUTE
  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     8 ms     7 ms     7 ms  IP-ADRESS [IP-ADRESS]
  3    15 ms    16 ms    16 ms  IIP-ADRESS [IP-ADRESS]
  4    24 ms    24 ms    24 ms  Port-channel1.463.ar2.ARN3.gblx.net [67.17.157.4
5]
  5    45 ms    45 ms    45 ms  204.245.38.170
  6    46 ms    46 ms    53 ms  po80.sr2.evo.leaseweb.net [62.212.80.74]
  7    46 ms    46 ms    46 ms  te5-1.sr6.evo.leaseweb.net [85.17.129.214]
  8    46 ms    46 ms    46 ms  inkbunny.net [62.212.67.22]
Ende
7 years, 10 months ago
having the same problem again when i upload my zip file.
Country: Brunei
google Chorme
win 7
Buck
7 years, 10 months ago
went ahead and tried again on all three browsers. Each time, the connection hung up. Only SeaMonkey showed a progress meter, and according to it, the upload was crawling under .06 megabytes per second. It, too, hung up around .44 mb out of 21 mb.

I'm in Memphis, TN, and I'm a Comcast subscriber, for now. I use a MacBook Pro with OS 6, and to be honest, I haven't had a problem uploading my 9+ MB music files, except for once. I'm not sure what to chalk my test results up to, because I haven't been having problems.

(I used Safari, SeaMonkey, and Chrome.)
KingofVermin
7 years, 10 months ago
It wouldn't be a problem with a ban of Cub Porn and Sonic Porn, including fan characters.
Alfador
7 years, 10 months ago
Uploaded a 56.5MB mp3 file, progress version worked perfectly, now trying the simple version, I'll let you know if there were any oddities there.
Alfador
7 years, 10 months ago
Upload complete on the simple one too!

Vital statistics:
OS: Windows XP Pro
Browser: Firefox 3.6.12
Location: Seattle, WA, USA
ivanbunny
7 years, 10 months ago
I think it's network side. Encapsulation issues  most likely.
yak
yak
7 years, 10 months ago
It becomes difficult to maintain a stable connection all throughout the process of uploading a large file when your TCP/IP stack gets busy. Unless you have fine tuned your OS defaults for the stack, sockets, socket buffers, connection timeouts, TCP window sizes etc.  then the  limitations of their default values are what's you're running into.
I can suggest a few places to look in and a few possible causes to the problem, but I'm going to be needing more info from you. The name of your distribution and the output of `sysctl -a`, ran as root, would be a good start. The latter is quite long, so it'll be better if you link it as a file.
Inkbunny
7 years, 10 months ago
I emailed you! Thanks so much for offering to help! :P -Starling
Automat
7 years, 10 months ago
Pinging inkbunny.net [62.212.67.22] with 32 bytes of data:
Reply from 62.212.67.22: bytes=32 time=73ms TTL=51
Reply from 62.212.67.22: bytes=32 time=72ms TTL=51
Reply from 62.212.67.22: bytes=32 time=72ms TTL=51
Reply from 62.212.67.22: bytes=32 time=72ms TTL=51

Ping statistics for 62.212.67.22:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 72ms, Maximum = 73ms, Average = 72ms

Tracing route to inkbunny.net [62.212.67.22]
over a maximum of 30 hops:

  1    13 ms    99 ms    99 ms  dsldevice.lan [10.0.0.138]
  2    95 ms    99 ms    99 ms  dsldevice.lan [10.0.0.138]
  3    22 ms    22 ms    22 ms  192.168.180.14
  4    23 ms    23 ms    22 ms  217.22.189.129
  5    22 ms    23 ms    22 ms  ge2-0-15-int-bkara1.datastream.com.mt [217.15.97
.226]
  6    64 ms    64 ms    63 ms  195.81.215.85
  7    63 ms    64 ms    64 ms  xe-3-0-0-0.fra-006-score-2-re0.interoute.net [21
2.23.42.145]
  8    73 ms    73 ms    73 ms  decix.crs.evo.leaseweb.net [80.81.192.246]
  9    72 ms    72 ms    72 ms  po100.sr1.evo.leaseweb.net [85.17.100.226]
 10    73 ms    72 ms    73 ms  te5-1.sr5.evo.leaseweb.net [85.17.129.210]
 11    73 ms    72 ms    72 ms  inkbunny.net [62.212.67.22]

location: malta
New Comment:
Move reply box to top
Log in or create an account to comment.