My wife has an X23 series model 2662 IBM ThinkPad. For years, she's avoided using the TrackPoint pointing device embedded in the keyboard as the standard rounded one was extremely abrasive and worn. She'd always attach an external mouse or (after meeting me) a trackball, or when in need using a piece of tissue to protect her finger. Well, dutiful husband that I am, I finally bothered to do a Google search if there was some replacement nipple or eraser tip for her model.
I was happy to find that Lenovo sells an inexpensive ThinkPlus TrackPoint Cap Collection. So for $10 shipped, I bought a variety of replacement caps, and she likes the wide flat type with the rim. Much more comfortable.
Monday, January 29, 2007
Friday, January 26, 2007
MythFrontend and HDHomeRun Wireless on a MacBook
[Update: check out Signal GH, an iPhone utility for monitoring the signal quality of an HDHomerun].
I've been running the MythTV Frontend for Intel OS X several hours a week for the last month. This is on my original MacBook (1.83GHz Core Duo, 2GB RAM) connected wirelessly via a 802.11g router to the basement MythTV server. I'm typically on the couch in the TV room upstairs, or on the bed in the basement; 30 feet from the wireless hub at most.
Performance has been good, and I've been happy with it, but it does lock up if you quit the application directly from Live TV mode. It's an odd sort of lock up in that the video keeps playing, but the beach ball of death cursor indicates the GUI itself is locked. So I'll command-tab out and force quit the application. Of course, the audio is nothing compared to the 5.1 speakers on the actual MythTV, but I have been known to watch even such sound intense shows as 24 on the MacBook, too lazy to watch it properly. Occasional flickers could be wireless instability, noise on the antenna, other processes grabbing the MacBook CPU or packets lost in Ethernet. It's hard to say.
I had worried whether my Ethernet network was up to the task of carrying 2 HD streams down from the HDHomeRun in the network closet to the MythTV (both the PC and the HDHomeRun are 100Base-T, the routers are 1000Base-T and the wiring is Cat-6) while simultaneously streaming a 3rd stream back up the same Ethernet cable to the wireless hub in the network closet. But, this works surprisingly well. I do like to give Live TV a couple seconds of buffer to give it a chance for error.
The GUI actually works better than the Linux version on my desktop, where I long ago lost the overlay GUI in TV mode. On the Mac, I actually see the Paused/Play time HUD window when I pause playback. Interlacing is not as good though.
In preparation for writing this blog entry, I put the MythTV frontend into a small window mode, and I'm just noticing it mirrors the video content in the OS X Dock. This is probably a bad idea, and a waste of cycles. I know it's cool and all, in a 2001 sort of way, but not that cool. Also, the UI for changing the window size is completely lame: holding down the right arrow key while it counts up to 480 horizontal pixels when I have a perfect good 4, 8 and 0 keys is unforgivable.
In summary, MythFrontend for OS X is nice to have, and I'm glad network and computer hardware is finally up to the task of this kind of high bandwidth application.
I've been running the MythTV Frontend for Intel OS X several hours a week for the last month. This is on my original MacBook (1.83GHz Core Duo, 2GB RAM) connected wirelessly via a 802.11g router to the basement MythTV server. I'm typically on the couch in the TV room upstairs, or on the bed in the basement; 30 feet from the wireless hub at most.
Performance has been good, and I've been happy with it, but it does lock up if you quit the application directly from Live TV mode. It's an odd sort of lock up in that the video keeps playing, but the beach ball of death cursor indicates the GUI itself is locked. So I'll command-tab out and force quit the application. Of course, the audio is nothing compared to the 5.1 speakers on the actual MythTV, but I have been known to watch even such sound intense shows as 24 on the MacBook, too lazy to watch it properly. Occasional flickers could be wireless instability, noise on the antenna, other processes grabbing the MacBook CPU or packets lost in Ethernet. It's hard to say.
I had worried whether my Ethernet network was up to the task of carrying 2 HD streams down from the HDHomeRun in the network closet to the MythTV (both the PC and the HDHomeRun are 100Base-T, the routers are 1000Base-T and the wiring is Cat-6) while simultaneously streaming a 3rd stream back up the same Ethernet cable to the wireless hub in the network closet. But, this works surprisingly well. I do like to give Live TV a couple seconds of buffer to give it a chance for error.
The GUI actually works better than the Linux version on my desktop, where I long ago lost the overlay GUI in TV mode. On the Mac, I actually see the Paused/Play time HUD window when I pause playback. Interlacing is not as good though.
In preparation for writing this blog entry, I put the MythTV frontend into a small window mode, and I'm just noticing it mirrors the video content in the OS X Dock. This is probably a bad idea, and a waste of cycles. I know it's cool and all, in a 2001 sort of way, but not that cool. Also, the UI for changing the window size is completely lame: holding down the right arrow key while it counts up to 480 horizontal pixels when I have a perfect good 4, 8 and 0 keys is unforgivable.
In summary, MythFrontend for OS X is nice to have, and I'm glad network and computer hardware is finally up to the task of this kind of high bandwidth application.
Be careful with your CFBundleVersion
This post is along the way of a reminder to myself should I ever have to figure out how my application's plist has caused the Launch Services manager to act strangely.
If you accidently setup your CFBundleVersion element badly, by for example, putting it in quotes, you will end up with the Launch Services database treating it as if it had a version of zero. You can see this clearly by running the lsregister utility:
[Update: lsregister has moved in Leopard:
]
If you accidently setup your CFBundleVersion element badly, by for example, putting it in quotes, you will end up with the Launch Services database treating it as if it had a version of zero. You can see this clearly by running the lsregister utility:
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump[Update: lsregister has moved in Leopard:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -dump]
Subscribe to:
Posts (Atom)