The sets have been returned in droves to Best Buy and other retailers because of the buzzing noise they make. After working with Samsung case management for my particular set for many months they are now firmly committed to saying the level of buzz is normal for plasmas and this set. I can agree its normal for this set, but its at least 100x worse than every other plasma Ive owned (4). Yes they all buzz, but generally less than 6 INCHES away. Ive now had 4 different B850/B860 combinations and they all can be heard from 10 FEET. This range appears to have an inherent design fault.

If you do decide to get one, please remember to return it directly to the dealer you bought it from as Samsung will not be able to fix the “buzz” you are hearing. If you are a dealer this might not be the best set to stock. If the buzz does not bother you, then great – the set is wonderful apart from the buzz (really).

This is what I had to go through to get to the situation where I have a buzzing plasma that Samsung will not deal with (taken from by BBB complaint which Samsung waited the full duration of time to respond to, and said “tough”).

Samsung is unable to resolve an issue w/ several plasmas I have had from them from 6/15/09. Long version here. Summary: 6/15 I bought a PN50B850 from Best Buy. It started “buzzing” & I could hear it in another room when volume was on! I have owned 3 different plasma brands and this is 100x worse (not normal). Returned 1st TV to BB & the 2nd arrived on 7/2. 2nd TV had same issue, could hear the buzz 15′ away. Called SS who sent repair dealer (tvunlimited). Claimed “its normal”. I escalate it & SS contacted a different repair center. On 7/24/09 tech tries to replace board but has wrong model. On 8/3/09 tech replaces 3 boards but buzzing got WORSE. On 8/14/09, cnet SS rep arranges replacing 2nd set w/ upgraded model. Unfortunately buzz still there. I have already installed the $$$ SS mount so I see if I can live w/ buzz. On 10/25/09 I decide I can’t. Called SS & they send tech w/ new fix, but tv ALREADY has fix installed. No change to buzzing issue. Called support & told they need to call the service center to check that the problem was “unrepairable” & they’d call back. They didnt. I call a day later & told tvunlimited should have set up appointment w/ me. I call tvunlimited & they said no fix for problem, it’s “usual” on these sets. I call SS again on 11/3 & they say need to contact someone in “product” & will call back. No callback. I have now had 4 different versions of the same set. SS never call back when they say they would (4) & not addressing the problem. The buzz w/ these TVs seems inherent design fault (not typical for plasmas). Widely reported across the web. Even cnet thread I started had 3 people returning buzzing sets.

Jonathan

So Im driving along, and my iphone chirps at me, I reach out and see that its a meeting reminder. Being lazy I drop the phone in my lap. A few minutes later it slides off to the side of my seat. Dang! I’ll pick it up later when I get home…

When I get home I can’t see the iphone ANYWHERE – its completely vanished… So I call it…. And the rest I’ll let my Flickr photos show you:

Its right in the middle of this photo, somewhere in the aircon vents, under the upholstery.

I can sort of see how it got there, but really, how likely is it that it somehow got behind one of these vents under my seat and managed to get into those iphone sized holes:

Off to the garage tomorrow to start taking the car apart….

Not so with my Nikon D60. Just over a month after getting it from Amazon the internal flash stopped firing. I went to their site, created an account to register my camera, and reported the problem. A few days later an email arrived saying send it to this address. I packaged it up, sent via Fedex for around $8, and waited. I wondered what was happening and followed up on my original ticket on their web site. I was promptly give a service repair tracking number and explained it was covered. About 10 days later after sending my Nikon off, a fixed D60 arrived on my doorstep.

The whole process was straightforward, easy to understand, and just worked as I imagine an issue like this should be handled (albeit with the extra request for the service repair ticket number to track the progress). Kudos to Nikon.

One of the new tables is pretty cool, as requested;) :

select * from microformats where url='http://wait-till-i.com'

Try it in the console, under “data”, or just run it from the public entrypoint directly.

Whats so interesting about the table, apart from the great microformat data it spits out, is the other meta information:

...
<language>english</language>
<rss>http://www.wait-till-i.com/feed</rss>
<format>text/html</format>
<size>30452</size>
<url>http://wait-till-i.com/</url>
<summary>
    <title>
        <type>default</type>
        <content>Wait till I come!</content>
    </title>
    <abstract>
        <type>default</type>
        <content>TTMHTM: The future of NASA 70s style, Microsoft Songsmith and why Starscream <b>...</b> Basted Tetris - A Tetris version that analyzes the playfield and denies you the <b>...</b></content>
    </abstract>
    <dispurl>
        <type>default</type>
        <content><b>wait-till-i.com</b></content>
    </dispurl>
    <fingerprint>
        <type>default</type>
        <content>3d4f995747df7c71</content>
    </fingerprint>
</summary>
<date>2009/01/12</date>
...

Intriguing eh?

They got a few edits into the document that I didn’t get a chance to look at over the xmas hols before it was published – so there are a couple of odd phrases here and there. However all in all I hope it gives anyone interested in using YQL a quick overview of what it’s all about.

• @var substitution from GET query string. YQL will “prepare” statements by replacing all @var literal values with the same named value in the query parameters. For example:

  http://query.yahooapis.com/v1/yql?name=dog&q=select * from sometable where name=@name


  Will result in the following statement being executed:

  select * from sometable where name="dog"
  
  

• (literal) sets. Literal arrays of strings or ints can be used in the IN () clause, for example:

  select * from social.profile where guid in ("1234","5566","123121");
  
  

• (field list) IN (select keys). The left hand side of an IN can how accept a list of fields in addition to a single field, and a sub-select within the right hand side of an IN can now return multiple scalars (from leaf values). The upshot is you can now join using multiple keys (not just a single one):

  select * from local.search where (latitude,longitude) in (select centroid.latitude, centroid.longitude from geo.places where text="north beach, san francisco") and radius=1 and query="pizza" and location=""
  
  

• Sanitize output. Added a ’sanitize’ post-select function that will attempt to sanitize the output for HTML safe rendering (stripping certain tags, cooking data etc). To sanitize the entire document:

  select * from atable | sanitize()

  To sanitize a specific field:

  select * from atable | sanitize(field='foo')
  
  

http://query.yahooapis.com/v1/public/yql?q=show%20tables

Unlike the oauth entrypoint, that requires oauth signing and so on, this one needs no signing, no app id, no nothing – just your query. Its that easy.

So you can just run it in a browser: show tables

… and go crazy! You can find upcoming events in North Beach sorted by start time, or get a list of Sushi restaurants with a 4 star or more rating in San Francisco.

A couple of caveats:

• this only gives you access to public data. If you want access to a user’s social network or other more personal info you’ll still need to sign things and go in through the oauth endpoint. So the social tables won’t show up in /public
• there are low rate limits on this endpoint. If you want a higher rate limit you’ll need to tell us who you are by getting a consumer key and secret from developer.yahoo.com and sign the oauth request.

The original poster wanted to get the forecast from the weather.forecast table for a non-US location. The table itself represents these types of location using a special key. For example, Prague (Czech Republic) is EZXX0012.

A followup post indicate that weather.com has a service that actually turns text-based locations (like “Prague”) into a list of possible location IDs that are suitable for the forecast table:

http://xoap.weather.com/search/search?where=prague

So now we have a great “join” situation, we can use one web service to join data in another completely different service and get the result we want for the inputs we have! So to get weather for all “prague”s in the world like this in YQL its a simple sub-select:

select * from weather.forecast where location in
   (select id from xml where
    url="http://xoap.weather.com/search/search?where=prague"
    and itemPath="search.loc")

You can see YQL run this query in the console (you’ll need a Yahoo! login to get to the page).

For real day-to-day use, the answer is you shouldn’t as any Javascript only technique inevitably exposes your shared secret. As with most secure APIs you should go via your own proxy to do the signing (use the PHP SDK or any other oauth library).

However, its still useful to “get going” and try things out away from the console and my colleague Paul has created some simple sample code for executing 2-legged oauth queries from javascript that enables you to call YQL functions without needing a server. Its as easy as:

var originalUrl="http://query.yahooapis.com/v1/yql?q=show%20tables&output=json";
var signedUrl = makeSignedRequest("[API Key HERE]","[Shared Secret HERE]",originalUrl);

For the most part you’ll probably be doing this using script node includes, so you probably want to add the callback parameter to the original url you want signing (you cannot add it afterwards as that will change the URL signature and invalidate the signed Url you have). You’ll also be exposing your shared secret, so you should only use this for testing and prototyping because if someone else copies it, you’ll need to get another one.

Note: the example is only 2-legged oauth. This lets YQL verify who the application is that’s using it, but not who the user is (which would be 3-legged). So it doesn’t bounce the page viewer anywhere (your users won’t even be aware of using YQL) and only allows the application access to public data. Thats still a lot of data, and enables you do some pretty powerful stuff

So check out his recent post.