Archive for July, 2009

Why do Google Search Results Change?

I was recently asked by my wife why Google search results change. I had noticed it before but didn't spend much time dwelling on it because my first thought was that Google uses many locations and many datacenters to hand out search results. The varying results are differences in the data stored at each location. Depending on which datacenter you are getting results from at any given time, you can see a huge change in results. As an example to this I made a quick video to show how going through a proxy server can change search results.  In this video I'm going through a Linux server in Texas at first. Note the total results for the keyword while going through the proxy are 282. By removing the proxy and refreshing the search the number changed dramatically to 635,000 results.

I saw a video explanation of this behavior that stated that Google was a beach, and while I enjoyed the analogy, it isn't entirely correct. There is a lot happening on the internet, but there's no way Google can index it all at once, or even catch it all. That's why they have many data centers, each pulling their own part of the weight. I'd imagine that the synchronization of the data takes time, that is if they actually synchronize the data at all. It may be that Google does this to randomize search results a bit in order to gauge relevancy of each result. At any rate, the keyword results can vary.

Also, after making this video, I captured the packets using wireshark and found that the request from my home internet connection was querying IP and my proxy server is pulling the query from Also neither of the search results were correct. After digging into the other pages of results there is a total of 64 results omitting the repeats. ICHY reports that the keyword has 3,640 competition. So, from what I can see of the data on both sides, ICHY doesn't report very accurate competition numbers according to their own explanation of the relevant results. Other keywords in their list yielded similar results discrepancies.


, ,

No Comments

Adventures in analog video recording on Linux

Linux does many things well, but the multimedia experience can be lacking without the correct bit of hackery. I mean, some cool things can be done with Linux on the multimedia side, but typically it'll take a lot of work to learn how it's done. Mac and Windows make complex things simple, while Linux makes simple things complex.

Back when I purchased my TV tuner card for my PC, I was using Linux as my main OS. I still use it daily but not on my main PC. Only occasionally do I boot to Linux on it. I typically run Windows Server 2008 as I've talked about on previous posts. When I bought the tuner I wanted to make sure that it worked under Linux. So, I purchased one that was made specifically for Linux, a PCHDTV 5500.

It has served its purpose as a TV tuner, since I watched a year or so of cable TV in analog on it prior to the digital switch. I have never been able to get the HD side of things to work on it. Either it's beyond me or my cable company just had all of the channels encrypted. I didn't spend enough time on it to find out.

Recording analog video in Linux can be FUN. By "fun" I mean the type of fun one has pulling their own toe hairs. Be forewarned, getting a good recording is best done from the command line. I tried many ways. I ended up going with mencoder.

That being said, there's not much you can't do with mencoder and ffmpeg from the command line.

I have some VHS recordings I'm converting to AVI and then later on to DVD. I first had to purchase a VCR because, wouldn't you know it, I didn't have one that worked.

After that I had to come up with a good way to connect it to my capture card. The card has coax and component inputs. The new VCR didn't come with any coaxial connections. The capture card had a yellow RCA connection for video. I could use that but then there was the problem with audio. The capture card had a 1/8" jack for audio. Luckily I had an RCA-to-1/8" adapter for one of my gadgets (not sure which). I ended up using two sets of RCA's.

I was amazed I actually got audio and video from it. Here's where more fun came in. I was running virtualbox in the background. Everything I tried to use to record the video told me that /dev/dsp could not be opened. I went through many hoops trying to troubleshoot that issue. I should have realized it sooner but it was all virtualbox's fault. Next time I'll make sure it's not running when I'm dealing with audio.

After all of those problems were worked out, I was able to use:

mencoder tv:///1 -tv driver=v4l2:width=640:height=480:forceaudio:adevice=/dev/dsp -ovc xvid -xvidencopts bitrate=-750:threads=2 -oac mp3lame -lameopts cbr:br=64:mode=3 -o /home/five/homevid.avi

I'll try to explain some of what is going on in that command. Mencoder is the program itself. There's little to be said there. The next part is interesting: tv:///1  That tells mencoder we are using the tv card and that we want to use the composite1 input. Typically it defaults to input=0 or tv:///0, which is the coax TV input. There are three inputs on the card: tv, composite, and s-video. The next part (driver=v4l2) tells mencoder that we want to use Video4Linux2. Then we specify the width and height of the capture. The forceaudio bit was placed there during my troubleshooting. It just forces the use of audio device /dev/dsp. I had tried a couple other devices during my troubleshooting, thus the addition of that option. Then we have the option for output video codec (xvid). I set the bitrate and the number of threads. I actually upped that bitrate considerably later to around 2048. I believe I'll end up upping it even more for the next vid. I did the same with the audio output bitrate. I set it up to 256.

That should help anyone experiencing some of the pain I went through.

, , , ,

1 Comment

Slow wifi on iPhone 3GS