One of my wife’s Christmas gifts was, admittedly, partially a toy for me. More accurately, i purchased it because I appears/appeared to fulfill a need of hers, while at the same time, hoping I could have some fun and learn a bit about it too.

The item in question is the Pinnacle PCTV HD Pro Stick… or more specifically, the Woot.com-branded one that I purchased at a price significantly lower than list.

Now, everything I’d read said it was a good product, but that you should use a different software — something like the nifty (and GPLed) app, MediaPortal — because the proprietary app was dog-slow. Sure enough, when I got everything installed, the HD channels appeared reasonably well, albeit occasionally choppy, but amazingly clear. However, it wasn’t long before the app UI would be nearly downright unresponsive, except for the actual video display itself.

I then installed MediaPortal, and the UI worked better — but video seemed to suffer a slight bit more. Hmmph.

Perhaps I should, at this point, indicate that my wife’s system is about a three-year old Dell Inspiron. Not a workhorse by any means, but not quite ready to be put out to pasture yet, especially due to fine grooming and upkeep, resulting in a virus/spyware free system. Also, too many horse metaphors there.

Anyway, while it seemed to me that her system was certainly suitable for this usage, the thought also passed through my mind that I needed to try things on a more high-calibre system.

Half a day later, after poring through Em28xx docs and associated module compilations, figuring out which apps could handle DVB (since Media Portal is a Windows app), and then learning how to scan for said HD channels, I started picking up high-def channels on my Fedora box.

However, I am saddened to report that on my desktop — a dual AMD 3800+ with a slightly dated, but seemingly reasonable video card (NVIDIA GeForce 6600), video was still choppy — perhaps even more so than on my wife’s laptop.

And yet still haven’t found a lot of people complaining about the quality (or lack thereof) in this product.

Nonetheless, I’ve come to some conclusions.

• You need a reasonably powerful and recent CPU/video card to do this newfangled HD stuff,
• Even though it’s readily known that the Linux Em28xx work is still not ready for primetime, my experiences may well may be further evidence to such notions,
• There is still a reasonable chance that there’s something I could do to improve/streamline my own user experience with this device

In any case, I am somewhat disappointed in my first forays into the world of HD — and computing in HD at that — but I’ve not yet given up the ghost that this stuff could work.

I’m usually kind of hesitant to upgrade Fedora releases immediately after the come out… I like to make sure most of the bugs are ironed out so that I don’t hose something. However, I simply couldn’t resist this time, and over a span of 24 hours, I upgraded both my home-built desktop and T43 laptop from F7 to F8.

Now, being an Xfce user (for the time being anyway), I don’t get to experience a lot of the bells and whistles arriving in F8, such as pulseaudio and the neato changing background stuff that Máirín worked on. However, I was interested in doing the install from a pure usability standpoint. A linux user since 1996, a jack of all trades but master of none, I am always interested to see how thing improve/regress from the perspective of someone who’s neither n00b nor r00t..

As always, there is good, bad and ugly. Generally speaking, the upgrade went quite well — albeit i took a path slightly less traveled, opting to take a stab at it with smart, versus yum. But anyway, I did run into the same --noscripts (resolvable) issue as dgoodwin, as well as some other packages — so that’s something that definitely should be added to the FedoraFaq wiki. Also, it seems that the f8 kernel gets installed, but never makes its way into grub.conf — odd, and I now know I’m not the only one to have seen this. Anyway uninstalling it and reinstalling seems to be the easiest fix.

Generally speaking though, it didn’t seem like I had a lot of problems… home system upgraded like a champ… then hit the laptop… rebooted…

… and then I was stymied and still am. After rebooting, my monitor begins to display a message about the frequencies being out of range. WTF? Worse still, it seems that to get any working resolutions at all on my laptop display that are above 1024×768, i have no options other than widescreen-esque ratios. Attempting to fix these issues with system-config-display was a futile effort for two reasons — one, because every time I tried to change the monitor setting, it would say it was saved, but actually wouldn’t… and then when I jerry-rigged the xorg.conf to give me the resolution i wanted, X still wouldn’t cooperate — either causing my monitor to display the frequency error again, or popping up in the right resolution — say, 1280×1024 — for a brief moment before resetting to something odd like 1280×768.

I still don’t know what is/was causing it, but later on I noticed that I didn’t get it in GNOME, or KDE… only in Xfce — but I don’t know WTF the window manager would have to do with changing the resolution.

Anyway, after seeing that, I went kamikaze on my dot-setting directories, figuring I could just wipe everything out and get it to work — and that did indeed do the trick, albeit at the expense of some of my desktop settings. That said, I’m still not at all convinced that things are quite right with my Xserver.

Oh, and due in part to all of this — and in part to all the cool new GNOME stuff — i considered switching back to GNOME, if only for a time, as an alternative to a busted resolution. However, trying to make my first changes or two and getting segfaults all over the place with gnome-appearance-properties, i changed my mind pretty quickly. Maybe this will get cleared up (out there|on my box) eventually and I can reevaluate.

Generally speaking, though, I was pretty happy with the install experience — I just for the life of me can’t figure out what the hell is/was going wrong on the X end of things.

Update: Well, I noticed that livna once again (and most conveniently) has fglrx drivers. I know there had been issues in the past few months, and I am not sure when they finally fixed that — but in any case, i installed them, and my issue seems to have resolved itself. The plot thickens…

So today’s project was to figure out how to get two wireles routers to talk to each other. My wife has been complaining about the occasional drop in service to her laptop in the other room, and with the re-arrangement we’ll be doing here soon, the existing WRT54G will be even further away, I decided to drop the $$ to get another one and learn how to bridge them.

It wasn’t nearly as easy as I thought it would be, but after several attempts, I got it going.

Attempt one: Try bridging via a WET11 bridge I already had. In other words…

(Internet)–Modem ::eth:: WRT54G#1 ::wireless:: WET11 ::eth:: WRT54G#2

I thought, “huh, this bridge (WET11) can connect to my old router, I can just plug that into the outgoing traffic port on the new one, right?” I went ahead and upgraded my old router to a newer, cooler firmware. I chose HyperWRT Thibor, which turned out to be a pretty cool upgrade from my previous HyperWRT firmware.

After trying for quite some time, however — including trying to get the WET11 back to a usable state from whence it had previously existed in a modified configuration for another network — I gave up on that approach. Besides, the WET11 is only 802.11b, I think, so that wouldn’t be the most desirable configuration.

Next I decided to try what I found here. This didn’t seem to be too bad. I did download a new flash — but opted for DD-WRT instead of the Sveasoft crap they’d mentioned. For anyone reading, if you want to go this route, a flash different from the stock linksys firmware is required, as you need something else to give you a place to change the gateway address. Anyway, this took a while — upgrading the WRT54g v4 or higher requires, at least initially, a three-part flashing process. Afterwards, though, following those instructions were just as easy, and this gave what appeared to be:

(Internet)–Modem ::eth:: WRT54G#1 ::wireless:: WRT54G#2 ::wireless:: Wife’s computer

However, in reality the aforementioned configuration only grants wired access to the second router. In other words:

(Internet)–Modem ::eth:: WRT54G#1 ::wireless:: WRT54G#2 ::eth:: Wife’s computer

Now, this isn’t what I wanted either. So, trying to figure out what I could do, I began flipping through the tabs in the DD-WRT configuration panel when I found the help page for WDS (more info here).

And then the lightbulb went on.

From here, it was pretty easy following the instructions in the aforementioned DD-WRT help panel. The only caveats are:

• Read it carefully and follow the directions carefully to assure you get the wireless MAC addresses for each WRT54G — not the regular ones.
• Where the instructions say “Make sure you are using the same Wireless Settings on both routers” — you don’t want the same wireless settings, at least not down to the IP. Having both set to 192.168.1.1 didn’t work. Setting the remote one in the other room to something else did work, however.
• When linking the MAC addresses on two routers with the differing firmwares, it should be noted that the DD-WRT config does have a much nicer WDS page, more convenient help making it overall easier/more confident in set up, at least moreso than the Thibor. Regardless, as long as you paste the wireless MAC in the right place on the Thibor page, you shouldn’t have to worry too much.

In any case — things seem to be working well now. Plus, now I know how to set up WDS, so this should be easier in the future.

Oh, and re: DD-WRT, I will probably upgrade my old router (version 2) to it eventually, but I was noticing problems with Firefox during the all-important flash process on the new one. Not a time you want your browser to flake out, so swallowed my pride, used IE to configure the one in that room. Anyway, I’ll probably wait till they work some of those kinks out before I flash the old one to DD-WRT.

Last night I spent three hours of my life trying to figure something out. Three hours that I’ll never get back. Three hours on something that should’ve only taken five minutes.

Simply put: I tried to get network printing to work via CUPS. I did finally figure the finicky thing out… and hopefully people who are having the same problems that I did will see this and it’ll help em.
The Background: A few months ago, I took the printer connected to my wife’s old desktop and connected it to my Fedora Core 5 linux box. No problems there — printing worked just fine. I was unable to share it, however…. trying to connect to the printer across the network failed. I tried for a little while, to no avail. Meanwhile, I knew that years ago, at the old company, I had set up CUPS to access our network printers, and never had any problems… So last night, with new resolve, I tried again.

So tracing back, I thought of everything I had done. I made my changes to /etc/cups/cupsd.conf to allow remote connections… everything seemed kosher there. First thing I thought of doing that I know I didn’t do before was to open up a port on my local firewall. Specifically, port 631. To do this in FC5, I went to “System | Administration | Security Level and Firewall” in the user menu. At the UI, I went to “Other ports” dropdown and added “631″ TCP and UDP.

Such a simple issue — I surely thought I had resolved my problem. Trying to print returned nothing however — no jobs appearing in the queue. Looking at my error log, I found something akin to the following appearing everytime I tried to print from the remote computer:

Hint: Do you have the raw file printing rules enabled?

I no longer have the full error message readily available (it seems my CUPS log has already been truncated), but that’s the gist of it. So I looked up the message above on Google and found this page posted by an equally-frustrated person. I took his suggestions and made them on my own system. So, (Hint #1) make the following changes:

In /etc/cups/mime.convs, Uncomment…

application/octet-stream     application/vnd.cups-raw        0       -

In /etc/cups/mime.types, Uncomment…

mime.types:application/octet-stream

Fix them, and restart cups:

/etc/rc.d/init.d/cups restart

I actually made a mistake in here, but for continuity’s sake, I will indicate it at the end. You probably won’t make the same mistake and following the above steps may resolve your issue. But read on, regardless — there’s some other stuff you will want to know…

In any case, so I made the changes… still got the same error. So I start fiddling with the settings in CUPS. Running out of options, I decide to check out the Gnome printer configuration tool… and there’s what we will call Mistake #1: As I read elsewhere, find a tool and stick with it. If you use CUPS, don’t use the UI tool. They conflict with each other. Seriously – don’t mix this stuff at all. Before I knew it, my local sample print page output was nothing but one big black inky box, and everytime i tried to print anything, I got the same thing. Also, my print driver would never stay correct. So, in fact — I will recommend using yum (or yumex — it’s easier) to (Hint #2) completely remove the package system-config-printer. That is, remove that if you’re going to use CUPS all the time. If you use something else, you’re on your own. Also, if you’ve been promiscuous with your printer tools, you may find some of those uncommented lines recommented again. Fix them and restart CUPS.

Now — if you’ve gone and made the same dumb mistakes that I have, you’ll probably find that your print setup is in an overall pretty confused state. I resolved this by also (Hint #3) removing the foomatic package and reinstalling it. I was going to remove CUPS and reinstall it if I had to, but I didn’t — and thank God — CUPS is tied to way too much stuff in FC5 to easily remove it, although I guess you could manually rpm –force it. Regardless, uninstalling and reinstalling foomatic did the trick. Once again, you may check those files above to make sure they are uncommented, because while I don’t think foomatic messed with those, I can’t be sure right now. Anyway, you know the drill.

So at this point I am pretty damned sure I have things fixed. I go to the other computer, send a test page and… same error.

I was stymied and a bit frustrated. I began looking at all my stuff again, and then found the biggest idiocy of the whole issue. I had made Mistake #2: When you uncomment, be sure you actually uncomment. What I mean is — when I removed the ‘#’ I had somehow slipped a single leading space character amidst the newly fixed line in mime.convs.

One. Single. Space. I removed the space, restarted CUPS, and three hours later down the road, had out the issue resolved.

So there you have it. What should’ve been a simple configuration took several hours due to both mistakes on my part and idiosyncracies in Linux printing. I should also note, as a postscript, that while retracing my steps, somewhere along the way, the lines where I opened up in my firewall for printing got changed from referencing the port number (“631″) to the actual service itself (“ipp” – internet printing protocol). I am guessing this occurred during the foomatic fix..?

In the past few weeks, I have, with a little help, taught myself how to use CSS, cron, and have written several perl scripts.

The fruits of my labour? The beginnings of a document repository that looks promising. Sometimes, at work, when you have a vision (in my case, a cross platform, easily-accessible resource repository), you have to bite the bullet and do it yourself, create a quality mock-up, and show them what really needs to be done.

The day is almost over. She’s heading to the airport now, takes off around 5.00, and will be here around 6.30. Monday, we head to Beijing. Can’t wait for the weekend, and the weeks ahead.

Catch y’all on the flip side.