Installing Boot to Gecko – Part 1
For the past month or so Stefan Reese and I have been talking about various things mobile, from what’s new and cool on Android to the various devices coming to market. Stefan is basically my source for everything mobile and keeps a fresh stream of info coming my way. When I heard about Boot to Gecko I obviously had to show Stefan about it and he seemed pretty stoked about it. Once Mozilla demoed B2G at the Mobile World Congress 2012 and I saw what it was really about I wanted it pretty bad. I’ve been playing with idea of installing it on my device ( luckily I have a Samsung Galaxy S II, which seems to be what most of the demos are on ) and when Stefan mentioned he was interested in trying it out as well, I figured I may as well do it.
First thing’s first, it seems to be recommended that you do the build on Linux ( the latest version of Ubuntu seems to be what most guides are recommending ) so that’s what I did. Since I was already running Windows on my desktop I used Ubuntu’s Window’s installer, which allows you to install Ubuntu right alongside an already existing Windows install ( no reformatting/partitioning needed! ). Once I installed Ubuntu I installed the usual things that I would on a fresh install ( flash, vim, git, got all my music up and running, set up thunderbird, ect ) and begin following the guides that I found online. One of the great things about the Mozilla community is how well they document things. I was able to follow the steps for the most part with no hiccups. I followed these guides and they seemed to do the trick, so I also recommend them! Just and FYI, I accept no responsibility if you brick your phone by following my steps 
Setting up my enviroment so it was ready to install B2G was pretty simple. It involved getting adb up and running ( which I had prior experience with from some Android development I’ve done ). You can do this by installing the Android SDK ( once installed you may need to run android-sdk-linux/tools/android and update the SDK ). Once that is done, you will need to add adb ( inside android-sdk-linux/platform-tools/ ) to your path ( done in your ~/.bashrc ). You can test this easily by going to your terminal and typing adb, you should see something like the following:
Now I was ready to backup my phone, which required installind heimdall, which is a cross-platform tool used to flash firmware onto Samsung Galaxy S devices. After installing heimdall you are going to need make sure it has access to your phone ( which is done via udev ). I did this by editting /etc/udev/rules.d/android.rules ( if it doesn’t exist create it ) and adding the following line:
sudo apt-get build-dep firefoxsudo apt-get install git mercurial libasound2-dev libcurl4-openssl-dev libnotify-dev libxt-dev libiw-dev mesa-common-dev autoconf2.13sudo apt-get install ia32-libs gcc-multilib g++-multilib bison flex gperf lib32z-dev lib32ncurses5-dev lib32ncursesw5-dev libidl-dev lib32gomp1 autoconf2.13 ccache libx11-dev lib32readline-gplv2-devsudo apt-get install default-jdkwget cmw.22aaf3.com/c1/recovery/recovery-clockwork-4.0.1.4-galaxys2.tartar xvf recovery-clockwork-*taradb reboot downloadheimdall flash --kernel zImageadb reboot recoverymkdir sgs2-androidcd sgs2-androidadb pull /system systemadb pull /vendor vendor
cd B2G ( or wherever you have it as )make sync ( from what I can tell it updates a ton of submodules that are in the project. Depending on how fast your connection is this may take a while, as it did for me. ).export ANDROIDFS_DIR=sgs2-android ( should be exported to the same PATH that you updated earlier )make config-galaxy-s2OSD700 0.8
This release I finally got time to sit down and focus on the first bug I was assigned this semester, which was 686370 ( Implement video playback statistics proposed in WHATWG ). The playback statistics were already started earlier and a few portions of it have already been implemented ( mozParsedFrames, mozDecodedFrames, mozPresentedFrames, mozPaintedFrames, and mozPaintDelay ). What I was to do for this ticket was to finish off the remaining statistics that needed to be implemented ( scroll down to the bottom ). Mathew Schranz also expressed interest in helping with this so I’m sure you’ll catch him blogging about his experiences as well.
To get things started I was fortunate enough to have some class time allocated to go over how we would begin working on this bug. Dave went over what would need to be done in order to get this implemented and how we would go from the decoder level all the way up to the DOM. We began by taking a look at the already implemented portions of the spec and began tracing a route that they took from an idl file all the way down into the decoder. This was invaluable to me as I got input from the class on what they would do, thoughts from others who have worked with idl files before, as well as an understand of the scope of what I would be working on. After we traced a path through the code it was time to begin coding.
I went home that night and basically didn’t know which statistics I wanted to do first, so I just chose the one at the top of the list, which was bytesReceived. bytesReceived is described as “The raw bytes received from the network for decode. Together with the downloadTime, this can be used to calculate the effective bandwidth. Includes container data.” which basically means that we need a way to measure all of the data that we are downloading for a given media element. I took a similar approach to what was done before in the video idl file and applied it to the media element idl file. I began forging my own path down to the decoder and began seeing some results. Once I got into the decoder I found a portion of the code that looked like what I needed to monitor and got access to the data I needed. I battled with making this correct for the next few nights and it actually turned out that I wasn’t even in the right code, as I’m confident now the data that I need is hidden within the media cache somewhere. I took the weekend off to work on my car and think about this and it dawned on me that what I actually found and created was bytesDecoded. I ended up renaming things accordingly and testing it again and it seemed like exactly what I needed. 1 down, 5 to go 
.
Next I decided to work on dropped frames, as I scrambled my brain a bit trying to comprehend some of the media cache code. droppedFrames is defined as “The number of frames of video that have been dropped due to performance reasons. This does not include (for example) frames dropped due to seeking.”. This means that we need a way to measure any frames that are not displayed, which will provide developers with a way to measure the speed of the decoding pipeline ( at least a portion of it, more accurate results would be achieved is used in conjunction with other media statistics ). Since this particular statistic was referencing frames I knew it would be directly related video only, and we could ignore the audio portion of the media element. This enabled me to do some caro culting and copy what I could from earlier implementation of the video statistics. Once I reached the decoder I did some searching and read through the code a bit and ended up finding the following snippet in the nsBuiltinStateMachine.cpp and added in a small piece of code that would keep track of all of the frames that were skipped and report them to a setter that I created in nsMediaDecoder for mozDroppedFrames. The setter would simply increment a value that I had stored in the nsMediaDecoder and I also had a getter that would be able to reach in and get the value of droppedFrames. It looked like a pretty solid first attempt and I rolled with it and all seemed to be working well. The problem that I am having is finding out if I did it right, because I seem to be getting the same results for both high-def videos and low-def videos ( 1080 vs 480 ). This doesn’t seem like it should be the case and I should probably look into this further.
The next steps for the statistics are to get the remaining few implemented and get this up for review as soon as possible. I’m sure that I’ve done a few things the wrong way, or it isn’t optimized enough, so I’m looking forward to getting some feedback. Until then, expect a few more blog posts about this and expect these stats to be landing in one of the upcoming Firefox Nightlies .
1982 El Camino restoration – Days 3 & 4
Since my last post ( where we decided to paint portions of the car the wrong color ) we decided that it would be best to just bite the bullet and paint the rest of the car the same color as our screw up. The new orange isn’t that bad, it’s pretty bright but thats no big deal. So day 3 began with us sanding off the old clear coat and paint and getting it ready for primer again. This meant re-taping the whole car again ( all of the chrome, windows, bumper, ect ) and sanding down the old paint a bit so the primer would stick. This required a lot more work then it sounds like, as the taping alone took many hours. Sanding off the old paint, even tho there wasn’t much of it, was a huge pain in the ass.
The old paint was difficult because we layered so much clear coat on in hopes that if the paint did turn out a bit shitty, that we could sand any imperfections out of the paint. This actually turned around to bite us in the ass as sanding clear coat of sucks the big one. But we bit the bullet and spent almost and entire day painting and taping; it was hard work but the car should be better because of it. That ended of our weekend a week ago and we didn’t end up doing any work during the week as we all have fulltime jobs and are pretty busy.
Yesterday we were able to reconvene to begin working on the rest of the sanding that needed to be done and prep it for primer. We went over the body once more with sandpaper and finished the hood that we never got to the previous weekend. The hood in particular was a bitch to sand down as we dumped the remaining clear coat on there. Once all of the sanding and taping was done we blew off all of the dust that the car was covered in and whipped down the car with a small amount of paint thinner to get any of the remaining paint to come off. Now we were ready for some primer!
The primer we used this time around was pretty old and stank like hell. It ended up going on pretty thick so it looks like were going to have a lot of sanding to do again today to get the car ready for paint. The primer began clogging the gun a bit so the paint went on a bit cottage-cheesy ( some chunks came out and made small bumps in the paintjob ). Luckily this was pretty contained and only ended up on the hood, so we should be able to concentrate our efforts there in sanding and it should turn out pretty well ( crossing my fingers on that one ).
In addition to the sanding and taping yesterday I also got a bit of a surprise when I got to the shop yesterday. My brother found me a set of headers for my car and was just finished installing them as I rolled up. I was stoked to see how they sounded so he fired her up. In the video you will see my brother have to open the door and pop his head out mid way through because it was so loud and the exhaust fumes were coming through the floor ( there are massive holes in my floor at the moment ahaha ). It sounds amazing currently and can’t wait to put an exhaust on it ( I decided on purple hornies ). I also took some pictures of the fucked up floor and the under part of the car so you can see what we are doing after the body work, which is replacing the floor.
Today were painting the rest of the car, so hopefully it runs out! More pictures and another post to come later.
Implementing video playback statistics in Firefox – part II
Over the past few days I have begun working on implementing video playback statistics in Firefox. I ended my last post with some build failures and couldn’t figure it out at the time. The first part of the statistics that I began implementing was mozBytesReceived ( scroll down ), which is a readonly property on a media element that tells the user how many bytes have been downloaded so far. I continued working on this for the last 2 nights and finally I got it to build again. The problem I’m now encountering is that I have not implemented the feature correctly and ran into a few cases where my initial idea was just wrong.
The build error I was getting last night was:
Undefined symbols for architecture x86_64
It also mentioned that a function was not properly defined, so after get Jon to look at it as well that’s what I did. I found the problem pretty quickly and it ended up that the compiler was telling the truth ( who would have thought ), I was indeed missing a function declaration. It actually turned out that in some of my trial and error coding I tried to implement my bytesDownloaded() function in both nsBuiltinDecoder.cpp and nsMediaDecoder.cpp, which was obviously wrong. I did a bit more searching and came across a piece of code that was referring to media statistics, so I took a more in depth look there.
I ended finding a statistics struct that defined some properties that looked similar to what I was working with ( mPlaybackRate, mDownloadRate, mTotalBytes, etc ) so I figured this would be a good place to see if I could begin working. After looking through the nsBuiltinDecoder.cpp file I found a GetStatistics() function that defined some values for the statistics struct. The function from a high level explanation did the following:
- Makes sure we are on the main thread using an assertion
- We create an instance of the Statistics struct
- We check to see if we have a resource yet, if we do get the values for the various struct properties, else provide some sane defaults
What I did next was define my own mozBytesReceived property in the struct and set it up so if there was no resource we would return 0 ( as there is no bytes downloaded yet ) and if there was a resource I would call my GetBytes() function I made previously on mPlaybackStatistics. So after doing this and building again ( in addition to removing the duplicated code I mentioned earlier ) I finally got it building again! The next thing I did was test to make that my implementation was correct and that I could access the property on the video element.
The first thing I did was find myself a video page and created a little test function in the console. My test function looked like the following:
setInterval(function(){ console.log( document.getElementsByTagName( “video” )[0].mozBytesDownloaded ); }, 100);
What it did was set an interval on which I would fire a function that logged the result of mozBytesDownloaded. So this seemed like a good idea to me so I ran it, which gave me lots of numbers!!!!
At this point I thought I had figured it out as I was getting numbers to flow through the console, I thought I was done! I should have known better that it’s never that easy, nothing ever works the first try. I let the video finish and all seemed well at first, until I decided to click back to the start of the video. To my surprise the amount of bytes “downloaded” continued to rise. Wait, what? Why is it doing that? Well after some searching I found out the culprit was the GetBytes function I wrote yesterday:
PRUint64 GetBytes() {
return mAccumulatedBytes;
}
The problem was the mAccumulatedBytes wasn’t doing what I thought it was. It wasn’t returning the total amount of bytes that were downloaded, but rather the total amount of bytes that were decoded, which wasn’t exactly accurate. Back to the drawing board I suppose.
At this point I am trying to see if there is a better place for me to hook into in the decoder somewhere. I looked for a while last night but didn’t find anything that overly caught my eye. I figure tonight I’ll head over to the #media channel in IRC and see if someone there can point me in the right direction.
Implementing video playback statistics in Firefox
Early this year I began my second course in Open Source development taught by David Humphrey. I have been working on various Firefox bugs since the beginning of the semester and have landed 2 tickets so far, with a 3rd on the way. The 3rd ticket that I am working on is almost done and just requires a few tests to be written then it should be good to go. While I muster up some motivation to write the tests I figured I may as well begin working on the biggest ticket I took on this semester, which is implementing the rest of the video playback statistics in Firefox. I was initially going to work on it alone, but Mathew Schranz expressed interest in working on it as well, so why not, the more the merrier!
We began by dividing up the remaining features that were still needed which included the following:
- bytesReceived – the number of raw bytes received from the network for decode
- downloadTime – the time since first HTTP request is sent until now or the download stops/finishes/terminates (whichever is earlier)
- networkWaitTime – the total duration of time when a playback is stalled, waiting to receive more data from network
- videoBytesDecoded – the number of bytes of video data that have been decoded
- audioBytesDecoded – the number of bytes of audio data that have been decoded
- droppedFrames – the number of frames of video that have been dropped due to performance reasons
- playbackJitter – it is useful for applications to be able obtain an overall metric for perceived playback quality and smoothness
I decided that I would take bytesReceived, downloadTime, networkWaitTime, and dropped frames while Mathew would take on videoBytesDecoded, audioBytesDecoded, and playbackJitter. I decided to simply start at the top of the list and work my way down, so bytesReceived was first. Since Humph went over this in class last week I had a good idea of where to start, so I picked up where we left off. Using MXR I looked up where the other parts of the playback statistics had been implemented and worked out from there. My guess was that I wouldn’t need to do too much heavy lifting, as much of the work was probably done for me ( I mean, they must keep track of what they are downloading somehow ) so I began digging through various mediaElement, decoder, and mediaStream files. I eventually ended up pieces of code for each of the various video encoding formats and began sifting through what was there. Eventually I found a function that seemed like something I wanted:
void nsBuiltinDecoder::NotifyBytesConsumed(PRInt64 aBytes)
After looking at the function a bit closer I noticed that it called another function, AddBytes on the mPlaybackStatistics object, which seemed liked something that was related to what I was doing here ( not to mention it was referencing playback statistics! ). Looking closer at AddBytes I noticed it was adding the number of bytes passed into it to a local variable in the decoder called mAccumulatedBytes. I was pretty confident at this point that what we wanted for bytesDownloaded was simply all of the bytes that we have downloaded so far, which im pretty confident is mAccumulatedBytes. Now I was ready to start coding!
I started by defining the attribute, mozBytesDownloaded, inside of the idl file located at dom/interfaces/html/nsIDOMHTMLMediaElement.idl inside mozilla-central. I made it a readonly attribute that was an unsigned long ( as i’m pretty sure that there will be no negative values here, so why not ). Next I needed to find a way to reach into the decoder and access the value of mAccumulatedBytes, so I took a look at the route that was currently being taken by similar functions to get to the decoder. I decided to look at how Chris Pearce originally did this for the already existing portions of the video playback statistics ( mozParsedFrames, mozDecodedFrames, mozPresentedFrames, mozPaintedFrames, mozPaintDelay ). After doing another search on MXR I found that this was being done inside nsHTMLVideoElement.cpp . Seeing as the bytesDownloaded attribute applied to both audio AND video, I couldn’t do this in here but told me it needed to be done in the nsHTMLMediaElement.cpp file instead.
Inside the nsHTMLMediaElement file I saw similar getters and setters to those that were in the videoElement file, such as GetMozSampleRate, GetMozFrameBufferLength, and many more. I figured a good place for my new function, GetMozBytesDownloaded, would be at home with these guys. I did a bit of cargo culting and stole what logic I could from GetMozFrameBufferLength as it was also accessing the decoder so seemed ok to me. What I needed to do from here was find my way into the decoder and it looked like GetMozFrameBufferLength was doing so also ( it was calling GetFrameBufferLength() ) so I decided to look where I could write my own function to access the data that I needed. The method was being defined in nsMediaDecoder.h so I figured it was a good place to put mine as well. After doing a bit of poking around and checking out what else was in here I found the function that brought me down this path, NotifyBytesConsumed! I was feeling even more confident now in my function placement and created my own, getBytesDownloaded. I did some more cargo culting here and stole what I could from NotifyBytesConsumed. I figured I didn’t need the check that NotifyBytesConsumed had for mIgnoreProgressData as it looked like it was pertaining to whether the video seeked or moved the play position; we only cared about how many bytes were downloaded. Instead of calling AddBytes on mPlaybackStatistics I figured I would yet again write my own function, getBytes. Just like I did previously, I looked up how AddBytes was implemented and followed suit where I could( which was done in MediaResource ). All my function did was ensure that the video had started ( if it wasn’t started, return early ) and if it had started then return the number of bytes that we have downloaded. Alright great, now lets compile this and see what happens. Anddddd build failures 
I managed to fix a few failures but I am currently stuck on one that looks like the following:
Undefined symbols for architecture x86_64:
“nsMediaDecoder::bytesDownloaded()”, referenced from:
nsHTMLMediaElement::GetMozBytesDownloaded(unsigned int*)in nsHTMLMediaElement.o
ld: symbol(s) not found for architecture x86_64
It’s gotten pretty late now, so I am going to tackle this in the morning and hopefully I figure it out then.
1982 El Camino restoration – Day 2
Yesterday I wrote about the beginning of a long project that I have started in restoring a 1982 El Camino. We managed the get a lot of the sanding, bondo, and taping done yesterday but we still had a lot to do today.
I woke up at 8am this morning as I had to finish off some coding stuff before I could begin working on the car again, which sort of sucked but whatever. By the time 10am rolled around I headed out to pick up some more supplies that we needed. Some finer grit sand paper, more tape, and various painting supplies ( the paint, clear coat, activator, reducer, primer, ect ). After nearly 2 hours of driving around, attempting to figure out the right paint color, and finally getting back to the shop we were able to start working. My brother Ryan, my friend Matt and I began sanding off the remaining bondo that we put on last night ( which was quite a bit ). Once we got the bulk of this done, which took about 2 hours, we went over the entire car in a super fine grit sand paper to make it as smooth as possible. This made it so the body was less noticeable and blended with the car a lot better. We then proceeded to finish taping the car off in preperation for painting and covered all of the sanded areas in primer. After this we wiped down the whole car to remove any remaining dust/sanding remnants and cleaned it as best we could. It was now time to paint!
My brother began mixing the paint ( I don’t know much about this process ) and prepped the spray gun. Seeing as we don’t have proper facilities for painting the room becomes congested with fumes and it’s obviously a horrible idea to stand in there while it’s going on so we waiting outside and watched in as my brother continued to layer the car with paint. At this point we were thinking “Hey that color looks pretty close” ( its worth mentioning that we half assed finding out the color of the car and guessed to save time ) and were pretty proud of ourselves for guessing the color bang on. After the layers continued to flow onto the car it became quite aparent that this was NOT the right color. If the original color of the car was basketball orange it was now borderline neon orange. I’m not gonna lie, my jaw dropped when I saw what we had done and it was definitely a face palm moment. We all looked at each other with stupid looks on our faces for a few seconds and then all burst out laughing at how retarded we were. At this point there was no use in crying over spilt milk and all we could do was accept it and make the best out of it. The new direction were taking is that we are going to paint the rest of the car to match the new color, which isn’t all bad, I actually sorta like it ( it definitely stands out ). The only downside to this is that we have to go back to the shop tomorrow, sand the rest of the car and prep it for paint all over again. This means sanding, taping, priming and all. Its gonna be another long day.
After the paint fiasco we wanted to have some fun so we decided to cut the exhaust off the car and see what the engine really sounded like ( it came with a dinky v6 exhaust that sounded like crap ). Below is a video of the result…
video-2012-03-10-21-03-15.theora.ogv
In total today we spent about 9 hours working on the car today and will probably spend another 9 tomorrow. My fingers are raw and bloody from sanding so much today, so I’m not looking forward to another day of it haha, but it’ll be worth it in the end! Thanks again to my brother and Matt for all the help!
1982 El Camino restoration – Day 1
So this is a bit off topic from my normal blog posts, but I figure it would be fun to blog about something other than coding for a change, so I am going to be blogging about a probably 10 – 20 day ( spread over 2 – 3 months ) process in restoring my new El Camino!
Ever since I was a child I have had this crazy fascination with El Camino’s. I know it’s weird that most kids like Mustangs, Corvettes, or other well known muscle cars, but I couldn’t get over the uniqueness of the El Camino. Maybe because it so closely resembled a truck, but still wasn’t one ( might have had something to do with that my Dad has always driven a pick up truck – seriously I’ve never seen him drive a car or even ride in one ). To me it was the best of both worlds, and it’s a car that I have always dreamed of owning. Recently I’ve picked up a few side jobs and have been saving a good chunk of money since about January. I shopped around for the last couple weeks to try to find the right one – something not too expensive, but also not a complete peace of trash. I knew I would buy something that would be a bit of a project, I mean, that’s half the fun! So I settled on a 1982 orange El Camino on Tuesday of last week, it was an amazing day to say the least! My brother Ryan ( he’s a heavy equipment mechanic by trade, so he is basically the one doing most of the work or delegating it to me when he can ) went up to Barrie, Ontario to pick it up. The car cost me $3800 in total, which is pretty good compared to some of the other ones I looked at. We took that car back to my Dad’s shop in Action, Ontario that night and tore the inside of the car apart until about 2am that night. When did a complete inspection of the car and determined what we needed.
The car overall was in pretty good shape. It had a recently rebuilt transmission in it that looked almost new, as well as a rebuilt 350 ( motor ) with about 30000km on it. The breaks were also in good shape, and sadly were in better shape than my current vehicle haha. The tires and rim’s were also in pretty decent shape. The rim’s were a bit rusted, but the chrome around the outside was still in pretty good shape and in addition to the tread on the tires. The floor of the car was in really ruff shape, and probably the biggest issue on the car. It was completely rusted through and we determined instead of trying to weld indivdual panels on and try and patch it that we would bite the bullet ( or I would ) and buy a whole new floor. We ordered this yesterday and it should be arriving on Monday, so next weekend we hope to have a new floor! The body was also in pretty rough shape.
From a distance the body looked to be in great shape, it’s actually a really nice looking car considering it’s 30 years old ( definitely had some body work done in the past, but not a big deal ). On closer inspection their was some glaring problems that needed to be fixed. There were quite a few small rust spots that needed to be filled. This included one major section above the drivers side door which actually leaked into the interior of the car, causing the roof to rot a bit and the material inside to fall apart. There were spots where the paint was peeling, rust was showing, pieces falling off, and generally bad stuff. Originally the owner had a tonneau cover on it which meant there was a ton of left over snaps all over the back of the car. A lot of these were rusting and just didn’t fit with the overall look that I was going for. This was probably the most annoying thing that we were going to have to fix, so we decided to tackle this first.
We began by grinding off all of the tonneau cover snaps and grinding any rust own to bare metal. Doing something like this definitely hurt’s at first. you start to see your brand new car being torn into pieces and it begins to look like complete chaos to be honest. What was nice orange paint initially becomes scratched up bare metal – small holes become bigger and more issues begin to come up. Neither of us are very good at body work, so this will probably be the hackiest fix we do on the car and were really praying for a nice outcome haha. We grinded down any remaning spots and sanding the area surrounding it. The reason that we sand around the area’s where we grinded is so that the primer will stick to it ( a rough surface is better than a smooth one ). Next we covered all of the spots we touched in primer, which preps it for bondo. We let this try for a bit and had a few beers.
Next we filled all of the holes with a thick bondo and let it harden. For those of you who don’t know what bondo is ( or cheese as my brother likes to call it ), it’s essentially filler for wholes or deep scratches. We applied it on quite liberally and let it harden, which doesn’t take long as we added a hardening agent to the mixture. After that we took some coarse sandpaper to the affected areas and begin smoothing it out. The goal here is to make the area we covered in bondo flush with the body of the car, ensuring that their is no visible bumps or waves in the area. This sounds easier than it is and actually requires a lot of elbow grease and hard work. In total tonight I estimated that I sanded about 3 – 4 hours on and off, which really gives your arms a workout. After this we mixed up a thiner version of the bondo we used before and covered the affected area a bit more. We did this because the initial bondo was to fill the holes that were there, where this bondo was to fill any smaller crevices and easier to sand a smooth out. Instead of using coarse sand paper, we can use a finer grain that ultimately allows us to make the finish much smoother. I also forgot to mention that there was a ton of taping that was done before any priming/sanding/bondo was done. We do this because we do not want to mess up the chrome finish at all and only want to touch the affected areas. It may look like a mess, but I swear we no what were doing ( I think ).
We worked for about 6 hours tonight and are in good shape to fix a lot of stuff tomorrow ( today? ). We will be able to come in in the morning and sand down the last layer of bondo that we applied and smooth it out as best we can. We are also going to remove the tires and sand off any rust and down to the bare metal. After that we are going to paint the rim’s gloss black which should stand out nicely with the chrome outside of the tires. We are also going to hit up the paint shop in the morning to try and match the color of the car to some paint so we can clean up all the areas that we covered patched up today.
This is going to be a long and probably expensive process, but it’s also extremely rewarding. It’s awesome being able to go from coding and manipulating the web to using my hands to bend, shape, and manipulate a vehicle. Being able to have this change of pace in my life is really something I need, as I was beginning to get into a repetitive 18 hour a day coding grind and really needed to switch stuff up. My goal is to have the car on the road with a few nice upgrades this by mid May, so wish my friends, brother, and I luck! Expect lots of pictures and videos!
