The Treehouse Blog

For some time now, wake-on-LAN has not been working on my home server PC.  I had been using WoL to wake the machine via a cron job on my firewall before I got home from work, and also to power the machine on remotely if I needed to get a file or such.  I had guessed a kernel change was to blame, but several updates since have not resolved, and my search for related bugs only turned up advice that didn’t work.  So, I threw in an Intel e1000 and cabled it up (using the on-board for most purposes, as the e1000 is only PCI), and WoL “just works” with the e1000.  FWIW, the on-board is an Nvidia MCP55.  Problem solved… or at least worked around.

A few things I learned today. None of this is surprising, but there’s nothing like first-hand experience.

1. When on a bike ride, and considering a path that involves walking the bike on a thorny trail, over a fallen tree over a stream, and up a 15ft steep bank with guard-rail at the top, do not ignore your suspicion that the thorns will be bad for your tires.
2. Riding a bike with a flat tire is not sustainable, and will quickly cause the tire to come off the rim.
3. Pushing a bike with a tire that is not on the rim will eventually lead to the inner tube coming out, which will get stuck in things and make the bike non-pushable.
4. Despite Chris Barner’s insistence, generally, you can’t union two bikes together into a tandem bike.
5. Biking with a chest cold is tiring.

When things are working well, my PVR box is supposed to wake-on-LAN about the time I get home, and be ready for use.  Since the LCD, the box wouldn’t be driving the display after boot.  I would have to kill and restart X with the LCD powered on.  Apparently this is due the NVIDIA driver needing to read the EDID from the LCD to figure out what resolution to use.  I tried a variety of ways forcing it to work without validating the resolution, but I ended up downloading the EDID to a file (using the nvidia-settings gui) and having the driver run against that.  Not that inelegant, I think.

Section "Device"
        Identifier  "Videocard0"
        Driver      "nvidia"
        VendorName  "NVIDIA Corporation"
        BoardName   "GeForce 7300 GS"
        Option      "UseEvents" "True"
        Option      "CustomEDID" "DFP-0: /var/lib/mythtv/edid.bin"
        Option      "ConnectedMonitor" "DFP"
        Option      "MetaModes" "DFP: 1920x1080"
EndSection

After sitting on the todo list for a year, I have finally taken the plunge into the world of HDTV.  I purchased a Samsung LN40A550 which is an LCD 1080p display.  It arrived on my birthday, allowing me to watch the season premier of LOST that same evening (happy birthday to me!).  I’ve subsequently had to upgrade a few things – replacing my video card so that I have less tearing, and buying an HDhomerun for capturing QAM streams from my cable provider.  (Note to the internet: Kuhn Cable does have 6 channels of QAM!)  I still need to clean up the cabling to the HDhomerun, and fix an issue I have with not being able to seek recorded HD content, and assorted other Mythtv issues, and some playback stuttering, but I have a bigger, HD-er TV now.  Doug did a lot of this stuff just before me, so many thanks to him for being the trial run.

Update:  My seeking problem was due to a crashed “recordingseek” table.  I repaired it and then ran mythcommflag –rebuild to regenerate the information for the recordings that wouldn’t seek.

I’ve decided to drop my use of AIM, and switch to Jabber/XMPP exclusively, on the arbitrary date of 2/17/09.  I might even setup a work account if there’s any interest.  Despite AIM being pretty darn stable, and not as evil as before (no need for the AIM binary lately on non AOL clients), I’m not a big fan of the lack of decent privacy features (at least, that I know of), and open protocols/systems are always nicer.  So, if you have any interest in IM’ing me ever after 2/17, make sure you’re XMPP-enabled.