After upgrading my Mythbuntu box to the latest 12.04 release which included an update to MythTV 0.25.  Shortly after that I noticed that my backend would continually fail, and it didn’t seem to be able to change the channel.

With the newer versions of MythTv, they seem to have nice Set Top Box firewire support built in, as in previous versions I didn’t have to setup any channel change scripts or firewire primers or anything to get it to work.

After this upgrade, I had to go through all of the old firewire documentation to figure out what was going on.

I built the firewire_tester here and used it to confirm that the STB can in fact be communicated with.  Then I built the 6200ch channel changer app to test changing channels.  When attempting to change channels using 6200ch I got errors.  Further reading on the 6200ch page mentions being able to add support for addition models.  So I ran 6200ch -v -v to get my vendor and model numbers, and found that my vendor model was included in the original 6200ch.c source file, but my model number (0x0000628a) wasn’t.

I added my model ID to the model definitions, and included it in the big if / or statement near the bottom of the source file and recompiled (and copied it to /usr/local/bin).

Using the new app, I could sucessfully change channels, so I updated my mythbackend settings to use this external channel change command and my Mythbuntu 12.04 installation running MythTV 0.25 seems to be working fine.

The changes I made to add my model number are now included in the MythTv 6200ch wiki entry, so if you are running the same model STB as me, grab the updated version there.


This one took up way too much time in my day today, and I still haven’t figured out why this happened yet, but I do have the solution that worked for me.

On SQL Server 2008 we run some remote processes that get kicked off via a sql agent jobs, and to execute those remote processes we use psexec.  All of a sudden all of our psexec calls started failing with the error below:

The process could not be created for step 2 of job <jobid> (reason: %1 is not a valid Win32 application).  The step failed.

A quick google brought up all sorts of  things I started looking at including verifying that the service account running Sql Agent had proper permissions to the folder and verifying that the exe and the path to the executable was correct.  All the posts I found referred to missing executables, but I could copy and paste my commands directly into a command prompted on that sql server and it ran fine.

We were calling psexec like this:


And running that directly via remote desktop session ran fine, so I couldn’t figure out why it wouldn’t run via a Sql Server  agent job.

For whatever reason, adding the .exe to the end of the call made the job work:


Today I stumbled upon a stuct tags in Go.  I hadn’t heard or seen these before as they are barely mentioned in any go documentation, but they can be crucial to working with protobufs, json or xml.

In my case I was working with json.

I’m trying to write a command line uploader for pictures for gallery3, as there appears to be no client that actually works on linux.  Gallery3 uses a RESTful api with the request contents being delivered in url encoded json.

Go has a really nice json package for getting json data in and out of Go structures.  The problem I was running into was that the golang JSON package requires upper case names (i.e. exported names) for marshalling and unmarshalling data, while the actual JSON package needed by the rest api required lower case names.

Enter Struct Tags:

You can specify a different name than the one in the Go struct by “tagging” the structure field like this:


Now, you look at that and ask: “Are those single quotes?”

No.  They are backticks, also know as backquotes, also know as a grave, also known as that thing that’s on the same key as the tilde.

I had no idea that they even existed, much less were a lexically valid part of a golang program.

My structure ended up looking like this:

type RestCreate struct {

Type string `json:”type”`

Name string `json:”name”`

Title string `json:”title”`


I’m just getting started with both Go and Vim, but already I’m seeing the incredible potential of both.  Go is only a couple years old now, so the refined, gui driven tools aren’t in place yet, which makes it perfect for use with Vim.  You can quickly throw together a working environment from gathered scripts all over the internet.

Here’s a breakdown of my (work in progress) go.vim file.  I load all my go specific settings in the ~/.vim/after/ftplugin/go.vim file so as to keep my .vimrc file clean of language specific stuff.  I do still occasionally write a quick python script for things I want automated quickly.

set makeprg=gb
set errorformat=%D(in\ %.%#)\ building\ pkg\ \”%f\”,%f:%l:\ %m%.%#,%-G%.%#

set rtp+=$GOROOT/misc/vim
autocmd BufWritePre *.go :silent Fmt

“Shell command sends result from shell to temp buffer
command! -complete=shellcmd -nargs=+ Shell call s:RunShellCommand(<q-args>)
function! s:RunShellCommand(cmdline)
echo a:cmdline
let expanded_cmdline = a:cmdline
for part in split(a:cmdline, ‘ ‘)
if part[0] =~ ‘\v[%#<]’
let expanded_part = fnameescape(expand(part))
let expanded_cmdline = substitute(expanded_cmdline, part, expanded_part, ”)
botright new
setlocal buftype=nofile bufhidden=wipe nobuflisted noswapfile nowrap
call setline(1, ‘You entered: ‘ . a:cmdline)
call setline(2, ‘Expanded Form: ‘ .expanded_cmdline)
call setline(3,substitute(getline(2),’.’,’=’,’g’))
execute ‘$read !’. expanded_cmdline
setlocal nomodifiable

“Test command for gotest, sends results of the goTest to a temp buffer
“for review
command! Test call s:RunShellCommand(‘gb -t’)

With this I can quickly :make my code (thanks to the effortless go-gb) and then test it with :Test, and with a handy :Shell command I stole from here I can quickly browse my test results in a separate buffer.

The point of this blog is to document fixes for the random technical things breaking that I deal with on a regular basis.  This is payback to the internet for every single time I googled an obscure error and found the exact fix I needed on some other nerds personal blog.

If just one of you finds any post on this site useful, then it will have been worth it.

Here’s the first:

I begin diving into Vim around the same time as learning GO.  Probably not smart to start a new programming language at the same time as tossing your old comfortable IDE out the window, but I guess I’m a masochist.  So I was just learning my way around GVim, and trying to get exuberant cTags to build properly for GO, when I started getting a “vim tags file not sorted” up executing vim’s omnicomplete.  One of the things that really pushed me towards vim was it’s nice integration with gocode, and all of a sudden I was getting errors everytime I tried to omnicomplete a variable.

Immediately I started deleting any vim plugin I had that referred to tags trying to restore my clean omnicomplete, but to no avail.

Then I found this post:

The problem was I had clicked the build tags file menu link in gVim without anything properly configured.  It created a tags file in my home directory, and that’s what was causing the issue.  Deleting the tags file cleared the issue.