December 6th, 2001

'show email on profile' option unchecks itself

Hi, I'm having an odd problem which is irritating (though not amazingly important). I first posted this in /support, and I was advised to post it here instead, so here goes:

As a paid member I like to take advantage of the fact that I can show my livejournal email address on my user profile without showing my private email address. However, every time I go to /editinfo_do.bml the box next to 'Show your contact information on your LiveJournal?' is unchecked, even though I definitely had my email address displayed on my profile. If I don't recheck the box, then no email address is shown on my profile after I click 'save changes'.

I edit my profile often enough that this little bug is beginning to annoy me. Is there anything I can do to stop it happening? Thanks in advance.

Network connectivity issues for @home and for

Hey folks;

From what I can tell, there are some routing issues to @home, and to The following are two traceroutes to from a server I manage, and from my home network. From home, I can reach just about everywhere but livejournal, and for that, I have to set up a proxy server on another box.

Can someone take a look at this, or at least point me to the right folks?

Here's the traceroute that breaks:

Tracing route to []
over a maximum of 30 hops:

1 1 ms 1 ms <10 ms
2 48 ms 20 ms 121 ms []
3 18 ms 57 ms 29 ms
4 15 ms 33 ms 22 ms
5 64 ms 31 ms 44 ms
6 41 ms 29 ms 44 ms []
7 110 ms 53 ms 28 ms []
8 51 ms 44 ms 51 ms []
9 61 ms 41 ms 73 ms []
10 42 ms 51 ms 59 ms []
11 * * * Request timed out.
12 82 ms 86 ms 44 ms [
13 * * * Request timed out.

And here's the one that works.

traceroute to (, 30 hops max, 38 byte packets
1 marcus ( 0.474 ms 0.477 ms 0.444 ms
2 ( 2.226 ms 2.154 ms 2.245 ms
3 ( 2.242 ms 2.274 ms 2.306 ms
4 ( 2.825 ms 2.637 ms 2.693 ms
5 ( 86.288 ms 86.018 ms 86.014 ms
6 ( 85.987 ms 85.982 ms 86.229 ms
7 ( 87.378 ms 87.332 ms 87.377 ms
8 so-5-3-0.XL1.CHI2.ALTER.NET ( 87.736 ms 87.594 ms 87.538 ms
9 ( 87.711 ms 87.746 ms 87.735 ms
10 ( 79.722 ms 79.660 ms 79.602 ms
11 ( 83.127 ms 83.050 ms 83.114 ms
12 0.POS5-0.XR1.SEA1.ALTER.NET ( 83.099 ms 82.795 ms 83.000 ms
13 195.ATM4-0.GW8.SEA1.ALTER.NET ( 82.991 ms 82.987 ms 82.988 ms
14 ( 83.531 ms 83.337 ms 83.696 ms
15 ( 83.368 ms 83.607 ms 83.354 ms
16 ( 83.360 ms 83.456 ms 84.072 ms

It looks to me like it's either livejournal or pnap that's breaking.
hulk, strong, party
  • revjim


I'm working on a syncitems client and am seeing a bit of odd behavior.

According to my userinfo page, I have 1,004 journal entries. But syncitems is giving me 1,043 unique items.

I tested it on another account with far less entries (8) and it works fine.

I also tested it with the "test" account. The userinfo page claims 1,358 entries, while syncitems returns 1,431. (Due to a bug in my XMLRPC libs that I have yet to hunt down, I am unable to retrieve all the entry id's for the test account to ensure that they are indeed 1,431 unique items being returned.

BTW- When I say "unique" I mean that the syncitems "item" values are unique. You know, the "L-1232343" value.

One thing that does seem to be correct is that the number of items syncitems claims there are in total is equal to the number of unique items I receive.

Perhaps the userinfo page is incorrect, only updated occasionally, or is not counting private or friends-only posts?

I haven't researched the data heavily, as 1,043 items is a lot to deal with.

Any ideas?
hulk, strong, party
  • revjim

more syncitems problems...

While performing more tests on syncitems's odd behavior I have found something VERY interesting. It appears that the syncitems call and the call to getevents with a "selecttype" of "lastsync" returns different items.

In order to test, I used the "test" user account. I requested syncitems with no time sent, and LJ returned the first 500 items. I then requested getevents, again with no time sent, and LJ returned 300 items. Then I compared the two arrays.

For every itemid that was returned by syncitems but not by getevents I requested it manually using getevents with a "selecttype" of "one". If the server returns no data, then I know the item has been deleted. Otherwise, it is an item that should have shown up but didn't. Then I compared the itemids returned by the getevents call to the ones returned by the syncitems call to see which items were returned by getevents that were not even mentioned in syncitems.

The results from the first call (the first 500 items) of the "test" account are as follows:

Deleted Items: 0
Items in SYNCITEMS but not GETEVENTS: 200
Items in GETEVENTS but not SYNCITEMS: 0
Total SYNCITEMS: 500
Total GETEVENTS: 300

Something isn't right. Shouldn't getevents return the same number of items as syncitems?

Y2K bug? ;-)

Just got an amusing little email...


Greetings from LiveJournal!

First off, I wanted to thank you for being a member. I also wanted to let you know that your membership expires on 1999-03-21.

In that case, the account expired long before I created a free account back in August, and even longer before I went paid in September. The date should be 2002-03-21, and my user info gets it right.

Is this the right place for this? Or is there something like lj_bugs as part of the secret network of lj_communities?
hulk, strong, party
  • revjim

syncitems bug....

The times returned by syncitems are being returned in 12hr time but without an AM/PM indicator. This should most likely be converted to a 24hr time, or alternatively, an AM/PM indicator should be added.

NOTE: This may be due to the time STORAGE and not the time RETRIEVAL for the syncitems data.
  • msram

(no subject)

I come from here (Please read it)

I was wondering if there is a way to pass only selected JavaScripts such as that of BlogSpan. Maybe it can be customised using an LJ-specific code like <lj blogspanid="nnnn">

Security — I believe security concerns are irrelevant here as the code is "approved" by LJ and the only control that the user has is the userid. The code by itself is just a script to dynamically call a piece of text from BlogSpan. Totally harmless.

Load — I doubt if this will result in an extraordinarily high server load due to increased traffic.

Benefit — LJ users can discover other journals and other non-LJ users will discover theirs. This is all in the spirit of growing into a community.