Next month: September 1997
Now that the Wednesday 8.30pm start for the TV show is permanent (Children's Hospital starts a new series at 8.00pm from next Wednesday onwards), I've adjusted the cron jobs and refresh timings to cope with the later start.
Fixed annoying bug with Jackpot Winners/Prize Order sorting in the Winning Numbers CGI - I hadn't set the allowable year range for draws correctly, so it badly scrambled the returned lines (not in sorted order like they should have been) until I correctly set the year range.
The live update went reasonably smoothly and I was also the quickest to put the full details on the site. A bit of excitement's coming up on Monday because it's the first time the prize expiry Java countdown will have hit zero :-)
I phoned up at around 8.50pm, got Pauline, who just said "no, the results aren't available yet", but about 2 minutes later, Chris Prickett had the full results online, so they must have been available then - it was sheer laziness on the operator's part - she didn't actually check their computer systems before telling me that the results weren't through !
So I phoned back at 8.55pm, got Alan, and - yep - he also said that the results weren't through. At this point, I'm starting to turn into Mr. Angry, so before I exploded, I asked him to double check and - eventually - he sheepishly admitted that they were available. I asked him for the number of prize winners and individual prize amounts and he reeled off the former, but then proceeded to give me the prize pools, so I had to ask him for all the individual prizes as well all over again. Believe you me, when I got off the phone, the air was blue :-)
Phoned up Camelot for the weekly figures since they hadn't sent a fax. It was the first unclaimed prizes week involving a midweek draw, so I had to hurriedly change my code to act like the Lucky Dip figures i.e. only weekly unclaimed prizes figures are being issued, so Wednesday draws don't have an individual unclaimed prizes figure.
This hit the Web pages across all our domains of course - even twin CPUs don't like deadlock and it was crazily sluggish to log into it and get a process list. After a brief look at the processes, there was nothing "eating" CPU, so it was clearly some sort of kernel resource (probably the number of network connections) exhausted by the Liverpool fans in the Anfield chat room. I gave up and rebooted the server machine.
Things were OK until about 15 mins from the end of the Liverpool match - the deadlock happened again and I had no choice but to reboot for a second time. At this point, I withdrew the Anfield chat room until our Java experts can fix a connection limit across the chat rooms.
All of this hit my lottery page updating, although I was still faster than Chris Prickett to get the full results, despite someone else hogging the phone until just after 9pm ! I was in such a frazzled state that I downloaded the pages and leisurely worked on the manual comments offline several hours after the draw (whilst my VCR was recording Babylon 5 in fact) before uploading them as you see them now (normally I do manual comments inbetween the initial numbers being drawn and getting the full results from Camelot on the phone).
Added machine and ball set info back into the Winning Numbers section. The reason it was left off was two-fold - firstly, the HTML table now has a dynamic number of columns (there's no column if a particular machine or ball set is selected in the form) and secondly, the table is now excessively wide, so I've put a warning about this in the form notes (probably need around 800 pixels wide to properly render the table).
Decided to remove the above table width warning and put in a table width in pixels for the Winning Numbers tables (always a bit risky when dealing with text-only HTML tables) as an attribute for the <TABLE> tag. The width is 600 pixels without machine or ball set, 700 pixels with the machine info and 750 pixels with both. This also conveniently stops the table "collapsing" horribly if your browser is too narrow, so I'll stick with it unless someone complains. It probably needs a bit of testing on PC browsers to see what's the minimum width I can safely get away with.
When trying to upgrade our HP-UX Netscape from 3.01 to 3.02, I discovered that "Times" as a font name used by an applet was OK with 3.01, but didn't work with 3.02 ! After experimentation, I found out that "TimesRoman" worked with both, so that's the font I'm using for the Countdown applet now.
Liased with Fish, our Java expert, to adjust the Countdown Java applet I'm using on the hi-res index page to cope correctly with different time zones. It struck me the other day that the countdown could be 5 or more hours out if someone from the US viewed the applet (confirmed by setting the TZ variable in UNIX to a US timezone and running Netscape on the hi-res page), but this now works OK.
Worked hard on the automatic update code again - this time I've spent several hours testing it and am pretty confident about it now. I've revived some special code from back in April (used for my Philly trip) that hadn't really gone through a lot of testing, but I've ironed out the niggles now, so it should run reasonably well if it's needed on Wednesday.
The automatic update at least kept the winning numbers on the home page this time, so it's gradually improving. It still needs a really good test, which I might have time for now that the World Athletics Championships have finished :-)
Fixed a stupid bug in the hi-res index page - the older set of balls (if you wait long enough for them appear) were actually the latest set of balls...duh ! Also shortened the "Estimated jackpot" string to "Est. jackpot" in the applet config file because the extra rollover draw message caused it to line wrap.
Checked the error log for the Web server and added a few more soft-links for some of the more commonly requested static (and hence now deleted) Winning Number documents to point to the new Winning Numbers form. I'll probably remove those soft-links some time in the future.
Fixed some old links for the previous/next years in the Winning Numbers section (they were going to the old static pages, rather than to a CGI-based URL). I've tested out the automatic page updating for tonight and it should work OK (unlike last weekend).
I've also run through the latest teletext e-mail from Saturday evening and fixed the auto-update system to generate the winning numbers correctly based on ITV/BBC teletext pages (this didn't work last weekend !). It turned out I'd forgotten to set a variable when the teletext result came in to indicate that provisional balls should be drawn (so they came out as question marks on Saturday, although the ALT tag was fine).
One other teletext results snafu was worked around - the Irish lottery results on the final sub-page of ITV teletext page 123 were interfering because the numbers appear in the same positions as the UK results. I simply take the second-to-last line of numbers in the ITV teletext e-mail instead now.
I've disabled the virtual lottery closing auto-page generation of course for the moment - the next virtual lottery draw doesn't close for another 8 days. Picked up another couple of tickets for tomorrow's "real" lottery Super Draw.
Had real problems trying to code for the aforementioned virtual lottery Super Draw - it took me 4 hours to get it right today ! It turns out that Wednesday's "real" UK lottery is also a Super Draw.
Did the usual gcc, lint, spell check, weblint and link check on the pages, which tidied up some minor loose ends on the pages. Musical credit for this weekend's changes belongs to the Hanson CD single Mmmbop, which I picked up this week for free in Our Price's "Buy 5 Get 1 Free" offer. The track works great on auto-repeat whilst coding :-)
In a Herculean operation, I've managed to set up ImageMagick 3.6.3 on my home machine in such a manner that it can be installed onto the work machines by simply unpacking the (2-year-old !) binaries and shared libraries into their install locations (for those in the know, SHLIB_PATH and chatr trickery mean I can put the shared libraries where I like). ImageMagick 3.6.3 can directly create "Java-friendly" non-interlaced GIFs with a single command, so the entire set of 7-ball GIFs in the /archive directory have now been de-interlaced and all future GIFs will also be non-interlaced.
The upshot of all this is that I could be without ISDN for between one and two weeks, so it looks like no live updates during that period. Isn't it typical that the only site on MerseyWorld that needs a truly live update is run by the only member of Connect staff whose ISDN won't dial in ? Grrr...
It was a blessing in disguise though, because it allowed me to rip through all the code to ready for a launch of a hi-res version of the lottery index page, which will include a rather impressive Java applet. I may also ask our graphics designers for a hi-res lottery logo to go on that hi-res home page although, initially, it won't replace the current (lo-res) home page and the rest of the page isn't any different to the lo-res version, though I fancy setting up an HTML table for the links.
One annoying thing at the moment is that ImageMagick 3.6.3 seems to be the last reasonably reliable version that can create GIFs with its "montage" command that have the correct colours (and, indeed, number of colours). All the 3.8 versions up to 3.8.8 seems to create GIFs that simply aren't correct in terms of palettes, colours or both. In addition, all 3.8 versions fail to produce a GIF that can load into a Java applet (even with interlacing switched off)....arrrggh ! I've e-mailed the author to complain about all of this.
Previous month: July 1997