Monday, September 11, 2017

Left 4 Dead 2 Video Project Retrospective

L4D2 Action Footage Retrospective

My first foray back into video editing has wrapped, and it was a valuable success.
Final video

The final product matched my initial expectations and I gained a lot of knowledge about Adobe Premiere; its quirks and its powers.

As with previous projects I used JIRA to track my work-load and time spent; continuing my theory that video editing fits within the Agile programming methodology. From this analysis I can put hard number to mistakes and good decisions made during the editing process.

I categorized all post-production work into the above JIRA epics.

Software vs. Art

Film editing is a marriage between software skills and artistic skills. As a person with a background in both areas, I find this kind of work very satisfying. Roughly speaking, this project involved a 50/50 split between 'software' related tasks and 'art' related tasks.

The reality of video editing is that a lot of my time is spent grappling with the nuances of software. For example, I spent about as much time dealing with importing and exporting footage than I did doing timeline manipulation (e.g. splicing and arranging footage). This is perhaps the most valuable insight I gained from this post mortem review.

This 'non-art' time represents an inherent overhead cost involved with video projects. That is to say, if I expect to start and finish new projects on a weekly basis, I need to factor in a lot of time for overhead.

I lucked out in the sound department. The original footage had nearly perfect audio and I could focus most of my time on the visuals.

Overall my estimations aren't too far off. That is, from a project-level view my overestimates balanced out my underestimates.

The most important metric here is my timeline editing accuracy. Of all the tech area, I believe timeline editing is the area with the least unknowns (for me anyways) and it can be my most reliable indicator for a project's overall complexity and time.

I anticipate that my software related activities should be mitigated or streamlined over time (as I learn the tools better). As for my 'art' related activities, it's less important to reduce the time spent and more important to realistically quantify how long it will take.

Lessons Learned
My timeline editing accuracy remains strong. Keep up the good work. *pats self on back*
For me it is unintuitive how much time is needed for import/export tasks. Trust my metrics to keep these estimates realistic.

Best and Worst Estimations

Time allocated for normalizing footage between different camera angles turned out to be a freebee. No color balance or audio balance was needed. This actually makes a lot of sense, since raw footage from both camera angles were obtained from the same video capture software (OSB Studio); both using out-of-the-box settings.


  • There were a couple work tickets that were originally scoped out for work in every scene that turned out to only need work in one scene (e.g. trim loading screens).
  • With misc tech related tickets I tend to bake in time to allow for 2-3 failed attempts. A couple of tickets this project succeeded on the first attempt (e.g. Update version of Premiere).


  • All of my worst offenders were import/export related tickets, ranging from 200% to 300% extra time needed to complete.
  • Dealing with non-fixed frame-rate footage was surprise for me. I had to tool up on a new piece of software (Handbrake) to tackle this issue.
  • Downloading and uploading footage required a surprising amount of baby-sitting. Download of large files failed frequently (~10 attempts to complete) and publishing of large files to YouTube failed frequently (~5 attempts to complete).

There was a fairly consistent correlation between scene length and time spent editing. Sc05 (the final scene) was the best bang for my buck, which makes sense. All the other scenes involved characters running through dozens of different locations, while the final scene only involved action in a single large location. Less time was needed to establish the location for the audience.

My actual time spent per scene was very consistent. However, my estimations varied wildly.

This project was edited chronologically. Overestimation in Sc01 was understandable, since I had no data to base it on. I overcompensated for estimates in Sc02, and so on.

Lessons Learned
I am stronger at estimating based on technical area than based on scenes' content.

When were Technical Areas Focused?

Again, editing was chronological. First 3 sprints were focused on timeline editing. The first sprint had a lot of import work, and the last sprint had a lot of export work (no surprises there).

The visual effects (none of which were part of the original scope) were applied last. The visual effect ended up clarify some confusing parts of the footage  (e.g. text on screen, watermarks), as suggested from feedback from a test viewing audience between sprint 2 and sprint 3.

Lessons Learned

  • The test viewing mid-project was invaluable, and resulted in a much cleaner final product. It also gave me time to pivot.

Product Fulfillment

Did I deliver on time?
Yes. It took 4 weeks and I finished 2 weeks early.

Burndown charts from all 4 sprints

Quality of life?
Work pace was consistent and there were no crunch times.
I originally estimated that 44 man hours would be needed to complete the project, and I ended up spending 46 man hours.

Did I deliver what I promised?
Yes. Original estimated scope of project was nearly on point; and only 15% of the originally planned work was replaced by higher priority backlog creep items (i.e. all the visual effect work).

Preventing Distractions
When editing chronologically I find it very tempting to get caught up in perfecting individual edits. For this project I did a good job time-boxing myself on difficult edits; I created a backlog ticket for anything that was taking more than 1 minute to do. This resulted in dozens of small tickets in the backlog intended for me to go back later and tighten difficult moments.

Most of the backlog creep remained unfinished; dozens of 30 minute stories. Final viewings of the footage proved to me that all the issues I felt were bothersome during my initial rounds of editing turned out to be non-distracting. Hence, no need to do them after all.

Lessoned Learned

  • Backlog any edit that takes more than 1 minute to do. It will likely turn out to be a non-MVP issues.


All in all, I'm very happy with my work and I'm excited for my next project: editing Overwatch gameplay footage from 6 different camera angles. I anticipate the most of my tooling from this project will be re-usable.

How to run Airflow in Windows (with Docker)

Exercising Airflow in a Windows Environment

Airflow is a work scheduling and queuing technology, with distributed/dispatching capabilities.

I've recently integrated Airflow into a project's data pipeline. It's a very customizable solution, but for those looking just to fire up a quick example to play around with, this article is a guide to spinning up out-of-the-box Airflow in a local Windows environment. It's not the greatest solution for production purposes, but it's enough to get familiar with the product.

This guide only goes through an example of running Airflow in non-distributed mode.

Support for Windows

Native installations of Airflow on Linux is officially supported.
Native installation in Windows is not supported. 

There are hacks out there to get Airflow running naively in Windows, however instead I recommend utilizing Airflow within a Docker container. This method requires no modification to your host machine, and encapsulates all Airflow activity in a mini-VM.

This guide assumes a base familiarity with docker (and assumes that you have Docker For Windows installed on your machine.

Strictly speaking, this article could also be used for OSX and Linux machines. That is any machine with Docker installed can use this article. Otherwise I'd recommended following the steps to install Airflow natively for a quicker setup

This article does also assumes a basic familiarity with airflow terminology.

Setting up docker-airflow

Pull down the following docker image.

docker pull puckel/docker-airflow

This will download a 1.39GB docker image image
This image is based on debian:buster; fairly thin, with very limited command line functionality.

After pulling the image you'll need to create docker container, and have 3 terminal sessions open to run/manage operations.
  1. A terminal to start the webserver (and keep it running)
  2. A terminal to start the scheduler (and keep it running)
  3. A terminal to issue ad-hoc CLI commands

Starting the Webserver

Instantiate a new docker container from the docker-airflow image.
The entrypoint for this docker immediately starts the airflow server with the default airflow configuration.
The webserver process will run indefinitely. Keep this session alive; handy to see webserver output. (Otherwise if this session is broken the webserver will continue to run)

The webserver's configuration file (airflow.cfg) is baked into the docker image. You cannot make any changes the config file until after the container is started. 
The docker container's entrypoint executes a script which exposes a few minor command line options that allow you to deviate from default airflow configurations.

For Example:

Starting the Scheduler

The Airflow scheduler process does not automatically start when the Airflow webserver starts. It needs to be started manually. Connect to the existing container via a bash session, then kick of the scheduler.
The scheduler process will run indefinitely. Keep this session alive.

Start bash session for CLI

Many Airflow operations can be conducted through the web UI; otherwise there are some important operations can only accomplished via CLI; namely adding new DAGs.

Limited Command Line Functionality

The docker-airflow image is lacking several command line features that you may be used to.
Any file manipulation through a bash session is very difficult because there are no text editors installed in the image (e.g. vim, emac). Instead copy files to/from the container, and manipulate the files on your host machine.

Also note that these bash sessions can use the -t option (for TTY) as it is not supported by the docker image. Thus, tha bash session wil have extremely limited functionality (e.g. no tab completion, use of arrow keys will input junk characters into your commands, etc.)

If you want a more feature rich docker image you'll have to re-build docker-airflow with desired modifications.

Add DAGs

Create the DAG .py scripts on your host machine, then copy it over

Update Config

Edit a version of the airflow.cfg file on your host machine and copy it over.

Saturday, August 19, 2017

Synchronicity Post Mortem

A year from now we'll look back on this and laugh…

A year has passed since my film debut of Synchronicity; enough time for me to stomach a thorough retrospective. I'll assess what went well, what went poorly, and any wisdom that I may carry with me to future film projects.

While many of my film's issues source all the way back to elements in production and pre-production (e.g. bad script, sloppy shoot), for this retrospective I'll only focus on the the final months of post-production leading up to the premiere.

During post-production I used JIRA as a tool to track my progress; running with the theory that agile software development techniques can work for filmmaking. So, I have some actual numbers and graphs to back-up my insights.

How much time was spent?

In post production I spent 265 hours over the course of 9 two-week sprints.
I divided my work into 147 tickets; averaging 1.75 hours of work per ticket.

The first 50% of the project was accomplished working at a steady pace of 15 hours per sprint. During this period my routine involved 1 hour per day (done immediately after getting back from my day job). This comfortable pace lasted for 8 sprints.
The last 50% of the project was all crammed into the last sprint. In essence, I accomplished 4 months of work in 2 weeks. Needless to say working on the project in the last two weeks ate up every waking moment when I wasn't working my day job.

What went well?
A slow pace at the start was important for me to get accustomed to the tools and to keep me from getting discouraged about the overall workload). I was using my time management tools effectively, which emboldened me to know that I could realistically pull off a final push to reach my MVP.

What went poorly?
Crunch time was brutal; I was physically drained by the end of the project. I slept little and my roommates scarcely saw me :P.

Lessons Learned
One of agile's principles includes "maintain a steady pace of work indefinitely". It's important to prevent burnout. The spike in work was forecastable and should have been amortized early on (by increasing my daily work load to 2 hours per day instead of 1).

Which Technical Areas did I focus on?

During post-production I touched all areas of video and audio. Namely, I grouped my work into the following technical categories.

Pickup Shots - Filming any remaining missing footage. Mostly close ups of props and computer monitors. These shots were intentionally deferred to post-production, as the actor's time during production was precious, and these shots had no actors in frame.
Visual Effect - Generating special visual effects layered on top of existing footage (i.e. using Adobe After Effects).
Timeline Editing - Slicing and arranging footage on the timeline. Ensuring smooth visual continuity between clips.
Sound Editing - Finding and/or generating new audio clips. Filling in sounds missing from the original footage (i.e. foley).
Sound Mixing - Volume balancing between multiple simultaneous audio layers. Ensuring smooth audio continuity and comprehensible dialog.
Misc - Hardware and logistical challenges outside of touching footage.

At a high level, 50% of my time was spent manipulating/cleaning content from production (Timeline Editing + Sound Mixing) and the other 50% was spent generating new content (Pickup Shots + Visual Effects + Sound Editing).

Not every sprint touched all technical areas. It varied from sprint to sprint.

My early sprints concentrated work on one technical area at a time. I choose this approach in order to practice each technical area at least once, by painting broad strokes, before focusing on the polish.

For example:
Sprint 1 : Timeline focus. A first pass at laying out all clips on the timeline. Any tricky or bothersome edit was deferred for later.
Sprint 2 : Sound mixing focus. A first pass at audio smoothing. Anything not solved by a simple crossfade was deferred for later.
Sprint 3 : Sound editing focus. Filling in foley for everyday easy-to-find sound effects (doors, chairs, etc.). Sounds for complex machinery were deferred.
Sprint 4 : Pickup shot focus. Filming anything that required minimal staging (filming my computer monitor at my desk: email inbox, IRC chat, etc). Off-site shoots were deferred.

What went well?
I intentionally minimized the amount  of visual effects work because I knew this was my biggest risk area. Namely I had never used Adobe After Effects before. I went as far as re-using the same clip several times throughout the movie (and the audience didn't seem to notice). Also a variety of work in different technical areas kept the project from getting stale (especially in the final weeks). I freely switched back and forth between audio/video work or new/old content work to exercise different parts of the brain.

What went poorly?
The amount of time needed to generate missing content took me by surprize. As it turns out, I spent more time staging and filming pickup shots than I did during principle photography. Also, finding usable audio clips of complex machinery proved very difficult. A lot of time was wasted hunting on YouTube for suitable noises. Some lines of dialog were unsalvageable, and they had to be omitted from the film entirely.

Lessons Learned
I learned that some kinds of audio cleaning are easier than others. If the principle footage has bad audio for background noises, this can be more easily fixed in editing. However footage with bad quality dialog is very time-consuming. In my next project I'll need to dedicate someone on set to verifying audio quality before moving onto the next scene.

How linear/chronological was my editing?

There are 36 scenes in my movie. I did not film them in chronological order, nor did I strictly edit them together in chronological order.

The first 8 sprints were spent organizing a basic foundation for each scene and punting all nuanced editing for later. During this phase of work I only focused on 4-5 specific scenes per sprint and I didn't move on until playback achieved basic plot continuity for said scenes. For all issues punted I created a backlog ticket in JIRA ticket, to be scheduled for later sprints

Consequently, my final sprint was spent churning through a backlog of difficult tickets; to apply finishing touches across all 36 scenes.

What went well?
Laying down the over framework first allowed for sanity checks on the overall tone and pace of the film. It provided a good opportunity to re-arrange large aspects of the story, and omit unnecessary lines of dialog entirely. I felt this process helped me suss out all the boring moments in the film before I committed them to being in the timeline.

What went poorly?
My backlog built up a tremendous amount of polishing work. My assumption was that in a time pinch I could drop most of the polishing work and still have an MVP. However, nearly all of the polishing work turned out to be crucial requirements. Hence a late realization for how much high priority work was actually left to do.
Lessons Learned
When punting polishing work for later I should have taken a moment to assign priority to the work (i.e. crucial for MVP or not). Don't automatically assume all polishing work is optional. Also, I should have periodically revisited the backlog at the end of each sprint to assess if my pace was on par for the deadline.

Which scenes required the most attention?

The amount of time needed to complete a scene varied drastically depending on the scene's technical requirements.

The drastic differences in completion time can be easily lumped into two categories.
* Scenes with no new content: These scenes averaged 2 hours of work to complete.
* Scenes with new content: these scenes averaged 13 hours of work to complete. In addition to the time spent generating the new content, these stories consistently tripled or quadrupled the amount of sound mixing needed to integrate the next content.

What went well?
There were 7 scenes that I completed in less than an hour each.

What went poorly?
For some scenes, my first pass at sound mixing was often voided later when new content was integrated. I ended up re-smoothing the audio in some scenes several times.

Lessons Learned
Be wary of pickup shots and complex foley. It will effectively x5 or x6 the amount of time you'll need to spend in post production. For any given scene, consider doing all pickup shot work first before attempting audio smoothing.

What work was never accomplished?

I estimated a lot of work upfront. Having reviewed all the raw footage I spent an entire week creating JIRA tickets, with time estimates down to the resolution of 15 minutes. However, during the course of the project, I uncovered more goofs and gaffs that needed to be handled (i.e. backlog creep).

Notes that the months Jul, Aug, Sept have been intentionally omitted from the chart. Said time period represents an extended hiatus from the project.

The backlog grew from 125 tickets to 250 tickets. 175 tickets were accomplished, 75 tickets left undone.

The final product was a combination of originally planned work and work added after the project started.

72% of my time spent towards the final product was fulfilling originally planned work. (and the other 28% of the final product was spent on work discovered after the project started).

31% of initially planned work never made it into the final product (as it was supplanted by more important work discovered during the project).

The technical area most thoroughly realized was pickup shots. This makes sense, since my script relied heavily on the audience seeing information on computer screen. Major plot element would have been lost otherwise.

Scope in all other areas were scaled back between 35%-50% in order to meet the deadline.

What went well?
The total number ticket I closed was pretty close to the original estimate. Thus, I was pretty good at estimating my workload capacity over the entire project.

What went poorly?
The final product lacked polished audio. Time that would have been spent cleaning up the audio had to be spent to filming pickup shots.

Lessons Learned
The basis for my project deadline assumed 100% completion of originally planned work. For my next film project I should push out the deadline another 30% to allow for backlog creep.

A numbers game
Outside of numbers and project management I have many more insights from anecdotes and audience feedback that may provide insight into flaws in my script and on-set directing. While I'm tempted to compile a list of these qualitative observations I feel this is an area where my personal bias remains strong, that is, I don't yet have enough of a 20/20 hindsight to formulate wisdom for pre-production and production. (e.g. I don't have any strong numbers to backup 'how distracting was lack of costume changes between days ').

Otherwise, I feel the quantitative analysis of my post-production experience will serve well to more realistically forecast the life of a film project.

Wednesday, August 16, 2017

Left 4 Dead 2 Action Video

Back in the Editing Booth

After a year hiatus from video editing I'm ready jump back into another editing project. Using video game footage of Left 4 Dead 2, I plan to assemble an action video of two players (playing together in a campaign) shooting zombies in Left 4 Dead 2.

Nothing fancy; simple cross-cutting between two first-person views. Just a chance to sharpen my editing skills.

While I do have some new movie script ideas brewing, I wanted ease back into video editing before I take on my next film. This will serve as a good opportunity to research quicker editing techniques with Adobe Premiere. I know for a fact that my editing process for the film Synchronicity was sub-optimal (I'm sure any avid Premiere user would look upon my footage timelines with horror :P ).

As with my previous film project, I plan to use JIRA to as a time/work management tool.

A software tool for an arts project? Crazy, right?

I found JIRA to be nothing short of invaluable during the editing of Synchronicity. It allowed me to see the forest for the trees; and without it would have taken probably another year to complete.

I hope to get good at editing fast. If I want to continue is movie editing, fast is better than good. All this as effort to setup myself up for success in my next film. That is, I would like for my next film to take less than 3 years to complete ;)

Monday, March 20, 2017

User Agent Strings : Rules of Thumb

Gathering Server Usage Statistics via User Agent Strings

All incoming web traffic to a web server contains a "user agent", which is a string value that clients include with their web requests. The user agent string contains information about the device hardware, the device's OS, the browser type, and the browser's version. Thus, if you have access to a web server's traffic logs, you have a great way to gather statistics about your clients and the devices they use.

Unfortunately, user agent strings are not standardized. There is some consistency within a given device manufacturer/browser type, but otherwise sometimes one or more of these pieces of information are missing or are ambiguous.
When interpreting user-agent strings you need to do a little bit of investigating to reverse-lookup these pieces of information.

Recently I went through this exercise, and I developed a few rules of thumb.

Analysis Caveats - Precisely Measuring the Imprecise

  • If 80% accuracy is all you're looking for, then these rules of thumb will serve you well. 
    • These rules encompass major PCs, smart phones, and tablets. These rules do not cover miscellaneous devices such as iPods, smart TVs, and smart watches.
    • Understand the business decision you're trying to make. Is 80% acceptable?
    • These rules represent the device market in 2017. New devices are coming out constantly with potentially new combinations of user agent strings. These rules may become dated in a couple years. Be prepared to adjust the rules of thumb accordingly.
    • Some of these rules are self explanatory, some are quirky.
  • If you're looking for 100% accuracy, then beware:
    • Not easy to automate. There will some online tools that attempt to do this; I found them all to be inadequate, and I kept falling back to manual analysis.
    • Don't waste your time analyzing every unique string. Set yourself a cutoff value; aim for the big fish. For example: during my research I deemed any string with less than 100 hits per week not worth my time.
    • Any client can spoof their user agent string (e.g. bots). There is a non-trivial margin of error baked into this kind of statistics gathering.
    • Duplicate strings. Manufacturers may be too lazy (or purposefully) use the same non-unique strings for multiple devices. The resolution of your results are have some coarseness baked into them. Don't try to precisely measure the imprecise.

User Agent String : Rules of Thumb

Ignore Junk

  • The front of the user-agent string is always "Mozilla". Completely ignore it. All user-agent strings from all devices and all browsers will contain "Mozilla". This is because of historical reasons.
  • The middle part of the user-agent string is always "AppleWebKit ... like Gecko". All user-agent strings from all devices and all browsers will contain it. Completely ignore it. Again, historical reasons. 

Interpret Browser
Generally, browser info is located near the end of the string.

  • Chrome
    • Chrome on android devices will contain both strings "Chrome" and "Safari". Completely ignore the "Safari" part of the string.
    • Chrome on an iOS device will contain the string "CriOS".
    • Chrome's version is directly after the "Chrome" string
  • Safari
    • Safari on an iOS device will only make reference to "Safari" (i.e. it will make no reference to "Chrome")
    • Safari's version is directly after the "Version" string
  • Firefox
    • Contains the string "Firefox"
    • Firefox's version is directly after the "Firefox" string
  • IE
    • Will contain the string "MSIE" or "Trident"

Interpreting Device OS
Generally, device info is near the front of the string
  • Android
    • Android will contain the string "Linux; Android", or sometimes just "Android"
    • Android version is directly part of the string. Easy.
  • iOS
    • iOS will contain the string "iPhone" and "iPad"
    • iOS version is directly part of the string. Easy.

  • Windows
    • A windows OS device with "Windows NT 10.0" corresponds to a Windows 10 operating system
    • A windows OS device with "Windows NT 6.2" corresponds to a Windows 8 operating system
    • A windows OS device with "Windows NT 6.1" corresponds to a Windows 7 operating system
  • OSX
    • Will contain the string "Macintosh"

Interpreting Device Hardware
Generally, device info is near the front of the string

  • Android
    • Most android devices include a unique 5-10 digit hardware string. Google the string to see which device name it corresponds to.
    • Android smart phone will include the string "mobile safari" (even if chrome was used)
    • Android tablets will include the string "safari" (i.e. the word "mobile" will be omitted).
  • iOS
    • iPads will contain the string "iPad"
    • iPhones will contain the string "iPhone"
    • iOS devices are otherwise ambiguous and do not contain specific hardware strings. Usually you can only narrow it down to a range of devices (e.g. between iPhone 5 and iPhone 7)
      • The only hints we get are from the iOS version and the 5-6 digit string for the iOS build version of iOS. Do reverse lookups on iOS device/version charts. Sometimes the build version is only used by 1 or 2 devices.
  • OSX
    • Assumed to be a laptop or desktop
  • Windows
    • Assumed to be a laptop or desktop, unless:
    • A windows phone will contain the string "windows phone"
    • A Microsoft surface tablet will contain the string "touch"

External References used during research (out dated!)

Sunday, September 25, 2016

How to setup a Linksys WNDR3700v3 as a repeater.

Long house - Short Wifi

Living in a typical new orleans 'shotgun-layout' house, extending wifi to the back of the of the house has been an on going issue. Unfortunately the cable hook up is at the front of the house, and short of running 65' of coax, we needed something to boost wifi to the back of the house.

Our first solution involved an off the shelf wifi "extender", which we placed halfway between the front and back of the house, but our coverage remains spotty. Some of my peers recommended ditching the extended and using a router to boost wifi as a "repeater". I had an extra router layout around and, with a little bit of dark sorcery, I was able to setup my older router into a capable wifi booster. Specifically, I was able to successfully install DD-WRT firmware onto my router, and utilize its repeater capabilities.

(pic of both units)

Linksys WNDR3700v3

This article will be specific to the Linksys WNDR3700v3. I have written some steps a bit generically to potentially help those with a different routers; but unfortunately the steps involved vary so much depending on the specific router model and even down to which chip set the manufacture used. Results may vary.

What you will need:
-A Linksys WNDR3700v3 (this will be your secondary router)
-Another router (i.e. your host router) with internet.
-A laptop/desktop with an ethernet port
-An ethernet cable
-2 hours of your time
-Some patience (fail 3 times, succeed the fouth time)
-(optional) A second device with wifi capabilities. This will be handy to have a phone etc. to browse the net with for instructions while your laptop/desktop is tied up installing firmware on the router.
And lastly, at risk of sounding incompetent:
-the ability to sniff out when these instructions deviate from your situation. (In the end I needed mix-and-match 5 different walk-thoughs before I cobble together instructions for my hardware). This by no means a comprehensive guide; good luck :)

What you don't need:
-Physical access to the host router.
That's right, if all goes well, the host router will be none-the-wiser that a repeater has been setup. All setup is done with the secondary router. You could potentially setup a repeater off of your neighbor's wifi (so long as you know their wifi password) ;)


When dealing with routers I find that terminology is the biggest barrier. I'll make a small attempt to de-obfuscate. Please read this section or you will regret it.

"Repeater" vs. "Extender"
Manufactures are inconsistent or use misleading branding. All in all the two terms are interchangable. Either way, the concept is the same. A 'secondary router' will connect to the 'host router' via wifi. Devices connecting to either the host or secondary router via wifi will have internet access.
For this article I'll be using these terms in the following manner
* Extender - an off the shelf device intended solely for boosting signal. I won't talk about extenders in this article.
* Repeater - a normal router which has been configured to boost signal.

"Repeater Mode" vs. "Repeater Bridge Mode"
The folks over at DD-WFT provide the following definitions:
* Repeater Mode - This mode will extend wifi internet access to both routers, but the networks created by each router will exist on a separate subnet. The distinction here is that devices connected to the host router cannot communicate directly to devices on the secondary router. Effectively, this only impact you if you are LAN gaming or file sharing; otherwise this mode probably suits your needs. This is mode is easier to setup, and this is the mode I opted to use.
* Repeater Bridge Mode - This mode accomplishes signal boost, and both routers will exist on the same subnet (i.e. devices connected to different routers will behave as if all devices were connected to the same router). This mode is a bit more difficult to setup, and is not strictly covered in this article.
* Access Point - This is the default configuration for routers. This mode does no do any repeating.

While Repeater Bridge Mode is an ideal solution, it requires that your host router and secondary router have matching chip sets, and that both routers have supported DD-WRT firmware. In my instance, only my secondary router had supported DD-WRT firmware, so I fell back to using Repeater Mode. At the end of the day it accomplished my primary goal (getting better wifi coverage for my roommates); no biggie.

"Client" and "Client Bridge"
Without digging too deep into these modes, they are intended for people who want to run an ethernet cable between their routers, or for people who want to restrict client to connect to their routers via an ethernet cable (i.e. clients cannot connect to their router via wifi!). These setups only make sense for an office environment that has particular security restrictions. Most likely you'll want to stear clear of these modes. Just remember that "Client Bridge" is not the same as "Repeater Bridge".

Firmware from DD-WRT

DD-WRT is a community of people that make free opensource firmware, and is often cited as the best solution for most people (citation needed). Unfortunately their wikis are a bit rough around the edges, and sometimes even constradictory. It appears community support has wanned over the years. Nonetheless I had good luck with DD-WRT, at the very least will point you in the right direction.

If DD-WRT fails for you, you'll need to confide in an alternative source ( ).

As with any firmware shinanigans there a chance you can brick your router. How big a chance? I don't know. But you weren't using that old router for anything anyways, right? What do you have to lose! (Even if you do brick your router, there are large sections of the DD-WRT wikis dedicated to recovering a bricker router). You can do it!

(create image: brick with wifi antennas)

and without futher ado:

How to setup a Linksys WNDR3700v3 as a repeater.

The firmwawre that Linksys WNDR3700v3 ships with does not support any repeater modes. Especially for router that are 5-10 years old, there's a good change your router does not support a repeater mode.

1) Give your roomates a heads up that your messing around with the routers.
If all goes well, you won't even touch the host router, and they can go on watching netflix without interruption. You will only be touching the secondary router. Nonetheless hope for the best, set expectations for the worst.

2) Download your secondary router's manual.
Google it. Read it. Confirm that it doesn't already ship with a repeater mode. This may sound like an obvious step, I only include it beware of terminology soup. (They might call it "bridge mode" or something stupid).

3) Log into your secondary router's web interface.
Any device connected to a router can alter the router's configuration, so long as you know the address, username, and password. Unless you've explictly setup new values, username and password will still be the manufactures default. All routers have a default password. For Linksys WNDR3700 the default info is:
username: admin
password: password
Just open your web browser (e.g. chrome, safari, etc.) and type the address as the URL.

4) Update manufacture's firmware.
It's possible the manufactures has an updated firmware with what you need. Updating the manufactures firmware should be a one-click operation. With in the router's web interface, find a button to check for updates. Please double check and you may be able to skip this whole thing.
As of the date of this post the most recent Linksys firmware (v1.0.0.38_1.0.3.1) "Genie" does not support repeater modes.

5) Verify DD-WRT has a supported firmware for your router.
Pay attention to the exact 'version' of your device. I.e. a WNDR3700v2 is way different than a WNDR3700v3.
Of the 3 routers I own, only 1 was supported. If the router you picked to be your secondary router is not supported, but your host router is supported. Swap them out, and proceed with the other router as your secondary. Or maybe trade routers with your friends.

6) From the DD-WRT website, download the associated .chk file. Normally installing firmware is a 2 step process: install the .chk (aka 'the flash' or 'trailing build'), then install the .bin. (The .chk is a base firmware, and the .bin is a more advanced and updated firmware). I found that the .chk contained both 'Repeater Mode' and 'Repeater Bridge Mode', thus I skipped all instructions to install the .bin. If you need your router's USB/external harddrive support, you'll probably need to install the .bin.

Ok, you're finally ready to start messing with the firmware. Get excited!

7) Connect your laptop to the router via ethernet cable.
-During the course of these instructions, the router's wifi will be severed a few times during power cycles and reconfigurations. Connecting via an ethernet cable is *probably* mandatory; otherwise you risk firmware not being applied correctly. I hope you don't own a mac book air.

(create an image of a mac book air dongle with $999)

(optional) And just to be safe turn off your wifi adapter. This will ensure that all your browser's communications are going over the ethernet cable. This will reduce confusion and false positives in later steps. I know I've screamed Eureka a couple of times, only to realize I was connected to the wrong router.

8) Give your laptop a static IP on the same subnet as the secondary router.
At the moment your secondary router is probably on the subnet 192.168.1.X; thus set a manual static (i.e. non-changing) IP such as

(OSX pic)

9) Perform the voodoo that is the 30-30-30 Reset on the router. I had a stopwatch handy, otherwise counting to 30 gets really old really fast.

10) Log into your router's web interface (e.g.
If you have the latest firmware (v1.0.0.38_1.0.3.1) "Genie", you will be propted to answer one of three choices. This is good; this is an indication that the 30/30/30 reset was successful. At any point during the remaining instructions if you mess up, you can alway re-do the 30/30/30 and re-start from this step.

11) Install the .chk
Select the choice “I wanna do it myself”; click OK for the "... are you sure?" dialogs.
Click “Administration” button (on left of the screen) > click ‘router update’
Upload the .chk
It will warn you about installing an old version. Click OK.

(pic; blur sensitive information)

12) More voodoo
The loading bar will take about a minute to finish. After it has finished, wait an additional 5 minutes. Then perform another 30-30-30 reset.

13) Log back into the secondary router's web interface (e.g.
You should see a new "" interface.
These remaining instructions assume the following version is installed:
DD-WRT v24 SP2

14) Specify the host router's details.
Moment of truth.
Go to Wireless > Basic Settings
Here you should see 2 sections for Wireless Physical Interfaces, and 1 empty section for "Virtual Interfaces"

Pick one of the physician interfaces to use. The physical interfaces run on different frequencies; pick the freq that your devices most commonly connect to (probably the 2.4 GHz). You're welcome to try and apply these setting to both physical interfaces; I've only tried applying the settings to one interface.

For "Wireless mode" select "Repeater"
-If you do not see a value for Repeater, uh oh. You may need to install that .bin afterall; or your router might have a funky chip set. You may need to experiment with installing other versions of the DD-WRT firmware. Good luck.

For "Wireless Network Mode" select the same value as your host router. 90% odds are this value should be "Mixed". Otherwise, if you have web interace access to the host router, double check.

For "Wireless Network Name (SSID)" set to the SSID of the host network.

Leave "Sensitivity Range" as is.
Leave "Network Configuration" as "Bridged".

(pic; blur my mac address)

15) Add a virtual interface.
Click "Add" button
Populate "Virtual Network Name (SSID)". This will be the name of the wifi network that devices will connect to. This SSID cannot be the same as the host router's SSID.
Leave the other attributes as is.

At the bottom of the page, click the save button. (Do not click the Apply button yet.)

16) Specify passwords
Under the Wireless > Wireless Security tab
For the interface you selected in step 14:
For "Security Mode" select "WPA2 Personal"
For "WPA Shared Key" input the password for the Host router
Both the host router and the secondary router should have the same wifi password, and also the same security mode. This guide assumes the Host router has WPA Personal; otherwise, if you have access to the host router's web interface, log in and double check.
Repeat this for the virtual interface.

At the bottom of the page, click the save button. (Do not click the Apply button yet.)

17) Set the secondary routers on a different subnet.
By default, the virtual interface will be on the same subnet as the host router; ensure the virtual interface is on a different subnet.
Go to Setup > Basic Setup > Network Setup
For local IP address change the subnet (e.g.

18) Ease dynamic packet filtering firewall restrictions.
We'll remove some normal firewall restrictions, (as was recommended by one of the guides). If you know enough about firewalls, you may choose to leave these on. Otherwise:
Go to Security tab
- Uncheck "Block Anonymous LAN Requests"
- Leave "Filter Multicast" checked
- Uncheck "Filter WAN NAT Redirection"
- Uncheck "Filter IDENT (Port 113)"
Then select "SPI firewall" disabled. (It's important to do this last)

At the bottom of the page, click save button.
Now click Apply.

19) Verify secondary router has internet
If you have another device handy, connect to the secondary router's wifi, and verify you have internet connect.
If you are having issues, there are some additional tips at this link:

20) Clean up; get your laptop back to normal
* Re-enable your laptop's wifi adapter
* Re-set your laptop's IP to DHCP

21) Enjoy!

So, at the end of the day I replaced my out of the box extender with a router configured to be repeater. Was this time well spent? Did I actually see any performance improvements? Initial signs say yes. Though I don't have any before/after wifi heat maps to back it up, I'll be able to report back with my measurements in 'number of roommate complains per week'. Or, if push comes to shove, I can leap frog even further, and boost the secondary router's range with the new collecting dust extender.

Guides I referenced: