Flashing on Droid Charge fails with "Expected file part index" error #14

alchemicalhydra · 2011-06-06T22:42:49Z

I'm seeing the following issue when attempting to flash my Droid Charge using Heimdall under Arch Linux:

athena:~/android/charge% sudo heimdall flash --kernel zImage --recovery recovery.bin

Heimdall v1.2.0, Copyright (c) 2010-2011, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/


Claiming interface...   Failed. Attempting to detach driver...
Claiming interface again...   Success
Setting up interface...   Success
Beginning session...
Handshaking with Loke...   Success

Downloading device's PIT file...
PIT file download sucessful

Uploading KERNEL
0%
ERROR: Expected file part index: 0 Received: 1
KERNEL upload failed!
Ending session...
Failed to receive session end confirmation!
Re-attaching kernel driver...

I've had to run the close-pc-screen command afterward to successfully reboot my phone.

This is a brand new Droid Charge that I just received today, and hasn't had any system updates applied yet.

I noticed someone with a similar issue on XDA-Developers in this thread (username "distortedloop").

I'm using Heimdall built from the latest GitHub commit on master (ab4073b).

The text was updated successfully, but these errors were encountered:

Benjamin-Dobell · 2011-06-07T03:43:59Z

As you've noted. This is currently a known issue. The Droid Charge seems to use the protocol slightly differently than other Galaxy S devices.

A big thanks to Dave Mueller who has tried a few different things to get this working, we have made some progress.

However, if anyone is able to get me a USB log of flashing in Odin or Kies then that would immensely helpful.

Benjamin-Dobell · 2011-06-07T03:50:01Z

Existing progress notes:

Setting SendFilePartPacket::kDefaultPacketSize = 65536, allows expected file part indices to be received however the following error is then encountered:

Failed to confirm end of file transfer sequence!

One potential solution I had in mind would be, in BridgeManager.cpp, set:

kMaxSequenceLength = 1600

Those of you interested in testing it's recommended you don't test with any files involved in the boot process, i.e. steer clear of boot.bin, Sbl.bin and param.lfs.

alchemicalhydra · 2011-06-07T23:32:42Z

I made both the aforementioned changes (to kDefaultPacketSize and kMaxSequenceLength), and had the following result:

athena:~/android/charge% sudo heimdall flash --kernel zImage

Heimdall v1.2.0, Copyright (c) 2010-2011, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/


Claiming interface...   Failed. Attempting to detach driver...
Claiming interface again...   Success
Setting up interface...   Success
Beginning session...
Handshaking with Loke...   Success

Downloading device's PIT file...
PIT file download sucessful

Uploading KERNEL
100%
Failed to confirm end of file transfer sequence!
KERNEL upload failed!
Ending session...
Rebooting device...
Re-attaching kernel driver...

The upload went very slowly, and as soon as it started, a red RX_TIMEOUT appeared on my Charge's download screen. The upload still progressed, however, and my phone successfully rebooted. I'm not yet sure whether my phone's kernel was actually flashed or not, though.

alchemicalhydra · 2011-06-09T17:10:36Z

Distortedloop offered to get a log using Odin if instructions showing how to do so could be posted.

alchemicalhydra · 2011-06-09T19:18:40Z

Just for the hell of it, I tried:

kMaxSequenceLength = 3200

... but that doesn't seem to make a difference; I get the red RX_TIMEOUT almost right away, and the same slow upload and subsequent Failed to confirm message.

I'm willing to try testing other Heimdall modifications as suggested.

alchemicalhydra · 2011-06-10T03:36:35Z

I managed to get Odin working under a VirtualBox install of Windows XP, and successfully flashed images that way to my Droid Charge. I'm willing to experiment as necessary to help get Heimdall working.

Benjamin-Dobell · 2011-06-10T05:22:44Z

It would be great if you could get a USB capture for me whilst flashing within Odin. The process is actually fairly straightforward with VirtualBox and Linux as the Linux kernel has the necessary functionality built in. WireShark should make the process even simpler:
http://wiki.wireshark.org/CaptureSetup/USB

alchemicalhydra · 2011-06-10T16:16:46Z

How's this?

http://tomxtobin.com/odin-recovery-flash-log

I started the Wireshark capture before starting Odin, flashed imnuts's CWM recovery image to my Charge, and then stopped capture once the phone was rebooting following the successful flash.

If there's anything else I can get you, please let me know.

Benjamin-Dobell · 2011-06-10T17:44:44Z

Okay, I've had a quick look over the log.

It looks like Samsung are still transferring 131072 bytes of data before expecting a response from the mobile phone. However, instead of sending the data as one big bulk transfer it's instead being sent as 16 transfers of 8192 bytes.

Try the following source modification with the current official source (so remove any other modifications).

Replace BridgeManager.cpp lines 808 - 817:

        // Send
        sendFilePartPacket = new SendFilePartPacket(file);
        success = SendPacket(sendFilePartPacket);
        delete sendFilePartPacket;

        if (!success)
        {
            InterfaceManager::PrintError("\nFailed to send file part packet!\n");
            return (false);
        }

with:

        for (int i = 0; i < SendFilePartPacket::kDefaultPacketSize; i += 8192)
        {
            // Send
            sendFilePartPacket = new SendFilePartPacket(file, 8192);
            success = SendPacket(sendFilePartPacket);
            delete sendFilePartPacket;

            if (!success)
            {
                InterfaceManager::PrintError("\nFailed to send file part packet!\n");
                return (false);
            }
        }

alchemicalhydra · 2011-06-10T18:36:12Z

I got the Expected file part index: 0 Received: 1 error again using only the above change against master.

Benjamin-Dobell · 2011-06-11T02:27:17Z

Hmm, the steps performed by Heimdall should be the same as those that were being performed by Odin in that log.

Is there any chance you'd be able to get a failed flash log with an unmodified master build of Heimdall and then again with the most recent mentioned modification included?

Thanks for going to all this effort!

alchemicalhydra · 2011-06-11T04:06:08Z

Sure thing:

Benjamin-Dobell · 2011-06-11T05:21:45Z

Strange, they're pretty much identical up until the time when the phone responds to Heimdall with an incorrect file part index. The only two differences are that Heimdall requests some extra data from the device just after initialising the connection and the other thing is simply that the transfer timing is different.

If you comment out lines 349 - 377 of main.cpp:

// -------------------- KIES DOESN'T DO THIS --------------------
deviceInfoPacket = new DeviceInfoPacket(DeviceInfoPacket::kUnknown2);
success = bridgeManager->SendPacket(deviceInfoPacket);
delete deviceInfoPacket;

if (!success)
{
    InterfaceManager::PrintError("Failed to send device info packet!\nFailed Request: kUnknown2\n");
    return (false);
}   

deviceInfoResponse = new DeviceInfoResponse();
success = bridgeManager->ReceivePacket(deviceInfoResponse);
unknown = deviceInfoResponse->GetUnknown();
delete deviceInfoResponse;

if (!success)
{
    InterfaceManager::PrintError("Failed to receive device info response!\n");
    return (false);
}

// TODO: Work out what this value is... it has been either 180 or 0 for Galaxy S phones, 3 on the Galaxy Tab, 190 for SHW-M110S.
if (unknown != 180 && unknown != 0 && unknown != 3 && unknown != 190)
{
    InterfaceManager::PrintError("Unexpected device info response!\nExpected: 180, 0 or 3\nReceived:%i\n", unknown);
    return (false);
}
// --------------------------------------------------------------

then Heimdall will no longer request the additional data from the device.

If that doesn't solve the issue then the only difference left should be the timing. In which case it's probably worth trying to flash with the --delay parameter set to a value of 15 (or perhaps 7), i.e.

heimdall flash --cache cache.rfs --delay 15

Let me know how you go.

alchemicalhydra · 2011-06-11T05:55:20Z

I get the same error with those lines commented out.

I'm also having trouble with the --delay argument:

athena:~/android/charge% sudo heimdall flash --recovery recovery.bin --delay 15
"-delay" is not a valid argument

Do you want to create a temporary Git branch for me to test from, just to make sure I'm working with the correct set of modifications? (e.g., at the moment I do not have kDefaultPacketSize modified in SendFilePartPacket.h)

Benjamin-Dobell · 2011-06-11T06:14:59Z

The --delay argument issue should be fixed if you pull the latest update:
7cbd3c0

I'm actually surprised it was even compiling with the missing commas in the commonArgumentNames array initialiser.

Benjamin-Dobell · 2011-06-11T06:21:27Z

I won't create a separate branch just yet as I don't believe any of the modifications I've suggested have really had any impact. The original kDefaultPacketSize value seems correct. Whilst the 8192 loop modification does bring Heimdall more in line with how Odin functions on your PC, I have a feeling it's not actually a requirement.

If adding a delay does fix the problem then I'm going to be a bit annoyed at the fact the device requires such an inefficient flashing mechanism. However if it doesn't work I'm going to be scratching my head as I'm pretty much out of ideas.

alchemicalhydra · 2011-06-11T06:27:46Z

--delay 15 (or --delay 7) seemed to result in a red DOWNLOAD COMPLETED flashing on the download screen for a moment before rebooting, but it still seems to have failed (the recovery is still the stock one).

Here's the output:

athena:~/android/charge% sudo heimdall flash --recovery recovery.bin --delay 15
Password: 

Heimdall v1.2.0, Copyright (c) 2010-2011, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/


Claiming interface...   Failed. Attempting to detach driver...
Claiming interface again...   Success
Setting up interface...   Success
Beginning session...
Handshaking with Loke...   Success

Failed to receive device info response!
Ending session...
Rebooting device...
Failed to receive reboot confirmation!
Re-attaching kernel driver...

Benjamin-Dobell · 2011-06-11T06:37:56Z

Hmm, I'm at a bit of a loss for now. If the issue is timing related then it's going to require a bit of coding to sort it out. Although it would be quite unusual if it was timing related.

I'm going to be pretty busy for next couple of days (maybe longer) but I'll definitely look into this as soon as I get a chance.

Thanks for all the testing and getting me those logs, you've been extremely helpful!

alchemicalhydra · 2011-06-11T06:42:01Z

Thanks for looking into this; I definitely appreciate it!

At least I have Odin for the time being; it's a minor hassle to fire up a Windows VM, but it works as a stopgap solution.

Definitely let me know if there's anything else you'd like me to try.

boostedjti · 2011-06-13T14:46:19Z

I too experience the rx_timeout while trying to flash anything. Oddly enough, if I download an ed1 file, which shipped with the phone, it will flash perfectly fine as long as it's a fresh download. Any other file, regardless of when it was downloaded will not flash...

If there's anything I can do to help, just let me know.

sebirdman · 2011-06-28T21:19:16Z

There is some new software for flashing the charge called "samsungPST"

r2DoesInc · 2011-07-08T22:45:48Z

any progress on this? i have no access to a windows machine and am currently trying to unbrick my charge with heimdall and getting the same errors.

deybhayden · 2012-02-05T01:43:41Z

I know this issue is way old - but got this same issue on ArchLinux yesterday, but was able to reboot the phone pass the message mentioned in the first post. Just making sure that Droid Charge is just un-flashable with Heimdall at this point? I'm kinda a freetard, so I don't want to set up a Windows virtual machine just to root my phone. :D

If it's a lost cause, I'll just deal with it until I get a newer droid. Thanks!

deybhayden · 2012-02-06T21:58:57Z

NVM, I set up a trial version of Windows & used ODIN to flash my phone. Thanks anyways!

jpeeler · 2012-03-25T02:01:53Z

I've run into the same exact issue here with v1.3.1. Is there anything I can provide that would help move this forward?

Benjamin-Dobell · 2012-03-31T01:37:46Z

Could someone please run v1.3.2 and confirm whether this problem still persists?

jpeeler · 2012-03-31T17:40:46Z

$ sudo ./heimdall flash --recovery ~/Downloads/recovery.bin
Heimdall v1.3.2, Copyright (c) 2010-2012, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
ERROR: Failed to retrieve config descriptor
$ sudo ./heimdall flash --recovery ~/Downloads/recovery.bin --verbose
Heimdall v1.3.2, Copyright (c) 2010-2012, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
Manufacturer: "SAMSUNG"
Product: "Gadget Serial"

        length: 18
  device class: 2
           S/N: 0
       VID:PID: 04E8:68C3
     bcdDevice: 021B

iMan:iProd:iSer: 1:2:0
nb confs: 1

interface[0].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: 02.02.01
endpoint[0].address: 83
max packet size: 0010
polling interval: 09

interface[1].altsetting[0]: num endpoints = 2
Class.SubClass.Protocol: 0A.00.00
endpoint[0].address: 81
max packet size: 0200
polling interval: 00
endpoint[1].address: 00
max packet size: 0000
polling interval: 00
Claiming interface...
Setting up interface...

Checking if protocol is initialised...
Protocol is not initialised.
Initialising protocol...
Handshaking with Loke...
ERROR: Failed to send data: "ODIN"

Benjamin-Dobell · 2012-10-02T01:05:30Z

Please try the Heimdall 1.4 release candidate to ensure this is fixed. If not, you can let me know if the problem still persists by re-opening the issue.

alchemicalhydra · 2012-11-15T15:40:24Z

The issue still exists with the latest Git build. (I don't seem to have a "reopen" option for the ticket.)

I'm seeing this a lot, too, when I try to flash; nothing seems to happen:

Heimdall v1.4 RC1

Copyright (c) 2010-2012, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au/

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
Claiming interface...
Attempt failed. Detaching driver...
Claiming interface again...
Setting up interface...

Checking if protocol is initialised...
Protocol is not initialised.

Initialising protocol...
Protocol initialisation successful.

Beginning session...
Releasing device interface...
Re-attaching kernel driver...

fisxoj · 2012-12-25T22:56:37Z

Here's an attempt today with heimdall from git on fedora 18.

Heimdall v1.4 RC1

Copyright (c) 2010-2012, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au/

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
Manufacturer: "SAMSUNG"
Product: "Gadget Serial"

        length: 18
  device class: 2
           S/N: 0
       VID:PID: 04E8:68C3
     bcdDevice: 021B

iMan:iProd:iSer: 1:2:0
nb confs: 1

interface[0].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: 02.02.01
endpoint[0].address: 83
max packet size: 0010
polling interval: 09

interface[1].altsetting[0]: num endpoints = 2
Class.SubClass.Protocol: 0A.00.00
endpoint[0].address: 81
max packet size: 0200
polling interval: 00
endpoint[1].address: 02
max packet size: 0200
polling interval: 00
Claiming interface...
Attempt failed. Detaching driver...
Claiming interface again...
Setting up interface...

Checking if protocol is initialised...
ERROR: libusb error -686090344 whilst receiving packet.
Protocol is not initialised.

Initialising protocol...
Protocol initialisation successful.

Beginning session...
Session begun with device of type: 180.

Downloading device's PIT file...
PIT file download successful.

Uploading LTEMODEM
0%
ERROR: libusb error -686090344 whilst receiving packet. Retrying...
ERROR: libusb error -686090344 whilst receiving packet. Retrying...
ERROR: libusb error -686090344 whilst receiving packet. Retrying...

File Part #0... Response: 0 0 0 0 1 0 0 0

ERROR: Expected file part index: -689023200 Received: -1
ERROR: (null) upload failed!

Ending session...
ERROR: libusb error -686090344 whilst receiving packet. Retrying...
ERROR: libusb error -686090344 whilst receiving packet. Retrying...
ERROR: libusb error -686090344 whilst receiving packet. Retrying...

ERROR: Failed to unpack received packet.
ERROR: Failed to receive session end confirmation!
Releasing device interface...
Re-attaching kernel driver...

alchemicalhydra · 2012-12-29T17:06:07Z

I've stopped using my Droid Charge entirely and "downgraded" to a Droid X that seems to give me fewer overall problems. I wouldn't mind lending the Charge out for the purpose of fixing this bug, but I want to get my hands on another spare/backup phone first in case my Droid X dies on me.

Programmerino · 2023-07-25T09:23:50Z

The exact same original issue is still present in v2.0.2 with the Droid Charge:

heimdall flash --FACTORYFS /home/pmos/rootfs/samsung-sch-i510.img
Heimdall v2.0.2

Copyright (c) 2010-2017 Benjamin Dobell, Glass Echidna
https://www.glassechidna.com.au/

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
https://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
Claiming interface...
Attempt failed. Detaching driver...
Claiming interface again...
Initialising protocol...
Protocol initialisation successful.

Beginning session...

Some devices may take up to 2 minutes to respond.
Please be patient!

Session begun.

Downloading device's PIT file...
PIT file download successful.

Uploading FACTORYFS
0%
ERROR: Expected file part index: 0 Received: 1
ERROR: FACTORYFS upload failed!

Ending session...
ERROR: Failed to receive session end confirmation!
Releasing device interface...
Re-attaching kernel driver...

Red RX_TIMEOUT text is additionally displayed on the top-left of the screen.

Benjamin-Dobell closed this as completed Jun 7, 2011

Benjamin-Dobell reopened this Jun 7, 2011

roblem mentioned this issue Jun 20, 2012

ERROR: Failed to confirm end of file transfer sequence! on Galaxy S III when flashing CF-Root v6.3 #43

Closed

ghost assigned Benjamin-Dobell Sep 11, 2012

Benjamin-Dobell closed this as completed Oct 2, 2012

kLeZ mentioned this issue Oct 4, 2012

galaxy tab P7510 "ERROR: Failed to initialise protocol!" #26

Closed

rjmcguire mentioned this issue Oct 5, 2012

not able to flash Galaxy s3 userdata partition #55

Closed

getochkn mentioned this issue Oct 17, 2012

T959W Support #66

Closed

luckasfb mentioned this issue Nov 12, 2012

New Device: GT-I8160 #74

Open

duskiv mentioned this issue Jan 12, 2013

ERROR: libusb error -7; Heimdall v1.4 RC1; Galaxy S2 i9100 #91

Closed

gigcast mentioned this issue Mar 14, 2013

v1.4 RC2: hangs on "Uploading KERNEL 100%" #105

Closed

DirkTerblanche mentioned this issue Jun 11, 2013

I9100 - Partition "KERNAL" does not exist in the specified PIT #129

Closed

giamteckchoon mentioned this issue Jun 15, 2013

GT-S7562 ERROR: FAT upload failed! #133

Open

eclipxe13 mentioned this issue Aug 1, 2013

ERROR: Failed to confirm end of file transfer sequence! on P5113 Galaxy Tab 2 10.1 with Heimdall 1.4~rc1+dfsg-1 #147

Closed

myHelloWorld mentioned this issue Aug 11, 2013

How to flash new bootloader on S3 I9300 - in new LLA stock rom #90

Closed

siemer mentioned this issue Aug 11, 2013

Specific factoryfs.img triggers “ERROR: Failed to confirm end of file transfer sequence!” #150

Open

efferre79 mentioned this issue Dec 28, 2014

doubts about PIT decoding for Nexus S GT-I9023 #248

Open

locomanolo mentioned this issue Jan 8, 2015

Gs5 fixes for Pit + flash #225

Open

VanFranz mentioned this issue Oct 24, 2015

G900W8 (VLU1BOC2) Cant print .PIT #305

Open

zclandry mentioned this issue Jan 8, 2016

Failed to confirm end of file transfer sequence #323

Open

orz007 mentioned this issue Mar 4, 2016

help to flash i9100 #331

Closed

DrDrebon mentioned this issue Jun 26, 2016

ERROR: Failed to unpack received packet. and PIT downloading only thing to work #349

Open

shaqaruden mentioned this issue Jul 24, 2017

Samsung Galaxy A520W #407

Open

lsimplify mentioned this issue Feb 15, 2018

v1.4.1 softbricking SPH-P100 tablets with the flash command "heimdall flash --KERNEL <filename>" #454

Open

GNUtoo mentioned this issue Sep 21, 2021

Heimdall can flash files bigger than partitions #494

Open

Programmerino mentioned this issue Jul 25, 2023

Droid Charge: Failed to bulk read: Connection timed out (110) Samsung-Loki/Thor#10

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Flashing on Droid Charge fails with "Expected file part index" error #14

Flashing on Droid Charge fails with "Expected file part index" error #14

alchemicalhydra commented Jun 6, 2011

Benjamin-Dobell commented Jun 7, 2011

Benjamin-Dobell commented Jun 7, 2011

alchemicalhydra commented Jun 7, 2011

alchemicalhydra commented Jun 9, 2011

alchemicalhydra commented Jun 9, 2011

alchemicalhydra commented Jun 10, 2011

Benjamin-Dobell commented Jun 10, 2011

alchemicalhydra commented Jun 10, 2011

Benjamin-Dobell commented Jun 10, 2011

alchemicalhydra commented Jun 10, 2011

Benjamin-Dobell commented Jun 11, 2011

alchemicalhydra commented Jun 11, 2011

Benjamin-Dobell commented Jun 11, 2011

alchemicalhydra commented Jun 11, 2011

Benjamin-Dobell commented Jun 11, 2011

Benjamin-Dobell commented Jun 11, 2011

alchemicalhydra commented Jun 11, 2011

Benjamin-Dobell commented Jun 11, 2011

alchemicalhydra commented Jun 11, 2011

boostedjti commented Jun 13, 2011

sebirdman commented Jun 28, 2011

r2DoesInc commented Jul 8, 2011

deybhayden commented Feb 5, 2012

deybhayden commented Feb 6, 2012

jpeeler commented Mar 25, 2012

Benjamin-Dobell commented Mar 31, 2012

jpeeler commented Mar 31, 2012

Benjamin-Dobell commented Oct 2, 2012

alchemicalhydra commented Nov 15, 2012

fisxoj commented Dec 25, 2012

alchemicalhydra commented Dec 29, 2012

Programmerino commented Jul 25, 2023

Flashing on Droid Charge fails with "Expected file part index" error #14

Flashing on Droid Charge fails with "Expected file part index" error #14

Comments

alchemicalhydra commented Jun 6, 2011

Benjamin-Dobell commented Jun 7, 2011

Benjamin-Dobell commented Jun 7, 2011

alchemicalhydra commented Jun 7, 2011

alchemicalhydra commented Jun 9, 2011

alchemicalhydra commented Jun 9, 2011

alchemicalhydra commented Jun 10, 2011

Benjamin-Dobell commented Jun 10, 2011

alchemicalhydra commented Jun 10, 2011

Benjamin-Dobell commented Jun 10, 2011

alchemicalhydra commented Jun 10, 2011

Benjamin-Dobell commented Jun 11, 2011

alchemicalhydra commented Jun 11, 2011

Benjamin-Dobell commented Jun 11, 2011

alchemicalhydra commented Jun 11, 2011

Benjamin-Dobell commented Jun 11, 2011

Benjamin-Dobell commented Jun 11, 2011

alchemicalhydra commented Jun 11, 2011

Benjamin-Dobell commented Jun 11, 2011

alchemicalhydra commented Jun 11, 2011

boostedjti commented Jun 13, 2011

sebirdman commented Jun 28, 2011

r2DoesInc commented Jul 8, 2011

deybhayden commented Feb 5, 2012

deybhayden commented Feb 6, 2012

jpeeler commented Mar 25, 2012

Benjamin-Dobell commented Mar 31, 2012

jpeeler commented Mar 31, 2012

Benjamin-Dobell commented Oct 2, 2012

alchemicalhydra commented Nov 15, 2012

fisxoj commented Dec 25, 2012

alchemicalhydra commented Dec 29, 2012

Programmerino commented Jul 25, 2023