This marks the 1-year anniversary since ditching DirecTV for the Sony SMP-N200 streaming media player.
The device features HDMI, optical, and RCA jacks, as well as an ethernet port.
So far, the experience has been great! Rather than paying around $900 a year for satellite, I'm paying just what I'd been paying before for internet, around $40 monthly, a decent compromise.
The interface of the player is very similar to that of Sony's Bravia series of TVs.
The remote enables navigation to the various options and settings. A great thing about this little black box is that you can browse the web, grabbing either streaming video from YouTube and elsewhere, or just general browsing. However, one trick is to use a smartphone app, Sony Media Remote, so that you gain the benefit of a keyboard; trying to "type" using the Sony's remote is an exercise in aggravation, to say the least.
For over-the-air TV, a Winegard antenna hung up near the ceiling of the living room plus a signal amplifier has managed to pull in 8 stations, six broadcast in my immediate area, and two more from towers about 40 miles away.
With the Sony SMP-N200 I can also stream downloaded video over my home's wireless network. To do this, I first needed to enable Homegroup on my Windows 7 desktop PC, and then I installed Nero MediaHome to act as a server for the Sony. Most any popular encoding format (AVI, MPG, MKV, WMV, and more) can stream from my computer to my TV with very little effort.
All in all, aside from the clunky remote, I'd give it a solid 4 out of 5 stars for the money I've saved thus far over cable or satellite.
Friday, May 10, 2013
Tuesday, May 7, 2013
The "GenerateResource" Task Failed Unexpectedly
Shortly after setting up a RAM disk using the freeware version of Dataram RAMDisk to see whether Visual Studio 2010 might compile a huge solution faster, I began getting the following errors after relocating the system's temp files to the root of the RAM drive:
I dug around and found numerous references to existing bug reports and a few workarounds. I tried unsetting the readonly file system attribute in my solution folder, setting the GenerateResourceNeverLockTypeAssemblies property in my project file to true or false to downgrade some security parameters, but ultimately it was the top answer here that did the trick.
I had set the environment variables for the RAM drive initially to just R:\, referencing the root of the drive. Apparently VS 2010 doesn't like this, so I simply created a new folder on my ram disk named TEMP, and then updated the environment variables accordingly:
Just to rule it out, and also because I hadn't rebooted Windows in a while, I also opened Control Panel => Programs and Features, and performed a Repair on Microsoft .NET Framework 4 Client Profile just in case the framework files might've gotten corrupted somehow, and then restarted.
Problem solved! Now on to see whether Joseph Fluckiger's experimentation which returned lukewarm results on performance of building to a RAM disk holds water for a solution with, say, dozens of projects.
The "GenerateResource" task failed unexpectedly.
System.TypeInitializationException: The type initializer for 'Microsoft.Build.Utilities.FileTracker' threw an exception. ---> System.NullReferenceException: Object reference not set to an instance of an object.
I dug around and found numerous references to existing bug reports and a few workarounds. I tried unsetting the readonly file system attribute in my solution folder, setting the GenerateResourceNeverLockTypeAssemblies property in my project file to true or false to downgrade some security parameters, but ultimately it was the top answer here that did the trick.
I had set the environment variables for the RAM drive initially to just R:\, referencing the root of the drive. Apparently VS 2010 doesn't like this, so I simply created a new folder on my ram disk named TEMP, and then updated the environment variables accordingly:
Just to rule it out, and also because I hadn't rebooted Windows in a while, I also opened Control Panel => Programs and Features, and performed a Repair on Microsoft .NET Framework 4 Client Profile just in case the framework files might've gotten corrupted somehow, and then restarted.
Problem solved! Now on to see whether Joseph Fluckiger's experimentation which returned lukewarm results on performance of building to a RAM disk holds water for a solution with, say, dozens of projects.
Labels:
C#,
RAMdisk,
troubleshooting,
Visual Studio 2010,
windows 7
Wednesday, February 20, 2013
Left and Right Double Quotation Marks
Often I find myself wanting to use left and right double quotation marks rather than the generic ones.
Especially if you happen to be quoting someone, it adds a touch of class to use these rather than their boring unicode counterparts. This site outlines the differences between the two, and for convenience I'm posting each here so that either one can be easily copied and pasted:
Below is as an animated GIF showing each of the left and right double quotation marks as well as the plain old unicode ones in CharMap, and keystrokes you can use to type the former if you're so inclined:
Especially if you happen to be quoting someone, it adds a touch of class to use these rather than their boring unicode counterparts. This site outlines the differences between the two, and for convenience I'm posting each here so that either one can be easily copied and pasted:
“
Left quotation mark. Hold down ALT and hit 0147 on your numeric keypad.
”
Right quotation mark. Hold down ALT and hit 0148 on your numeric keypad.
Below is as an animated GIF showing each of the left and right double quotation marks as well as the plain old unicode ones in CharMap, and keystrokes you can use to type the former if you're so inclined:
![]() |
| A handy animated GIF outlining them all. |
Labels:
ASCII,
CharMap,
double quotation marks,
quotes,
Unicode
Saturday, February 16, 2013
Block Reddit Ads, Part Deux
In my previous post I outlined a method to block Reddit ads.
It worked, until I tried hitting Reddit early this morning.
It appears that the ad structure is slightly different, now the following element hiding rule in the Element Hiding Helper of AdBlock Plus should do the trick:
This ought to work until they decide to change up their site structure once again.
UPDATE: Apparently, the developer of AdBlock Plus has decreed that Reddit ads will from this point forward be whitelisted, stating that Reddit ads meet their 'acceptable ads' guidelines, necessitating custom rules like I describe above. To me, this is a bad idea, especially since even bigtime advertisers like Yahoo, Fox, and Google have inadvertently helped malware procreate through ads.
It worked, until I tried hitting Reddit early this morning.
It appears that the ad structure is slightly different, now the following element hiding rule in the Element Hiding Helper of AdBlock Plus should do the trick:
reddit.com###siteTable_organic.organic-listing
This ought to work until they decide to change up their site structure once again.
UPDATE: Apparently, the developer of AdBlock Plus has decreed that Reddit ads will from this point forward be whitelisted, stating that Reddit ads meet their 'acceptable ads' guidelines, necessitating custom rules like I describe above. To me, this is a bad idea, especially since even bigtime advertisers like Yahoo, Fox, and Google have inadvertently helped malware procreate through ads.
Labels:
adblock plus,
advertising,
block ads,
element,
firefox,
reddit
Friday, February 15, 2013
Block Reddit Ads
Reddit recently introduced an update to their ads which eludes AdBlock Plus.
Instead of a simple element ID denoted as a sponsored link, their page uniquely identifies it according to a link to the comments for a given ad posting. Ads annoy me, and as my previous post on blocking Reddit ads attests, even their minimal advertising is an unwanted distraction.
However, using the Element Hiding Helper, it's trivial to block the new ad scheme. If you're already familiar with hiding elements, all you need to do is add an element hiding rule like this:
If you want a more detailed procedure which might help you block other unwanted web content, read on.
In Firefox, tap the ALT key to display the menu, then click Tools => AdBlock Plus => Select an element to hide (or alternatively hit CTRL-SHIFT-F3). This brings up the element selection dialog that lets you pick and choose items on the web page to hide.
Now a red selection box will outline and identify elements of the page as your mouse cursor hovers over them. If you hover over the sponsored link area, you should see something like this:
Note the entire ad post is surrounded, with a tag in the lower-left indicating the post is within a DIV element. Click on the tag for this area, and you'll open the Compose element hiding rule dialog.
This is the Basic view, but we need to go deeper, so click on the Advanced view button.
By default, when you clicked to select the ad, the element hider chose that specific DIV element. However, blocking this won't do, as each ad will have a unique identifier (in this case, 17aahm) which will foil the filter.
To get around this, first click on the checkbox beside the option that begins "class: thing id-..." to uncheck it, and then click on the DIV in the list which is the parent to this one, just above the default selection. Then, click the checkbox beside siteTable_promoted so that it's checked, and then click the Add element hiding rule button.

Now the ad should be hidden, either immediately or after your next refresh of Reddit's page.
Instead of a simple element ID denoted as a sponsored link, their page uniquely identifies it according to a link to the comments for a given ad posting. Ads annoy me, and as my previous post on blocking Reddit ads attests, even their minimal advertising is an unwanted distraction.
However, using the Element Hiding Helper, it's trivial to block the new ad scheme. If you're already familiar with hiding elements, all you need to do is add an element hiding rule like this:
reddit.com###siteTable_promoted > *
If you want a more detailed procedure which might help you block other unwanted web content, read on.
In Firefox, tap the ALT key to display the menu, then click Tools => AdBlock Plus => Select an element to hide (or alternatively hit CTRL-SHIFT-F3). This brings up the element selection dialog that lets you pick and choose items on the web page to hide.
Now a red selection box will outline and identify elements of the page as your mouse cursor hovers over them. If you hover over the sponsored link area, you should see something like this:
Note the entire ad post is surrounded, with a tag in the lower-left indicating the post is within a DIV element. Click on the tag for this area, and you'll open the Compose element hiding rule dialog.
This is the Basic view, but we need to go deeper, so click on the Advanced view button.
By default, when you clicked to select the ad, the element hider chose that specific DIV element. However, blocking this won't do, as each ad will have a unique identifier (in this case, 17aahm) which will foil the filter.
To get around this, first click on the checkbox beside the option that begins "class: thing id-..." to uncheck it, and then click on the DIV in the list which is the parent to this one, just above the default selection. Then, click the checkbox beside siteTable_promoted so that it's checked, and then click the Add element hiding rule button.
Now the ad should be hidden, either immediately or after your next refresh of Reddit's page.
Labels:
adblock plus,
advertising,
block ads,
element,
firefox,
reddit
Tuesday, February 5, 2013
Foscam FI9821 Wireless Workaround
In my abortive attempt to review the Foscam FI9821, I mentioned the complete inability for the camera to find let alone connect to mine nor any wireless networks in my neighborhood. This precluded my ability (and desire) to review the camera any further.
Now, however, the camera sees and connects successfully to my wireless network.
After my issues with the late Foscam FI9820 with its poor daytime image quality and anemic firmware, I already experienced RMA hell and didn't want to go through it again. Thus, being handy with electronics, I decided to try an off the wall suggestion found in Foscam's support forum.
Note that the following steps may VOID the manufacturer warranty.
1. Power off the FI9821 and disconnect all cables.
2. Remove the rubber feet on the underside of the camera, this should reveal a couple of screws. Remove them. There are also two screws located on the underside beneath one round laser QA label and another beneath a round paper label. Remove the labels and then the screws as well.
3. Carefully remove the bottom of the camera and follow the wire that runs from behind where the antenna screws in to the camera to a metal "post" on the circuitboard, similar to the one depicted here:
4. Remove the connector, then reconnect it, and as you do so wiggle it, just a little bit.
5. Reverse the steps above and reassemble the camera.
6. Connect the power and ethernet cables, and proceed to configure the camera to connect to your wireless network if you haven't already. Be sure to save the settings!
7. From the camera's web interface, on the Wireless Settings screen click the Scan button. Your wireless network should appear similarly as shown below:
8. Unplug the ethernet cable and wait a minute or so, then try browsing to the camera's IP address. With luck, the camera will have switched to wireless mode and you should then be connected wirelessly, at last!
Why does this work?? It could be due to insulation which is sometimes used to coat electronics, such as that used to coat thin wire that's used for coils. Perhaps in the manufacturing process, the post got sprayed with insulation by accident, leading to a poor connection with the antenna wire connector. Wiggling the connector around on the post may've scraped away any insulation, leading to a solid connection.
Regardless, releasing a $150+ camera so hurriedly with a problem like this, one that some simple quality assurance practices could've caught and fixed, is ridiculous. Although again I applaud Foscam for their responsive customer service and providing me with a free upgrade to the newest model of their camera, shame on them for not catching this frustrating little glitch!
I will review the camera in earnest in the near future, now that its wireless connectivity, a core feature in my eyes, is operational at last.
Now, however, the camera sees and connects successfully to my wireless network.
After my issues with the late Foscam FI9820 with its poor daytime image quality and anemic firmware, I already experienced RMA hell and didn't want to go through it again. Thus, being handy with electronics, I decided to try an off the wall suggestion found in Foscam's support forum.
Note that the following steps may VOID the manufacturer warranty.
1. Power off the FI9821 and disconnect all cables.
2. Remove the rubber feet on the underside of the camera, this should reveal a couple of screws. Remove them. There are also two screws located on the underside beneath one round laser QA label and another beneath a round paper label. Remove the labels and then the screws as well.
3. Carefully remove the bottom of the camera and follow the wire that runs from behind where the antenna screws in to the camera to a metal "post" on the circuitboard, similar to the one depicted here:
4. Remove the connector, then reconnect it, and as you do so wiggle it, just a little bit.
5. Reverse the steps above and reassemble the camera.
6. Connect the power and ethernet cables, and proceed to configure the camera to connect to your wireless network if you haven't already. Be sure to save the settings!
7. From the camera's web interface, on the Wireless Settings screen click the Scan button. Your wireless network should appear similarly as shown below:
8. Unplug the ethernet cable and wait a minute or so, then try browsing to the camera's IP address. With luck, the camera will have switched to wireless mode and you should then be connected wirelessly, at last!
Why does this work?? It could be due to insulation which is sometimes used to coat electronics, such as that used to coat thin wire that's used for coils. Perhaps in the manufacturing process, the post got sprayed with insulation by accident, leading to a poor connection with the antenna wire connector. Wiggling the connector around on the post may've scraped away any insulation, leading to a solid connection.
Regardless, releasing a $150+ camera so hurriedly with a problem like this, one that some simple quality assurance practices could've caught and fixed, is ridiculous. Although again I applaud Foscam for their responsive customer service and providing me with a free upgrade to the newest model of their camera, shame on them for not catching this frustrating little glitch!
I will review the camera in earnest in the near future, now that its wireless connectivity, a core feature in my eyes, is operational at last.
Labels:
FI9821,
Foscam,
troubleshooting,
wireless,
workaround
Saturday, February 2, 2013
Foscam FI9821 Review
UPDATE: Hard to believe, but a tip on Foscam's support forum from some random user turned out to be more helpful than Foscam.
A user on the forums reported that they got their wireless functional by simply popping open the camera, and then adjusting the wire connected to the camera's antenna.
Lo and behold, upon opening up the camera (and surely voiding its warranty, but no matter at this point as far as I'm concerned) and then removing the wire from its little post, reattaching it, then grinding it around the post back and forth a few times, suddenly the camera is able to detect my wireless network!
Wow.
Foscam should enclose instructions telling their users how to crack the camera open and do what their QA department should've done and ensure the connection between the antenna and their camera is solid.
Or, even better, Foscam should do this testing prior to selling a $150+ camera to its customers!
___
I am pleased to be able to review the recently released Foscam FI9821 IP camera.
Perhaps in part due to my rather frank review of their FI9820 model, Foscam has just recently premiered the FI9821, with similar capabilities as the FI9820 but, I hope, fewer outright bugs than the previous model.
To review, the Foscam FI9820 had the following disagreeable problems:
I must give credit to Foscam's tech support. Courteous and respectful to the last, even when I threatened to contact my bank to dispute the credit card transactions associated with my purchase of two FI9820 cameras, they fulfilled an RMA request and provided me with a FREE upgrade to two FI9821 cameras at no cost other than for shipping the old cameras to their Houston, Texas facility.
Now, on to the review of Foscam's newest camera.
The cameras each arrived carefully packaged via USPS Priority Mail. My first minor disappointment came in the form of the AC adapter, its cord is still a mere 3 feet in length, less than I'd like.
I plugged in the power and fired up the camera, then assuming it would utilize DHCP to acquire a network address from my home router, I scanned my network using the handy free utility, Advanced IP Scanner, to ascertain its IP address so I could point my browser to it and configure it. No joy, the MAC address of the camera didn't appear to be detected by the software.
I uncharacteristically decided to consult the manual, which instructed me to pop the included CD into my drive and run the IP Camera Tool utility to help detect the camera on my network. Upon doing so, the camera was indeed detected, but strangely its TCP port had been set to 88 at the factory rather than the industry-standard 80 for http traffic.
Okay.
I accessed the camera's interface, and promptly changed the port to the standard port 80. So far, so good.
Next I tried to configure the wireless network settings on the camera. The interface isn't terribly helpful, for one, it seems Foscam expects your wireless network's SSID to be broadcast rather than hidden. I prefer to keep my SSID hidden to minimize the chance some passerby might see it and gain access, but as was the case with the FI9820, this new model wants your SSID to be broadcast.
Despite setting my SSID to be broadcast, this camera seems to NOT want to connect to my wireless network. This as of the most recent 1.1.1.10 firmware update.
I simply cannot review this camera any further until I'm able to connect it to my wireless network. I've contacted Foscam support, hopefully they'll address this issue sooner than later.
A user on the forums reported that they got their wireless functional by simply popping open the camera, and then adjusting the wire connected to the camera's antenna.
Lo and behold, upon opening up the camera (and surely voiding its warranty, but no matter at this point as far as I'm concerned) and then removing the wire from its little post, reattaching it, then grinding it around the post back and forth a few times, suddenly the camera is able to detect my wireless network!
Wow.
Foscam should enclose instructions telling their users how to crack the camera open and do what their QA department should've done and ensure the connection between the antenna and their camera is solid.
Or, even better, Foscam should do this testing prior to selling a $150+ camera to its customers!
___
I am pleased to be able to review the recently released Foscam FI9821 IP camera.
Perhaps in part due to my rather frank review of their FI9820 model, Foscam has just recently premiered the FI9821, with similar capabilities as the FI9820 but, I hope, fewer outright bugs than the previous model.
To review, the Foscam FI9820 had the following disagreeable problems:
- Poor daylight video quality.
- Inability to connect to a wireless WPA2 network that uses a complex passphrase with any non-alphanumeric characters.
- As reported by Foscam, no further firmware support that might resolve these and any future issues.
I must give credit to Foscam's tech support. Courteous and respectful to the last, even when I threatened to contact my bank to dispute the credit card transactions associated with my purchase of two FI9820 cameras, they fulfilled an RMA request and provided me with a FREE upgrade to two FI9821 cameras at no cost other than for shipping the old cameras to their Houston, Texas facility.
Now, on to the review of Foscam's newest camera.
The cameras each arrived carefully packaged via USPS Priority Mail. My first minor disappointment came in the form of the AC adapter, its cord is still a mere 3 feet in length, less than I'd like.
I plugged in the power and fired up the camera, then assuming it would utilize DHCP to acquire a network address from my home router, I scanned my network using the handy free utility, Advanced IP Scanner, to ascertain its IP address so I could point my browser to it and configure it. No joy, the MAC address of the camera didn't appear to be detected by the software.
I uncharacteristically decided to consult the manual, which instructed me to pop the included CD into my drive and run the IP Camera Tool utility to help detect the camera on my network. Upon doing so, the camera was indeed detected, but strangely its TCP port had been set to 88 at the factory rather than the industry-standard 80 for http traffic.
Okay.
I accessed the camera's interface, and promptly changed the port to the standard port 80. So far, so good.
Next I tried to configure the wireless network settings on the camera. The interface isn't terribly helpful, for one, it seems Foscam expects your wireless network's SSID to be broadcast rather than hidden. I prefer to keep my SSID hidden to minimize the chance some passerby might see it and gain access, but as was the case with the FI9820, this new model wants your SSID to be broadcast.
Despite setting my SSID to be broadcast, this camera seems to NOT want to connect to my wireless network. This as of the most recent 1.1.1.10 firmware update.
I simply cannot review this camera any further until I'm able to connect it to my wireless network. I've contacted Foscam support, hopefully they'll address this issue sooner than later.
Monday, December 24, 2012
Acronis True Image Backup Fails
When trying to do a disk and partition backup on Acronis True Image Home 2012 build 7133 to an external USB drive, the backup failed repeatedly with a read error.
Upon contacting Acronis support, at first I got a suggestion that the error had been "fixed" in the latest version, and that I should upgrade to the 2013 version of the software. Conveniently, the support tech I'd been corresponding with provided me with an affiliate link to purchase the new version.
It seemed rather odd that a support tech would provide an affiliate link to purchase an upgraded version of the product rather than help with the customer's current version. I decided, instead, to press the issue and fork over $9.99 for a paid support incident. My case then got reassigned to someone who seemed to be more on the ball, and asked me to take some basic troubleshooting steps, including scanning my C: drive, which happens to be an Intel SSD, with the chkdsk utility, revealed so issues whatsoever.
Subsequent back and forth with the support technician proved largely unhelpful until they asked me to try backing up a single file or folder rather than a whole partition. I then tried backing up the My Documents folder, and it failed quickly with an error stating the system couldn't find the path R:\TEMP, which happened to be associated with a RAM drive I'd had set up until recently.
I remembered that in the time between making my last successful backup using Acronis, I'd uninstalled QSoft RAMDisk, a utility which enables you to use a portion of your system memory as a very fast RAM drive. Trying to create a backup with Acronis since the RAM drive had been uninstalled proved fruitless because Acronis seemingly balked at not being able to find the RAM drive registered with Windows any longer.
Serendipitously, the developer of the RAM drive software released an updated build of their software earlier this month, so I decided to reinstall it and give it a try. I installed the software, then set up a RAM drive with the same drive letter as I'd originally used.
Upon reinstalling the RAM drive and rebooting, the backup proceeded successfully.
The moral of the story appears to be, if you happened to have a RAM drive installed on your system at some point prior to having Acronis installed, you'd best make sure the RAM drive is existant so that Acronis won't complain and decide to no longer complete your backups.
Upon contacting Acronis support, at first I got a suggestion that the error had been "fixed" in the latest version, and that I should upgrade to the 2013 version of the software. Conveniently, the support tech I'd been corresponding with provided me with an affiliate link to purchase the new version.
It seemed rather odd that a support tech would provide an affiliate link to purchase an upgraded version of the product rather than help with the customer's current version. I decided, instead, to press the issue and fork over $9.99 for a paid support incident. My case then got reassigned to someone who seemed to be more on the ball, and asked me to take some basic troubleshooting steps, including scanning my C: drive, which happens to be an Intel SSD, with the chkdsk utility, revealed so issues whatsoever.
Subsequent back and forth with the support technician proved largely unhelpful until they asked me to try backing up a single file or folder rather than a whole partition. I then tried backing up the My Documents folder, and it failed quickly with an error stating the system couldn't find the path R:\TEMP, which happened to be associated with a RAM drive I'd had set up until recently.
I remembered that in the time between making my last successful backup using Acronis, I'd uninstalled QSoft RAMDisk, a utility which enables you to use a portion of your system memory as a very fast RAM drive. Trying to create a backup with Acronis since the RAM drive had been uninstalled proved fruitless because Acronis seemingly balked at not being able to find the RAM drive registered with Windows any longer.
Serendipitously, the developer of the RAM drive software released an updated build of their software earlier this month, so I decided to reinstall it and give it a try. I installed the software, then set up a RAM drive with the same drive letter as I'd originally used.
Upon reinstalling the RAM drive and rebooting, the backup proceeded successfully.
The moral of the story appears to be, if you happened to have a RAM drive installed on your system at some point prior to having Acronis installed, you'd best make sure the RAM drive is existant so that Acronis won't complain and decide to no longer complete your backups.
Labels:
Acronis,
RAMdisk,
troubleshooting
Sunday, December 23, 2012
Battlefield 3 Disconnects
For months I'd been having issues with lag and stuttering in the PC version of Battlefield 3. Worse, though, were frequent, seemingly random disconnects.
I'd connect to a server, be able to play for 10 minutes or more, then my system would lock up hard, unresponsive even to Ctrl-Alt-Del for a few minutes until finally BF3 exited and the Battlelog site came back with anything from a disconnect message to one saying I'd been kicked from the server.
Despite having the latest updates to BF3 itself, as well as for EA's bloated and unnecessary Origin software, PunkBuster, and my system's video drivers and Windows updates, the disconnects continued to occur, making it so that I seldom if ever got to the end of a round without being disconnected.
Finally I decided to take the plunge and configure my DSL router with port forwarding specific to BF3's needs, according to this page on EA's support site.
The site PortForward.com handily provides instructions specific to many router makes and models for the PC, XBox 360, and PS3 versions of Battlefield 3. One note, for the listed TCP ports specific to the PC version, I found that all but ports 80 (http) and 443 (https) were necessary to seemingly work around the disconnect issues I'd been having. You might need these ports forwarded if you plan to have your PC act as a BF3 server, but given that I don't it doesn't seem to make a difference.
Why the BF3 installer or the game itself doesn't specifically tell you which ports to forward in the beginning I don't know. Why EA and DICE rush out their games hurriedly without addressing their users' complaints, I don't know either. I'm happy to have found this works around my problem, and that the game is at least playable for more than 10 minutes or so at a time, but given their track record with previous games and their various issues, I'd like to see BF3 go open source someday and get in the hands of numerous software developers who would likely care more about the game and its users than EA.
I'd connect to a server, be able to play for 10 minutes or more, then my system would lock up hard, unresponsive even to Ctrl-Alt-Del for a few minutes until finally BF3 exited and the Battlelog site came back with anything from a disconnect message to one saying I'd been kicked from the server.
Despite having the latest updates to BF3 itself, as well as for EA's bloated and unnecessary Origin software, PunkBuster, and my system's video drivers and Windows updates, the disconnects continued to occur, making it so that I seldom if ever got to the end of a round without being disconnected.
Finally I decided to take the plunge and configure my DSL router with port forwarding specific to BF3's needs, according to this page on EA's support site.
The site PortForward.com handily provides instructions specific to many router makes and models for the PC, XBox 360, and PS3 versions of Battlefield 3. One note, for the listed TCP ports specific to the PC version, I found that all but ports 80 (http) and 443 (https) were necessary to seemingly work around the disconnect issues I'd been having. You might need these ports forwarded if you plan to have your PC act as a BF3 server, but given that I don't it doesn't seem to make a difference.
Why the BF3 installer or the game itself doesn't specifically tell you which ports to forward in the beginning I don't know. Why EA and DICE rush out their games hurriedly without addressing their users' complaints, I don't know either. I'm happy to have found this works around my problem, and that the game is at least playable for more than 10 minutes or so at a time, but given their track record with previous games and their various issues, I'd like to see BF3 go open source someday and get in the hands of numerous software developers who would likely care more about the game and its users than EA.
Labels:
battlefield 3,
bf3,
DICE,
disconnects,
EA,
port forwarding
Friday, December 21, 2012
Foscam FI9820W Review
I recently purchased a pair of Foscam FI9820W wireless IP cameras to augment my existing pair of FI8918W ones.
Featuring 720p video resolution, H.264 video compression, pan and tilt capability, SD card support, and IR cut to help filter out distortion in the camera's daytime mode, wireless IP cameras like these are very handy because they can be placed anywhere within the reach of your wireless network and a household power outlet, and transmit images and even live video wirelessly.
In addition, if a burglar happens to break in and swipe or disable the cameras themselves, there's a fair chance that before this happens, the camera will have gotten a nice face shot of the perpetrator discovering the camera, and then send it via email or FTP if configured to do so, for you to later submit to the police.
This newest, more expensive camera in Foscam's lineup unfortunately suffers some significant shortcomings. Compared to the more mature FI8918W model, the web interface is still disappointingly ugly and Internet Explorer-centric, utilizing an ActiveX control to render live video in a browser and a few hoops need to be jumped through to get the interface functional in a more mainstream browser like Firefox or Chrome.
As if that were bad enough, a serious security issue arises with the FI9820W's lack of full WPA / WPA2 passphrase support. If your wireless network happens to be protected with one of these security protocols and uses anything other than an alphanumeric passphrase, you'll have no choice but to compromise your wireless security by making your password simpler to accommodate this camera.
Although the picture quality is outstanding in the camera's grayscale night vision mode with all its H.264 sharpness, the daytime mode leaves much to be desired. Even in a well-lit room the image appears blurry and washed out in spite of the included IR cut feature.
Another downside, whereas with the FI8918W you could set up its motion detection to optionally take a variable number of snapshots, the FI9820W allows no more than a single snapshot per activation of the motion alarm. Add to that the fact that the camera shares the similarly short AC adapter cable as its predecessor, there isn't a lot to make this camera in its current form worth the higher cost.
To summarize...
I contacted Foscam's U.S. based technical support about the camera's disappointing features and anemic firmware, who responded to my inquiry on the FI9820W's shortcomings:
Let's hope they will!
Featuring 720p video resolution, H.264 video compression, pan and tilt capability, SD card support, and IR cut to help filter out distortion in the camera's daytime mode, wireless IP cameras like these are very handy because they can be placed anywhere within the reach of your wireless network and a household power outlet, and transmit images and even live video wirelessly.
In addition, if a burglar happens to break in and swipe or disable the cameras themselves, there's a fair chance that before this happens, the camera will have gotten a nice face shot of the perpetrator discovering the camera, and then send it via email or FTP if configured to do so, for you to later submit to the police.
This newest, more expensive camera in Foscam's lineup unfortunately suffers some significant shortcomings. Compared to the more mature FI8918W model, the web interface is still disappointingly ugly and Internet Explorer-centric, utilizing an ActiveX control to render live video in a browser and a few hoops need to be jumped through to get the interface functional in a more mainstream browser like Firefox or Chrome.
As if that were bad enough, a serious security issue arises with the FI9820W's lack of full WPA / WPA2 passphrase support. If your wireless network happens to be protected with one of these security protocols and uses anything other than an alphanumeric passphrase, you'll have no choice but to compromise your wireless security by making your password simpler to accommodate this camera.
Although the picture quality is outstanding in the camera's grayscale night vision mode with all its H.264 sharpness, the daytime mode leaves much to be desired. Even in a well-lit room the image appears blurry and washed out in spite of the included IR cut feature.
![]() |
| Night vision engaged, the image is relatively sharp and clear. |
Another downside, whereas with the FI8918W you could set up its motion detection to optionally take a variable number of snapshots, the FI9820W allows no more than a single snapshot per activation of the motion alarm. Add to that the fact that the camera shares the similarly short AC adapter cable as its predecessor, there isn't a lot to make this camera in its current form worth the higher cost.
![]() |
| Daytime, even with IR cut the image is disappointingly grainy and washed out. |
PROS:
CONS:
- High video resolution.
- Sharp night vision.
- SD card support.
- Nonstandard WPA / WPA2 passphrase support.
- Grainy, washed-out daytime video.
- Internet Explorer centered, 1990s-era web interface.
- Short AC adapter cable.
I contacted Foscam's U.S. based technical support about the camera's disappointing features and anemic firmware, who responded to my inquiry on the FI9820W's shortcomings:
"Your suggestions will forward to our R&D team, we'll try to fain [sic] these features in the future software. Highly appreciated your feedbacks. Thanks a lot."
Let's hope they will!
Saturday, September 15, 2012
Reseed Identity Using Variable
In a sproc that involves creating a copy of a production SQL table for testing, I wanted to reseed the identity of the new table to 1 more than the max of the production key value.
I figured at first I'd just use the appropriate syntax for DBCC and just use a variable already at hand containing the max production value and add 1 to it, like so:
SQL, however, would have nothing of it:
To work around this, I decided to try creating a dynamic SQL string to incorporate the variable arithmetic:
Now I can create the table and set its starting identity value to 1 greater than in production using a variable despite DBCC's syntax dictating otherwise.
I figured at first I'd just use the appropriate syntax for DBCC and just use a variable already at hand containing the max production value and add 1 to it, like so:
DECLARE @MaxID int -- Grab the max identity value from production. SELECT @MaxID = MAX(ID) FROM dbo.MyProductionTable DBCC CHECKIDENT (MyProductionTable_COPY, reseed, @MaxID + 1)
SQL, however, would have nothing of it:
Incorrect syntax near '+'.
To work around this, I decided to try creating a dynamic SQL string to incorporate the variable arithmetic:
DECLARE @MaxID int DECLARE @SQL nvarchar(100) -- Grab the max identity value from production. SELECT @MaxID = MAX(ID) FROM dbo.MyProductionTable SET @SQL = 'DBCC CHECKIDENT (MyProductionTable_COPY, reseed, ' + CAST(@MaxID + 1 AS nvarchar(10)) + ')'
Now I can create the table and set its starting identity value to 1 greater than in production using a variable despite DBCC's syntax dictating otherwise.
Labels:
SQL
Friday, August 31, 2012
Enforced Dependencies and Schemabinding
In trying to rename a table I encountered the dreaded error about enforced dependencies:
I first used the following script to identify the objects dependent upon the table:
This yielded the names of three objects in my database which happen to use SCHEMABINDING in their definitions.
I didn't want to manually alter and recreate these objects, so instead I decided to create a script which will find the SQL code for each object, remove the WITH SCHEMABINDING syntax, drop the existing objects and then recreate them sans schema binding.
Now I can incorporate this logic into a sproc and not have to worry about meddlesome constraints if I'm going to be renaming tables. The above script has been tested successfully under SQL 2008 and 2012, and will be able to automatically drop and recreate views, scalar and table valued functions, sprocs and triggers.
Object 'myTable' cannot be renamed because the object participates in enforced dependencies.
I first used the following script to identify the objects dependent upon the table:
SELECT DISTINCT o.object_id, o.name, o.type_desc, m.definition
FROM sys.sql_dependencies d
JOIN sys.objects o ON o.object_id = d.object_id
JOIN sys.objects r ON r.object_id = d.referenced_major_id
JOIN sys.sql_modules m ON m.object_id = o.object_id
WHERE d.class = 1
AND r.name = 'myTable'
This yielded the names of three objects in my database which happen to use SCHEMABINDING in their definitions.
I didn't want to manually alter and recreate these objects, so instead I decided to create a script which will find the SQL code for each object, remove the WITH SCHEMABINDING syntax, drop the existing objects and then recreate them sans schema binding.
DECLARE@TheTable varchar(100),@Count int,@Max int,@object_id int,@name varchar(50),@type_desc varchar(50),@definition nvarchar(max),@DropSQL nvarchar(max),@CreateSQL nvarchar(max) -- Remove schemabinding from objects tied to table. DECLARE @Objects TABLE ( ID int IDENTITY (1, 1) PRIMARY KEY NOT NULL,object_id int,name varchar(50),type_desc varchar(50),definition nvarchar(max) ) -- Set the table name here: SET @TheTable = 'MyTable' INSERT INTO @Objects (object_id, name, type_desc, definition) SELECT DISTINCT o.object_id, o.name, o.type_desc, m.definition FROM sys.sql_dependencies d JOIN sys.objects o ON o.object_id = d.object_id JOIN sys.objects r ON r.object_id = d.referenced_major_id JOIN sys.sql_modules m ON m.object_id = o.object_id WHERE d.class = 1 AND r.name = @TheTable UPDATE @Objects SET definition =CASEWHEN definition LIKE '%SCHEMABINDING%' THEN REPLACE(definition, 'WITH SCHEMABINDING', '')ELSE definitionEND SELECT @Count = 1, @Max = COUNT(ID) FROM @Objects WHILE @Count <= @Max BEGINSELECT @object_id = object_id, @name = name, @type_desc = type_desc, @definition = definitionFROM @ObjectsWHERE ID = @CountSET @DropSQL ='DROP '+CASE @type_descWHEN 'VIEW' THEN 'VIEW'WHEN 'SQL_SCALAR_FUNCTION' THEN 'FUNCTION'WHEN 'SQL_TABLE_VALUED_FUNCTION' THEN 'FUNCTION'WHEN 'SQL_STORED_PROCEDURE' THEN 'PROCEDURE'WHEN 'SQL_TRIGGER' THEN 'TRIGGER'END+' '+@namePRINT @DropSQLEXEC sp_executeSQL @DropSQLSET @CreateSQL = @definitionPRINT @CreateSQLEXEC sp_executeSQL @CreateSQLSET @Count = @Count + 1 END
Now I can incorporate this logic into a sproc and not have to worry about meddlesome constraints if I'm going to be renaming tables. The above script has been tested successfully under SQL 2008 and 2012, and will be able to automatically drop and recreate views, scalar and table valued functions, sprocs and triggers.
Labels:
SQL
Friday, August 24, 2012
Monday, August 20, 2012
Those Bitches!
Classic scene I captured in animated GIF form in homage to the hilarious parody trailer, Star Wars Episode III: A Lost Hope.
Labels:
animated gif,
photoshop,
Star Wars
Photoshop CS5 Slow Animated GIF Playback
In Photoshop CS5 you can import video and transform it into a series of layers, then export that collection of layers as an animated GIF.
However, one gotcha I encountered has to do with frame rate and playback speed of the resulting GIF animation. I found that despite the fact that I'd set the no delay between each frame, the animation appeared slow regardless of which browser I used.
To work around this annoyance, I found that I needed to tweak the frame rate of the animation in timeline mode.
Here's how.
First off, make sure the QuickTime player is installed. Photoshop uses QuickTime to render video into layers, and the video must be viewable in QuickTime in order to be imported properly; if it's not and using some unrecognized video codec, it might import as a series of blank frames.
In Windows Explorer, right-click on the video file you want to import, and click the Details tab. Note the frame rate of the video in question is 25 frames per second (fps).
Click File => Import => Video Frames to Layers and import your video into Photoshop.
In Photoshop, perform edits you want, such as removing frames, adding text, whatever you need to do for your animation.
Ensure the Animation panel is visible by clicking Window and verifying a checkmark is beside Animation. Then, click on the button in the lower-right area of the frame view, which has a tooltip "Convert to timeline animation". Upon doing this, the frame view will disappear and be replaced with a timeline showing the layers stacked upon each other.
You should also notice that in the timeline view, the frame rate is shown. Note how it differs from the original frame rate of the imported video.
Now we alter the animation's frame rate to correspond to the original video's frame rate. In the upper-right corner of the Animation panel you should see a tiny upside-down triangle. Click this to reveal the Animation panel's popup menu, then click Document Settings.
Now the Document Timeline Settings window appears, from which you can change the Frame Rate from the default of 30 to the value corresponding to that of your imported video, in this case, 25.
Finally, click File => Save for Web & Devices to save the project as an animated GIF according to the settings you require. The resulting GIF should now be in sync with the original video in terms of frame rate, and render at about the same speed rather than annoyingly slow.
However, one gotcha I encountered has to do with frame rate and playback speed of the resulting GIF animation. I found that despite the fact that I'd set the no delay between each frame, the animation appeared slow regardless of which browser I used.
To work around this annoyance, I found that I needed to tweak the frame rate of the animation in timeline mode.
Here's how.
First off, make sure the QuickTime player is installed. Photoshop uses QuickTime to render video into layers, and the video must be viewable in QuickTime in order to be imported properly; if it's not and using some unrecognized video codec, it might import as a series of blank frames.
In Windows Explorer, right-click on the video file you want to import, and click the Details tab. Note the frame rate of the video in question is 25 frames per second (fps).
Click File => Import => Video Frames to Layers and import your video into Photoshop.
In Photoshop, perform edits you want, such as removing frames, adding text, whatever you need to do for your animation.
Ensure the Animation panel is visible by clicking Window and verifying a checkmark is beside Animation. Then, click on the button in the lower-right area of the frame view, which has a tooltip "Convert to timeline animation". Upon doing this, the frame view will disappear and be replaced with a timeline showing the layers stacked upon each other.
You should also notice that in the timeline view, the frame rate is shown. Note how it differs from the original frame rate of the imported video.
Now we alter the animation's frame rate to correspond to the original video's frame rate. In the upper-right corner of the Animation panel you should see a tiny upside-down triangle. Click this to reveal the Animation panel's popup menu, then click Document Settings.
Now the Document Timeline Settings window appears, from which you can change the Frame Rate from the default of 30 to the value corresponding to that of your imported video, in this case, 25.
Finally, click File => Save for Web & Devices to save the project as an animated GIF according to the settings you require. The resulting GIF should now be in sync with the original video in terms of frame rate, and render at about the same speed rather than annoyingly slow.
Labels:
animated gif,
cs5,
frame rate,
photoshop,
slow
Subscribe to:
Comments (Atom)
























