Friday, November 13th, 2009
This is my title
This is my description.
Friday, February 6th, 2009
We’ve moved!
We’ve moved! We’ve decided to start blogging via Tumblr, which means that this particular version of the blip.tv blog will be abandoned. That’s not to say that we’ve changed our URL, of course. And our “legacy” posts won’t be removed either. Just make sure you’re visiting http://blog.blip.tv (our standard URL) instead of http://blog.blip.tv/blog/ (the legacy blog) and you’ll be all set.
Friday, February 6th, 2009
Success!
This morning’s upgrade was a success! Did you encounter any problems? Let us know.
Wednesday, February 4th, 2009
Uploads will be disabled temporarily on Friday, February 6th
In order to do some upgrades, we’re going to be suspending uploads from 7AM to 8AM EST this Friday. Any uploads that are in progress at 7 will likely be interrupted, so make sure you plan around this.
All other features of blip.tv will be working normally.
If you have any questions, please feel free to hit us up at our Get Satisfaction page.
Friday, January 30th, 2009
A farewell to adjacent ads
Newcomers to blip might not know that we once supported adjacent advertisements. These were similar to overlay ads, but actually ran outside of the player. Veteran blip users might be surprised to find out that we still technically support such ads. But that won’t be true for much longer. The few users who still use adjacent ads will find them turned off on February 3rd. These users will be moved to the overlay system, their logical successor. Anyone who wishes to adjust their advertising settings should visit our advertising dashboard. Anyone who has questions should head over to our Get Satisfaction page.
Have a great weekend!
Thursday, January 15th, 2009
Stats problems (again)
As those distinguished scientists Murphy and Finagle have observed, if something can go wrong, it will. After today, I’d be tempted to add that even if something can’t possibly go wrong, it will anyway.
We have a number of safeguards in place to protect the integrity of statistics, but unfortunately this has just encouraged the gremlins to become more ingenious. Early this morning, the system failed in a surprising new way. The immediate result was that view counts for recent days were inflated by about 7%; it also means that we have had to stop stats processing temporarily while we correct the numbers.
We are currently busy getting everything sorted out. While we straighten things out, you may notice some inconsistent numbers and your statistics for today will be delayed. As always, we apologize for any inconvenience this may cause you.
Monday, January 12th, 2009
Back in action after a long weekend
Some of you might have noticed sluggish behavior at blip this weekend. Others might have had trouble uploading. This was due to some very popular videos that popped up while we were doing an infrastructure upgrade and that led to unexpectedly high loads on our systems.
So, while it was technically a standard length weekend, it must have seemed much longer to Justin, who spent much of it making sure things were running smoothly. If you’re still encountering problems, please make sure you send an email to support@blip.tv. We’ll get back to you ASAP.
Oh…and Happy New Year!
Friday, January 2nd, 2009
Facebook cross-posting version 2.0
Okay our rewritten Facebook app is up and running. If you were using our Facebook integration before, you’ll need to refresh it at http://blip.tv/facebook. This version of the app publishes to your feed, so your episodes are sure to be noticed.
Monday, December 15th, 2008
Stats delay
For the second time in a couple weeks, we’re having a delay with stats. Please accept our apologies for this issue, and know that it’s a top priority for us.
The problem should be resolved tonight or tomorrow at the latest.
UPDATE: We’ve patched the underlying cause of the problem, and we anticipate having all data updated by midnight eastern time tonight.
About three months ago we changed the way we processed stats. Instead of recording a view in the database every time a video was watched, we wrote all views to log files and processed the log files every half hour to hour. We did this primarily because it was more efficient. Our traffic has grown a huge amount since our statistics system was initially designed, and this new process allows us to manage much larger quantities of data while making video viewing faster and making stats retrieval faster for content creators. The new statistics system, designed to work with log files instead of video view requests, is called Jasmine.
Jasmine has been handling our statistics for some months now and has generally been doing an excellent job. It’s super fast, and extremely accurate.
Unfortunately, any time you start using new software for very important things you run into glitches. You can anticipate some glitches, but there are always unanticipated problems that catch up. The good news about systems that use log files, though, is that there’s always an indelible record of the real data. Even if Jasmine screws up, the underlying data is already there. We have the technology. We can rebuild it.
So far we’ve had two problems with Jasmine.
The first problem happened ten days ago. In that case Jasmine “missed” a set of log files on a particular set of our servers. We discovered the underlying cause of the problem and built a set of counter-measures to make sure that the problem couldn’t happen again, and that if it did we would know about it right away.
This second problem is caused by a rather silly little bug. We recently changed the way we manage log files in order to ensure that we’re preserving data for longer. We actually did this because of the first problem with Jasmine that we experienced on the fifth — we wanted to make sure that if Jasmine had a problem that went undetected for a while that we’d be able to recover data from a long time ago. So we changed things to save log files longer. This was one of the action items that came out of our post-mortem meeting on the fifth, and a result of our Kaizen approach.
Unfortunately, by keeping logs longer, we found a new problem with Jasmine. A single line of code — out of thousands — caused a problem when sorting through large number of log files. And that’s what’s caused today’s problem. We’ve patched the underlying code — Jasmine can now deal with an infinite number of log files — and we’re cleaning up the damage. In about forty-five minutes Charles and Angus will be cleaning up Jasmine’s data from yesterday and today, and then will re-run Jasmine fresh.
There will probably be new problems that come up with Jasmine. But, ultimately, it’s a good thing that we have it. And it’s pretty safe in the long-term. While we may have another problem — maybe even a few more problems — like the one we’re having today and the one we had on the fifth, Jasmine will allow us to scale the blip statistics service far beyond where we were able to scale it previously.
Thank you for your understanding and your patience. Please let me know if you have any questions. Feel free to e-mail me: mike AT blip DOT teevee.
Credits and stuff
Copyright © the blip.tv blog | Powered by WP 1.5.1.2. | Tree by Headsetoptions and MandarinMusing a minimal theme based on HyperBallad Back to Content