WordPress FLV plugin WP OS FLV slow

Over the past few weeks, I’ve been designing a basic site (in WordPress) for a new client. This client needs some embedded FLVs on the site, and doesn’t want them (for good reason) to be directly linked to YouTube. As such, and seeing as I didn’t want to make the client write the HTML for embedding a flash video, I installed a very simple FLV plugin called WP OS FLV.

The plugin worked exactly as I had hoped it would, by cleanly showing the FLV with just a few basic options. However, I noticed that the pages with FLVs embedded in them using the plugin were significantly slower to load than were pages without FLVs. Doing some fun experimentation with cURL, I found that those pages had some external calls on them. Hmmmmmm, now what would the plugin need from an external site? Doing a little more digging, I found the following line hardcoded twice in the plugin’s wposflv.php file:

<param name="movie" value="http://flv-player.net/medias/player_flv_maxi.swf" />

That line means that if the site flv-player.net is down or slow, the page with the FLV plugin on your blog will also be slow. In order to fix this problem, you simply need to download the player_flv_maxi.swf file from that site, upload it somewhere on your server, and edit the line to call the location on your server instead. For instance, if your site is my-site.com, and you put the SWF file in a directory called static, you would change the absolute URL to:

<param name="movie" value="http://my-site.com/static/player_flv_maxi.swf" />

If you too were having problems with this plugin being a bit slow, I hope that this suggestion helps!


Zoom 5341J cable modem

After moving back to the midwest United States, I was immediately reminded of the frustrations of dealing with the primary cable internet provider–Charter Communications. They offer fairly good speeds, and when considering the price, the performance-to-cost ratio is outstanding. However, the reliability of the service leaves a lot to be desired.

One of the primary problems when I lived here before was the really poor modems (and corresponding Charter-infected firmware) that they provided. Never fear, though, as I came back with my own modem… or so I thought. Apparently in June of 2012, Charter announced that customers can no longer use their own modems. So, with my service came a free lease of a Cisco DPC3010. Not a bad modem, barring the firmware that Charter has loaded onto it (which eliminates the administrative login credentials, and thus, one can’t look at the logs). Though there is a user account for logging in (Username: chtruser Password: charter), the administrative functionality has been removed. The modem, however, (and again, likely the fault of the Charter firmware, and not the Cisco modem itself) refused to channel bond on downstream (upstream bonding is not yet offered). As a result, my downstream speeds were abysmal by comparison to the rated speeds.

After arguing with the customer service team at Charter, I finally convinced them to provision my modem. I have a Zoom 5341J modem, which is a nice, affordable modem that supports up to 8 bonded downstream channels and up to 4 bonded upstream channels. Within its administrative interface, it also features information regarding the lock status, modulation, channel ID, frequency, power, SNR, and (un)correctable errors. The modem also has a hidden menu which can only be accessed by going directly to the URL:


replacing $MODEM_IP with the actual IP of the modem (which by default is, resulting in a full URL of This page shows all of the events in in the SNMP log, which is highly valuable information if you want to actively monitor your network status.

In any case, the new modem with the stock firmware (unmodified by Charter) is working beautifully with four bonded downstream channels (the maximum for my package). I strongly recommend the modem for its reliability and price point.


Stalled scp transfers due to OpenSSH regression

Recently, I started having troubles with transferring files to my servers via scp. Typically, I would just issue the scp command without any options at all (regarding rate limiting, et cetera). However, I started having a problem where it would only transfer small files–ones that were <50KB. Anything larger than that would start just fine, but the transfer would stop quite abruptly, and scp would report that it had stalled. I also saw this problem when trying to upload via sftp. However, using rsync to transfer the files would work without a problem.

After digging around for quite some time, consulting multiple posts regarding the issue, and setting every option imaginable within scp, I had all but given up. I firstly eliminated that there was a problem with my local machine by trying from a couple other machines of mine. I secondly eliminated my home networking equipment by trying from another network, and via my mobile. At that point, I knew that the problem had to be with my server, or with one of the hops along the way (more likely the former than the latter). So, I investigated settings on my server, but there weren't many clues to utilise; nothing in /var/log/messages or /var/log/authlog. I started tcpdumps but couldn't see any indication of WHY the problem was occurring; just that it WAS occurring.

Eventually I started looking through Gentoo's bugtracker, and stumbled across bug #414401. Though the original bug wasn't about an scp problem specifically, the first comment reflected the same issue that I was experiencing. It seems that the problem was related to a buggy HPN patch in the latest version of OpenSSH. I reverted to the previous patch and the problem was gone.

Oh the trials and tribulations of problem-solving in the software world. ;) Hopefully this post will help someone solve a similar problem.