‘Waiting for TypePad…’ is a phrase I have now memorized when it comes to publishing posts to any of my blogs. This last week has been exceptionally frustrating.
I write posts offline using ecto for Windows, currently version 1.7.5, and publish them to TypePad. It should work, but it doesn’t.
What’s been happening is that, on average, about two posts out of five don’t publish correctly usually due to a server time-out or data-receive error. That’s generally been the case for many months. It means I then have to log in to TypePad and re-publish from there. A real pain.
This past week, though, such errors from TypePad have been the case with every single attempt at publishing a post.
Today it’s worse – when I start ecto and it checks in to the TypePad server to refresh the published blog entries within ecto, it gets a server time-out or data-receive error. So well before writing and posting, there are server time-outs.
The ecto error log shows one of these phrases in every entry:
System.Net.WebException: The operation has timed-out.
System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive.
While I’ve asked TypePad Support about server time-outs before, I’ve sort of lived with these errors as they haven’t totally prevented me from posting. Until now. It’s got beyond purely a pain – this is massive frustration.
I posted a TypePad support help ticket yesterday. No reply so far, although it’s only 24 hours.
What is going on here?
In discussion a few weeks ago with Alex Hung, one of ecto’s developers, in the ecto Windows support forum, he wondered whether there may be issues with TypePad’s servers (overloaded) or that my blog databases are too big. I have no idea!
All I know is that whenever I use this software tool (ecto) to publish content to my blogs, it either doesn’t do it properly or doesn’t work at all. Is this an ecto issue or a TypePad problem? I have no idea, although I’m pretty sure it’s more likely a TypePad issue – other ecto users are reporting similar issues with TypePad.
I wish someone could simply say "yes, this is a problem and here’s how it is being fixed" with the fix either being something TypePad has to do, or ecto has to do, or I have to do. Or some mixture of the three of us. I really don’t care who has to do it – let’s just fix this damn thing.
I’m not writing this post in ecto, by the way – pointless at the moment. I’m not writing it in TypePad, either – when I click on the ‘save’ button in the edit window, all I stare at for ages is "Waiting for www.typepad.com…" in my browser status bar.
So I’m writing it in NoteTab Light, a really good plain-text editor that also has very good HTML capabilities, which I’ve used for years for plain-text editing. I can add any HTML code and then paste the content into TypePad’s editor in HTML mode.
Hmm, maybe this is what I should stick with.
Does this post read like a rant? Well, I guess it is one.
Hi Neville
I wonder if at least part of this is down to your own site. If you run Nevon through the speed check at http://www.websiteoptimization.com (it’s on the Firefox developer’s toolbar) you’ll see a lot of red flags.
Some examples:
* TOTAL_OBJECTS – Warning! The total number of objects on this page is 77 – consider reducing this to a more reasonable number.
* TOTAL_IMAGES – Warning! The total number of images on this page is 68 , consider reducing this to a more reasonable number.
* TOTAL_SIZE – Warning! The total size of this page is 258972 bytes, which will load in 52.01 seconds on a 56Kbps modem. Consider reducing total page size to less than 30K to achieve sub eight second response times on 56K connections. Pages over 100K exceed most attention thresholds at 56Kbps, even with feedback.
* TOTAL_SCRIPT – Caution. The total number of external script files on this page is 6 , consider reducing this to one or two.
* HTML_SIZE – Caution. The total size of this HTML file is 29297 bytes, which is above 20K but below 100K.
* IMAGES_SIZE – Warning! The total size of your images is 173794 bytes, which is over 30K.
* SCRIPT_SIZE – Warning! The total size of external your scripts is 39210 bytes, which is over 8K.
* CSS_SIZE – Warning! The total size of your external CSS is 16671 bytes, which is over 8K.
Hope that’s useful
Cheers
Neil
Neil, this does not have anything to do with Neville’s site. TypePad is run by a database, not by posting snippets into html files.
I am having the exact same problems on a TypePad blog that I co-author. Let’s all hope it will all be well, but a matter of fact is that I have been experiencing this ever since I started blogging with TypePad in the beginning of March.
Using the web interface is no help, it’s even slower. Much slower. A Six Apart fellow should comment on this – here.
ecto for Windows 1.7.5 and TypePad connection issue
TypePad has implemented some changes on their server last Friday and the result is that ecto for Windows will no longer connect successfully to the server. I’ve implemented a fix for this problem and I highly recommend all TypePad users…
ecto for Windows 1.7.5 and TypePad connection issue
TypePad has implemented some changes on their server last Friday and the result is that ecto for Windows will no longer connect successfully to the server. I’ve implemented a fix for this problem and I highly recommend all TypePad users…
Neville, sorry you’re having these problems. Because I haven’t heard of a large number of people having these issues, I’m guessing it may be either something specific to Ecto or to your configuration. I’ll try to get in touch with our server team and see if they can find any reason this would be happening.
Have you filed a help ticket on this issue?
Hey Neville,
Alex, the author of ecto for Windows posted a little about the issue earlier today: http://ecto.kung-foo.tv/archives/001439.php
Definitely check out the development build he talks about in that post – it should fix the issue you’re seeing.
I’ve had no problems posting with Blogjet but have noticed the TypePad web interface is slow managing comments etc
Thanks for your comments, everyone.
Anil – yes, I had posted a help ticket on Saturday. I’ve now heard back from Support so we’re in touch on the issue. Thanks for dropping in here.
Neil – that’s an interesting notion. I agree with Jacob, though, that I can’t see how the public site (the blog you see) would be affected when I’m connecting to a separate offline server. (Unless someone from TypePad says it is so.) Content from there then gets published live. The issue’s more to do with the initial connection with the TypePad editing server, not with the live blog server.
Nevertheless, you have a good point re load times for this blog and the graphics. There are lots of of them, all small but collectively they add up. Must be frustrating if you visit on a dial-up connection. Something I will look at from the design point of view.
Nick – thanks for the tip re ecto 1.7.6. I had downloaded it and installed it. Unfortunately it doesn’t run due to some other error which I’m in touch about with Alex Hung.
Robin – I sometimes use BlogJet as well but, frankly, I don’t like it as much as ecto. The interesting thing with this app is that it connects just fine to the TypePad servers. I’m using version 1.5.0 build 37.
Hmm, that adds a bit of complexity to this situation, from my user point of view. If BlogJet can, why can’t ecto? So is it really just a TypePad issue?
The developer build 1.7.6 that ecto just released says in the history notes that among the fixes are a new registry key to allow a user-configurable network timeout setting, and “fixed connection problem with TypePad.”
But as I mentioned, I can’t run this dev version yet. If anyone has, I’d love to know if it’s successful at connecting properly.
ecto for Windows 1.7.5 and TypePad connection issue
TypePad has implemented some changes on their server last Friday and the result is that ecto for Windows will no longer connect successfully to the server (ecto for MacOSX will work as usual).I’ve implemented a fix for this problem and I highly recomme…
Hi Neville; sorry you’re having problems. I’m using ecto and posting to a number of TypePad blogs on a Mac, and everything works like a charm — I write a couple of blogs for companies, and I’ve had no problems posting many times a day.
I did try ecto on my Windows machine a few weeks back, but didn’t like it.
Hope you get it sorted. In the meantime, thanks to you and Shel for your podcasts and blogs. They’re terrific.
Hi Neville, sorry for waking up late, we have no support issues here in Europe for similar problems and I have been posting using Ecto OSX with no problems in the last weeks, weird.
Seeya soon, Loic
Angela, thanks for saying nice things about the podcast and blogs!
You and Loic use ecto for the Mac, which is quite a different app to the version for Windows. Far superior, from what I hear from ecto Mac users. One thing about the Windows version is that it requires Microsoft’s .NET Framework to run. I’m not saying that’s anything to do with the connecting with TypePad issue, but it appears to be something to do with why I still can’t get the latest dev build to run on any of my PCs. So I’m using BlogJet meanwhile which connects to TypePad without any difficulty. And one difference, by the way, between BlogJet and ecto for Windows – BlogJet doesn’t need .NET, it’s a native Windows app.
Loic, the server time-out and other issues really are quite serious. TypePad proxy server gateway timeouts today, for instance, during a publish – that is very alarming.
I’ve been in communication with TyepPad Support since Sunday, answering their questions and hopefully helping them get closer to a solution. It does look very much as though a central character, so to speak, in all this is the size of a blog and how that directly affects the editing and publishing process. It appears that this blog is of such a size that there are back-end issues. I don’t know any of the technical details here. What I do know is my other blog is probably a tenth the size of this one – and there are no issues in publishing with that blog.
I know the Support team is trying to find a solution. I hope they are successful very quickly.