My point to you is the following. I looked very carefully through all of your “Annotation Problem - 3rd Party Software” type of problems and the next three are bogus.

Breyer vs K Havasi, 1918
Hort vs A Rodriguez, 1987
R Kempinski vs Epishin, 2001

Try loading them in different chess software and you will, hopefully, see that there’s nothing wrong with the PGNs. Probably, one source of confusion is the <lack of a delimiter> between the move and annotations. The PGN standard clearly specifies that no such delimiter is required. That’s a bug in the parser you were using. Another possible confusion comes from the fact that <more than one annotation> follows a move. Little known but that’s perfectly allowed by the PGN standard. That’s another bug. In case of CVD, double-annotations are not only supported and presented properly (see move 140…Bd8 in the third game) but also preserved during export (Copy Game).

And your blog is worth checking out; a whole New World is opening up to me, not kidding. Very neatly organized... Bookmarked!

It’s still the same world of chess but I agree that the live relays on my blog have a flavor of their own. I never liked the lack of features in the official live broadcasts not to mention their varying performances. One of my goals was to make my live relays more reliable and less vulnerable to server breakdowns.

* Use ECO=960

* If ECO=960, skip position check of kings and rooks prior to castle

* Other permissions verified as per usual (unmoved, unattacked, etc)

* for backward tracking, consult original FEN rather than built-in start position for how to undo a castle

* Seems like this wouldn't take more than 1-2 hours of recoding/testing.

*Result: with a small change to each PGN (sdding ECO=960) Fischer Random games can be played with the Deluxe Viewer.

* How are you going to convince the whole world to use your approach?

IMO, what we need is a standard way of sharing Chess960 games that <everybody> agrees on and everybody is going to use in the future. After that we can use any Chess960 viewer to show the games. Moreover we already have the PGN to start from.

* How hard is this task?
* Why hasn’t this issue been resolved for so many years?

You may be right about one thing, though.
It seems that a lot of effort is wasted trying to prove how easy the solution is. I’ve even read suggestions that show little understanding of the basic PGN principles.

If I’m to produce a quick (and easy to do) idea of mine I’d say:

* Let’s drop the ridiculous <which-game-is-superior> contest and forget about the artificial compatibility.

Adding the ECO=960 edit step before pasting would have to be done manually in each and every PGN case, but would at least make the viewer usable in this arena anyway.

I understand--now--that anything you undertake, you would want it to be "ANSI-approved" if not globally accepted. Definitely a legitimate desire.

First, the overall software architecture of my live relays is very modular. The CVD’s version used there is exactly the same (ver 3.5) used here on CG.com and all the relay work is done by the “TFD Proxy” module (on a separate server). That fact isn’t so obvious and people might be confused thinking that CVD has some special relay functionality in it.

The idea of “TFD Proxy” was born in my head (about a year ago) after witnessing numerous failures of official broadcasts based on the DGT’s software. We all have seen those followed by some lame excuses about “server overloads”. The truth is that by its original design their application it prone to scale badly. In addition, I haven’t seen any improvements in the way live broadcasts are presented for a very long time so my hope that somebody will address the issues was fading quickly.

One of the earliest appearances of “TFD Proxy” was in mid-march http://chesstuff.blogspot.com/2009/.... Later I kept improving it Viewer Deluxe chessforum and nowadays we have a grown-up version with a long list of advantages. Here is just a few:

1) It acts as a true proxy and only downloads from the server games which have been actually modified (with new moves, times, etc.). Shortly, if some 1000 users are watching via “TFD Proxy” the official server will only be bothered as if a single visitor is watching via DGT’s interface;

2) It is very robust and not so vulnerable to server’s downtime. For the duration of a live event the official servers can (and will – see above) become unstable. Most of the brief problems caused by the official servers are resolved by “TFD Proxy” and the latest states of the games will be available until something newer comes in. Shortly, the user’s experience should be much improved;

3) In very persistent situations, where one of the servers has been non-responsive for a long time, a meaningful message will be produced to notify the end user. The opposite is (oh, so familiar) the hanging/frozen application and the look and feel of “I have no idea what’s going on!”. In other words, in such situations no news would be definitely bad news.

Most users don't realize this but many of our live broadcasts are performed by an employee watching a board and typing in moves as he sees them appear. It's a crude, demanding, and error-prone process. That is the reason why we don't have live chess broadcasts except for a few times a year.

It is our opinion that the method of live chess broadcasting that is common these days needs to be vastly improved. The simple solution is that for high profile chess events, there needs to be two servers. The first server can be for the general public which can and probably will crash when a million chess fans all excitedly press "reload" continually on their browsers. The other server could be for sites like Chessgames which should be given the red carpet treatment. This secondary server could have a password or some other authorization scheme, and therefore only be accessed by a small group of authorized people. When we say that we should be given the red carpet treatment, that's not hubris--it's just common sense. We read from their server ONCE in order to disseminate those data to thousands of people. Therefore our request truly is thousands of times more important than the average request.