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.
From what I can tell, there are some routing issues to @home, and to attbi.com. The following are two traceroutes to www.livejournal.com 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 www.livejournal.com [188.8.131.52]
over a maximum of 30 hops:
1 1 ms 1 ms <10 ms 192.168.1.254
2 48 ms 20 ms 121 ms 12-232-196-1.client.attbi.com [184.108.40.206]
3 18 ms 57 ms 29 ms 220.127.116.11
4 15 ms 33 ms 22 ms 18.104.22.168
5 64 ms 31 ms 44 ms 22.214.171.124
6 41 ms 29 ms 44 ms gbr6-p30.sffca.ip.att.net [126.96.36.199]
7 110 ms 53 ms 28 ms gbr4-p30.sffca.ip.att.net [188.8.131.52]
8 51 ms 44 ms 51 ms gbr3-p50.st6wa.ip.att.net [184.108.40.206]
9 61 ms 41 ms 73 ms gbr1-p100.st6wa.ip.att.net [220.127.116.11]
10 42 ms 51 ms 59 ms gar1-p360.st6wa.ip.att.net [18.104.22.168]
11 * * * Request timed out.
12 82 ms 86 ms 44 ms border6.ge3-1-bbnet1.sef.pnap.net [22.214.171.124
13 * * * Request timed out.
And here's the one that works.
traceroute to www.livejournal.com (126.96.36.199), 30 hops max, 38 byte packets
1 marcus (188.8.131.52) 0.474 ms 0.477 ms 0.444 ms
2 pao-berk-ds3-1.pao.winterlink.net (184.108.40.206) 2.226 ms 2.154 ms 2.245 ms
3 dix-fe.pao.above.net (220.127.116.11) 2.242 ms 2.274 ms 2.306 ms
4 sjc2-pao1-oc48-2.sjc2.above.net (18.104.22.168) 2.825 ms 2.637 ms 2.693 ms
5 ord2-sjc2-oc48.ord2.above.net (22.214.171.124) 86.288 ms 86.018 ms 86.014 ms
6 core3-core2-oc48.ord2.above.net (126.96.36.199) 85.987 ms 85.982 ms 86.229 ms
7 uunet-abovenet-oc12.ord2.above.net (188.8.131.52) 87.378 ms 87.332 ms 87.377 ms
8 so-5-3-0.XL1.CHI2.ALTER.NET (184.108.40.206) 87.736 ms 87.594 ms 87.538 ms
9 0.so-1-0-0.TL1.CHI2.ALTER.NET (220.127.116.11) 87.711 ms 87.746 ms 87.735 ms
10 0.so-7-1-0.TL1.POR3.ALTER.NET (18.104.22.168) 79.722 ms 79.660 ms 79.602 ms
11 0.so-6-0-0.XL1.SEA1.ALTER.NET (22.214.171.124) 83.127 ms 83.050 ms 83.114 ms
12 0.POS5-0.XR1.SEA1.ALTER.NET (126.96.36.199) 83.099 ms 82.795 ms 83.000 ms
13 195.ATM4-0.GW8.SEA1.ALTER.NET (188.8.131.52) 82.991 ms 82.987 ms 82.988 ms
14 internap1-gw.customer.alter.net (184.108.40.206) 83.531 ms 83.337 ms 83.696 ms
15 border6.ge3-1-bbnet1.sef.pnap.net (220.127.116.11) 83.368 ms 83.607 ms 83.354 ms
16 livejournal.com (18.104.22.168) 83.360 ms 83.456 ms 84.072 ms
It looks to me like it's either livejournal or pnap that's breaking.
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.
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?
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.