I’m still working to diagnose the issues with daily boxscore emails. Based on my research, I think I have narrowed the issue down to daily boxscore emails for friends’ teams (although I still don’t know why). Is there anyone who has signed up for daily boxscore emails for their own teams that is not receiving them?
Yesterday I started receiving notes that players’ season at-bats in Kilg.us were topping out at 127, even when MLB was reporting a higher value. The reason was a simple oversight in database design. All the numeric values were defined as “tinyint” within the database. This is what is used throughout the daily stats, so it was copied over when the season stats tables were created.
Tinyint is a data-type that only allows for values from -127 to 127. This is great for daily stats (the only daily stat I could imagine passing 127 would be a pitch-count), but doesn’t work so well for season stats. I have changed the data-type to “smallint” for all fields that could exceed 127 in a full-season. Smallint will allow values up to 32767.
Season-to-date stats are collected on a scheduled basis, every 15 minutes. In the next few minutes we should see season-to-date at-bat values correcting themselves. I’ll be monitoring this to ensure it happens so I can diagnose further problems if it doesn’t work.
Thanks to all of you that chimed in with this issue and for providing details so I could correct it quickly!
I noticed the other day that Kilg.us 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.
I jumped into the Find Friends section of Kilg.us this evening, planning to update the logic to auto-accept all friend requests to “Major League Baseball” (at present, I manually check the account daily and accept requests). Hitting the page, though, I encountered a Lucene search error, so that derailed my attention.
It looks like the search logic was getting confused when the page was sent an empty query (just clicking the “Find Friends” link rather than using the form on the Dashboard). This wasn’t happening a month or so ago when I set it up, so I’m guessing it has something to do with the size of the index that is being queried now.
Anyway, I updated the code to handle empty queries more gracefully. While testing that, I noticed an issue when requesting Friends that don’t have a name on their profile. When making the request, the prompt would ask if you wanted to request ” ” to be your friend. That isn’t very helpful. I updated that script to pull in the user’s email address if a name isn’t on the profile. Now when you ask someone to be your friend, you will either be prompted with their name or their email address. Much better.
In the process, my JavaScript errored out a couple times. This, unfortunately, means I requested to be friends with a couple people I don’t know. So if you got a random friend request from me, I won’t be offended if you decline!