– Fantasy Stat Tracker …Tracker

A blog about the development of – The Fantasy Baseball Stat Tracker

Posts Tagged ‘xml’

Spring Training Stats

Friday, April 5th, 2013

I’ve been getting a flood of emails about spring training statistics showing up for players that haven’t played in the big leagues yet this year. collects all of its stats for an XML feed that MLB publishes. Every time you request the stats for your team(s), checks to see what the latest stats are and loads them into the system.

Unfortunately, it seems that MLB leaves springs stats listed for all players that appear in the spring but are then sent to the minors (or DL). Until they appear in a big league game, MLB will continue to show springs stats in their feed.

This is just how it works.

If you have a player on your team that is showing spring stats, please move that player to your bench. The player’s individual stats will still show from spring, but this will remove the player’s stats from your team totals.

That’s a wrap!

Monday, October 29th, 2012

The 2012 baseball season has come to a close. As such, will no longer be sending out daily box score emails.

It’s been a tumultuous year for In particular, we experienced a lot of accuracy issues with our data source (free published XML feeds) and I heard more than ever about the lack of this stat or that stat.

I stopped using for my personal needs a couple years ago (I originally built it as a personal tool). Going into 2013, I’m on the fence as to whether to continue maintaining Obviously there are costs associated with keeping the servers up and running (thanks to all of you that have donated to help cover hosting costs!), but even more important is the time it takes to field email questions and comments, fix things when they go wrong, and monitor the performance of servers, databases, and email services. We’ll see how that goes in a few months when the excitement of a new season ramps up.

In the meantime, keep your chins up. Baseball is only a few cold months away!

Missing and Delayed Player Stats

Sunday, August 19th, 2012

Over the last few days I’ve received a lot of emails about not properly updating some player’s stats. Reports include missing stats, delayed reporting of stats, and out-dated season stats. I’ve not been able to investigate every report (timeliness is obviously critical in a real-time stat tracker!), but in each instance I’ve been able to check, the MLB data source is, in fact, reporting the incorrect, incomplete, or out-dated states.

Unfortunately, there is nothing I can do about the incorrect stats feed. This is one of the down-sides of using a free, unsupported stats feed. We just have to live with whatever it provides us.

It seems like most people have had success checking later in the evening or first thing in the morning. Hopefully that will suffice in getting everyone the stats they need.

With any luck, there is just a glitch in the stats feeds and they will right themselves soon. In the four or so years has been up and running, though, I haven’t seen this happen before, so I’m not quite sure what to expect.

I love Kilgus! Can you include [STATX]?

Friday, April 6th, 2012

This is by far the most common topic when people email me about I’m thrilled that so many people are enjoying the tool (we start the year with over 1800 members, nearly 500 users per day), but these are bummer emails to receive.

Unfortunately, 95% of the time the answer: No, sorry.

As a free tool, needs to rely on whatever free stats we can find. As it turns out, MLB publishes some limited live data (I believe for their GameDay feature) that we’ve been able to tap. While it is great that the data is free, the bummer is that it isn’t comprehensive. is already pulling every stat available from MLB and even calculating a whole series more that aren’t made available in the data feed.

If you’re favorite stat isn’t included, it’s almost certainly because we just don’t have access to it. At the start of each season, I double-check the feeds to see if any new stats are available. This year, there is nothing new.

So, if there is something that can be calculated with the data already in, let me know and I’ll be happy to add it! If you want a new counting stat added, though, I can’t add it.

Maybe someday an angel investor will throw a pile of money at and we can afford to purchase a real data feed (~$25k/year). Until then, we just have to make due with what we have.

Hopefully it’s enough to be useful to you!

(That said, don’t forget to click “Select Stats” for each of your teams to see all the stats that are available: currently 32 categories!)

Internet Explorer Sign-up or Log-in Bug

Saturday, May 7th, 2011

Over the last couple weeks, I have received numerous emails from people having trouble signing-in to their accounts. With a little digging I was able to find a consistent theme: they were all using Internet Explorer 8 or 9.

Specifically what was happening was that a person would type their existing username into the sign-in form and would then be prompted to create an account. As everyone is probably aware, uses the same form for logging in and signing up. If you enter an existing username, it asks you to log-in. If you enter a username that doesn’t exist, it asks you to sign-up.

To manage this functionality, generates an AJAX request after you enter your username then move focus to the password field. This is creates a “change” event on the username field. When that event happens, asks the database whether the username you entered exists. The database returns a response in the form of XML. The XML has one message: the username is valid (it exists in the database) or it is invalid (it doesn’t exist in the database).

Once the XML response is returned, some JavaScript parses it to read whether it says “valid” or “invalid”. If the value is “invalid” the form asks you to create an account. The JavaScript to read this follows standard practices to navigate the document object model (DOM) and find the value in question. This works in Firefox, Chrome, Safari, Konqueror, Mobile Safari, Opera, Android Browser, Blackberry Browser, etc., etc. Apparently, how Internet Explorer handles the XML is different. It doesn’t create all the parameters that the standard approach would.

This shouldn’t come as a surprise to anyone.

What I ultimately found is that Internet Explorer will parse the value out and save it in a “text” parameter for the XML object. Rather than navigating the DOM in a standard fashion, I’m now taking a shortcut and checking if that “text” parameter exists on the XML object. If it does, I read it in as the returned value. If it doesn’t (obviously, all the other browsers to generate this rogue parameter), I continue to navigate the tree and get the value in the proper manner. This only works because the only value of the XML is the “valid” or “invalid” message.

The end result: the log-in/sign-up form logic should now be working again in IE. And still working in every other browser. If you find that not to be the case, please let me know (comment, email, Facebook, Tweet).

New Stat: Total Bases

Thursday, May 5th, 2011

Now that is migrated and–seemingly–stable, I can actually make some improvements!

First up are some stats additions. The easiest request was to include total bases. Because this is calculated based on data we already have, I was able to implement it pretty quickly. To enable Total Bases for any of your teams, visit the “Select Stats” page for that team. You will see a checkbox for “TB.” Checking that box and saving your changes should add a TB column right after strikeouts.

The most commonly requested stats that does not currently have are games played. While this data isn’t conveniently available in the MLB XML data uses, I think I have determined a way to deduce whether a player has played in the day’s game(s) or not. That will take significantly more effort, though, so it will have to wait. Perhaps this weekend I’ll find some time.

Clean-up to Save Gathering

Tuesday, May 11th, 2010

I noticed the other day that had recorded a save for one of my pitchers that, in fact, had blown a save. Reviewing the code that collects these stats, I think I’ve identified the issue.

Unlike most stats which come from a dedicated attribute in the XML files, saves, wins, losses, and holds need to be parsed out of a generic “notes” attribute. The logic performing this parsing was looking for “S,” to identify a save. While this matches the pattern (S,9)–a pitcher who recorded his 9th save–it also matches the pattern (BS,3)–a pitcher who has blown his 3rd save. I have updated this parsing pattern to look for “S,” in the absense of “BS,”. Hopefully this will fix the problem. I’ll be keeping an eye on this throughout the evening, but ping me if you notice any issues.

Games Played/Started Stats

Sunday, April 18th, 2010

Since the release of season-to-date stats, a lot of people have been asking for games played and games started to be included. I’m doing some research to find a reliable place to find such a statistic. If I can find it–and figure out how it plays into a paradigm with daily stats, too–I will incorporate it. The level of effort to include it is pretty minimal, assuming it can be found. More details to come.


Sunday, June 28th, 2009

One of the longest running requests of has been to include game progress information. I can definitely see the value in knowing whether the game your pitcher was pitching in is done yet or not (will there be a win coming or is it all over already?). This is a different kind of statistic than what otherwise collects, so it has been low on the priority list. As I got tired of stored procedures earlier today, though, it finally sounded like an appealing project.

The scoreboard is displayed across the top of the page in the banner area. It displays abbreviated linescores: team, runs, hits, errors, and inning (or “F” if Final). The banner area only has room for 8 scores at a time, so there are left and right arrows to slide the scoreboard side-to-side to view all games.

The first draft of the implementation pulls XML data from MLB each time a page is loaded that displays the scoreboard. Currently the homepage, your Dashboard, and all Team pages include the scoreboard. The data is collected from the XML, looped through, and populated into a list/table combination of mark-up. Some JQuery sets up click events on the arrow buttons when the page loads (if they are needed; if 8 or less games are occuring that day, no arrows will appear) and calculates how far the scoreboard needs to slide to display all games.

I only had time to perform a very quick testing on IE8, Safari, and Chrome (in addition to Firefox, on which all my development occurs) so if you experience any problems with your browser, please let me know.

More development will be ongoing with the scoreboard. I expect I will update the process to store the game scores so doesn’t need to continue pulling in game scores even after all game are done. It will function similar to how player stats are collected. It will first check if the XML feed has been updated. If not, it will pull data from the database. If so, it will update the database and use those stats.

Player Layer and Language

Tuesday, June 23rd, 2009

While clicking through my team stats today on, I noticed that the stats display layer seemed to be out of date. After a little investigation, I found that the XML feed for the stats had not been updated since June 16. A little more digging turned up what looks like a change in the way MLB is storing their data. The format of the data itself seems to be the same, but they moved its home on the server. After updating the path to the data, all seems to be well and cumulative stats are up-to-date again.

In other news, I resolved an issue that yesterday’s IE7 “fixes” introduced. In the mega-drop-down, the new JavaScript set a negative top-margin for IE browsers. Turns out IE8 is enough better than IE7 for this to be a problem. So that method has been updated to only apply the margin to Internet Explorer version 7.

And lastly, some new language throughout the site. The Account Info page now displays an alert message if the User’s profile is set to Public but they don’t have a first or last name defined. Obviously it is difficult to find people in a search if you can’t search on their name(s). The new language encourages the inclusion of a name to help other Users in their searches. The Account Info and Sign-up pages now also have note text added to the password sections indicating that passwords must be at least 6 characters long. Previously the only way to know this would be to enter a password that was too short and try to submit it. At that point an alert would pop-up identifying the shortcoming. Now the User is informed up front.