I stupidly decided to opt-in to the Steam Beta client today. WHAT A MISTAKE!
After applying a patch and restarting Steam I was greated with the following error:
"Error...steam.exe (main exception): " yada, yada, yada but the best part is that the error was Error 1 or 0 "unknown error".
Awesome.
Well after about 45 minutes I got things working again.
I used the repair option given from the installer on my original Orang Box DVDs. Then, I deleted the Registry Keys "beta" and everything under "Users" at the following location:
HKCU\Software\Valve\Steam
After that Steam started, updated, and I simply logged in again. Bingo!
Friday, 22 May 2009
Saturday, 9 May 2009
Fish-Cam is GO!
I recently made a nice little to-do list on my fridge with a dry erase marker I've had since university. It doesn't judge me; you shouldn't either.
..anyways I've made some very good progress on said project and have now officially kicked off my "Fish-Cam" project. It is essentially a budget/DIY version of this or this.
I decided to use a portable DVD player instead of a stand-alone mini-LCD or *gasp* a mini-CRT. The main reasons for this decision are:
..anyways I've made some very good progress on said project and have now officially kicked off my "Fish-Cam" project. It is essentially a budget/DIY version of this or this.
I decided to use a portable DVD player instead of a stand-alone mini-LCD or *gasp* a mini-CRT. The main reasons for this decision are:
- Cost. A portable DVD player is ~$80 - $180 CAD right now. Mini LCDs are $110+
- Design. Portable DVD players are meant for lugging around. Mini LCDs are really meant to be mounted somewhere.
- Features. A Mini-LCD is useless on it's own. A portable DVD player plays DVDs, mp3s, etc.
- Availability. Wal-Mart had plenty of portable DVD players. Only a few shops have mini LCDs... and questionable return policies if things don't work!
Review: Portable DVD Players (RCA DRC6338 & Toshiba SD-P70S)
As part of my Fish-Cam project I decided that I'd look at purchasing a portable DVD player to use as the monitor. So I went over to Wal-Mart and picked out the RCA DRC6338 8" portable DVD player because it was on sale and had an 8" screen. What a mistake! Luckily upon return of that unit I picked up the Toshiba SDP70S and was very pleased.
Here are my reviews...
RCA DRC6338
Cost - $119 CAD
Features - Car charger, wall charger, built-in battery, 8" screen, audio/video inputs & outputs, remote
Review - Crap. It has a cheap feel, doesn't include the special cable you'll need for av i/o, and didn't work with my video input source at all. It also lacks the ability to output digital audio (not that I care). Even worse; you can't use the device and charge it at the same time! Really poor design.
This unit went back as soon as it failed to display my video input source.
Toshiba SD-P70S
Cost - $98 CAD
Features - Car charger, wall charger, external battery, 7" screen, a/v in & out, remote
Review - Excellent. It feels well built and the packaging is many times better than the RCA. It also INCLUDES the special a/v input cord you'll need and does do digital output. It worked right away with my video input source and I didn't even have the battery plugged in to the unit. This is great as I plan to run this 100% from a 12V battery as part of the fish-cam and I don't want to worry about battery life at all. The unit CAN charge and play at the same time.
Although it does have 1" less viewable space I'd consider this unit superior to the RCA. The fact that it includes the a/v cables makes up for the screen size IMHO.
Here are my reviews...
RCA DRC6338
Cost - $119 CAD
Features - Car charger, wall charger, built-in battery, 8" screen, audio/video inputs & outputs, remote
Review - Crap. It has a cheap feel, doesn't include the special cable you'll need for av i/o, and didn't work with my video input source at all. It also lacks the ability to output digital audio (not that I care). Even worse; you can't use the device and charge it at the same time! Really poor design.
This unit went back as soon as it failed to display my video input source.
Toshiba SD-P70S
Cost - $98 CAD
Features - Car charger, wall charger, external battery, 7" screen, a/v in & out, remote
Review - Excellent. It feels well built and the packaging is many times better than the RCA. It also INCLUDES the special a/v input cord you'll need and does do digital output. It worked right away with my video input source and I didn't even have the battery plugged in to the unit. This is great as I plan to run this 100% from a 12V battery as part of the fish-cam and I don't want to worry about battery life at all. The unit CAN charge and play at the same time.
Although it does have 1" less viewable space I'd consider this unit superior to the RCA. The fact that it includes the a/v cables makes up for the screen size IMHO.
Monday, 4 May 2009
HEAP Fragementation in SQL Server 2005
I happened upon an interesting problem at work today. There's an application my company purchased that is used for project management in one way or the other. Each night a job runs that does various things including synchronizing variables like permissions and user names with Active Directory. The vendor supplied the script that does this and it's terrible. It involves dumping a lot of data into a work table, then pulling that data out piece by piece, converting it to XML, comparing the XML to some other XML, and then re-inserting into the database. Yikes.
Anyways, the performance of this sync job is fairly constant until a certain point and then it just blows up and quadruples the run time which affects other processes.
Previously this was solved when I noted the complex system we use to defrag our databases had a bug in it. I fixed the bug, defragmented things and everything went back to normal.
This time however, there is no bug and the tables that play a role didn't show any sort of fragmentation at all. In QA I just went ahead and defragmented everything with the "quick & dirty" rebuild script
Never, ever use that on a production database :p
A test showed that the sync was indeed working properly again. Great. So all we need to do is ensure that the database has essentially zero fragmentation on all tables and indexed views to get this to work. I'd also take a pet unicorn while we're wishing.
So I did a little more digging around and I noticed that our automated index rebuilding script didn't consider index_id = 0 (HEAP) which meant I wasn't viewing any data for that while reviewing fragmentation levels. I coded up a very quick fragmentation check query
What I found shocked me. There were 10+ large heaps with 99.5%+ fragmentation!!
I immediately started to dig in and see why these tables didn't have clustered indexes and you know what I found? No reason. No reason at all. There were already non-clustered and unique indexes on every table I found. For some reason the developer/vendor just never clued in that over time they would create massive fragmentation on these tables and not give us poor DBAs a chance to fix it. My assumption is that this was developed way back in the SQL 6 or 7 days where I *think* they used linked-heap table structure... don't quote me on that though as I've never touched anything older than 2000 (and oh man do I not miss 2000!)
If you're not sure how I fixed things yet I'll tell you. I converted a UQ index on each table to a clustered index (using a best guess approach) which rebuilt all the others. Fragmentation is under 1% and I'll be able to monitor the fragmentation now to see if I need to do anything else with these tables.
All this work because a vendor didn't bother to properly design their database. Shocking, eh? ;)
Anyways, the performance of this sync job is fairly constant until a certain point and then it just blows up and quadruples the run time which affects other processes.
Previously this was solved when I noted the complex system we use to defrag our databases had a bug in it. I fixed the bug, defragmented things and everything went back to normal.
This time however, there is no bug and the tables that play a role didn't show any sort of fragmentation at all. In QA I just went ahead and defragmented everything with the "quick & dirty" rebuild script
EXEC sp_msforeachtable 'ALTER INDEX ALL ON ? REBUILD'
Never, ever use that on a production database :p
A test showed that the sync was indeed working properly again. Great. So all we need to do is ensure that the database has essentially zero fragmentation on all tables and indexed views to get this to work. I'd also take a pet unicorn while we're wishing.
So I did a little more digging around and I noticed that our automated index rebuilding script didn't consider index_id = 0 (HEAP) which meant I wasn't viewing any data for that while reviewing fragmentation levels. I coded up a very quick fragmentation check query
SELECT object_name(object_id)
,index_id
,partition_number
,page_count
,avg_fragmentation_in_percent
,index_type_desc
FROM sys.dm_db_index_physical_stats(DB_ID(N'--dbname--'), NULL, NULL, NULL , 'LIMITED')
ORDER BY page_count DESC, avg_fragmentation_in_percent DESC;
What I found shocked me. There were 10+ large heaps with 99.5%+ fragmentation!!
I immediately started to dig in and see why these tables didn't have clustered indexes and you know what I found? No reason. No reason at all. There were already non-clustered and unique indexes on every table I found. For some reason the developer/vendor just never clued in that over time they would create massive fragmentation on these tables and not give us poor DBAs a chance to fix it. My assumption is that this was developed way back in the SQL 6 or 7 days where I *think* they used linked-heap table structure... don't quote me on that though as I've never touched anything older than 2000 (and oh man do I not miss 2000!)
If you're not sure how I fixed things yet I'll tell you. I converted a UQ index on each table to a clustered index (using a best guess approach) which rebuilt all the others. Fragmentation is under 1% and I'll be able to monitor the fragmentation now to see if I need to do anything else with these tables.
All this work because a vendor didn't bother to properly design their database. Shocking, eh? ;)
Sunday, 3 May 2009
Roomba Scheduling App Released (SerialBandit)
I spent some time writing an application that will communicate with a 5XX series Roomba (I have a 530) via RS232 (COMM Port or Serial Port) from your computer. The main goal was to let me setup my Roomba to clean at specific times (cleaning schedule). You can buy a device from iRobot that will let you do this remotely, but not for my version of Roomba (or below in the 500-series).
I couldn't find any apps that worked reliably and did what I was looking for so I wrote my own.
I'll include a few pictures of the setup, but essentially it's the standard Serial Port -> MAX232 -> Roomba setup. You can get further instructions here if you need them.
The application is up on CodePlex here. You can download the compiled app on the "Downloads" tab. :)
Picture below show...
Leave comments here for support.
Cheers!
**UPDATE 1**
I've posted my announcement on RobotReviews.com (here)
**UPDATE 2**
Apparently 2 posts with details of this app is "spamming the boards". Oh well. :p
I couldn't find any apps that worked reliably and did what I was looking for so I wrote my own.
I'll include a few pictures of the setup, but essentially it's the standard Serial Port -> MAX232 -> Roomba setup. You can get further instructions here if you need them.
The application is up on CodePlex here. You can download the compiled app on the "Downloads" tab. :)
Picture below show...
- Quick shot of the interface
- The Roomba serial port connector I made (A 6 pin mini DIN with the key removed, connected to Cat5e cable)
- The Roomba plugged in to the serial adapter
- The PC -> Roomba Converter on breadboard
- The schematic I used. 100% Credit on the schematic goes to Tod E. Kurt
Leave comments here for support.
Cheers!
**UPDATE 1**
I've posted my announcement on RobotReviews.com (here)
**UPDATE 2**
Apparently 2 posts with details of this app is "spamming the boards". Oh well. :p
Subscribe to:
Posts (Atom)