We're into the second week of events and although less gold medals are obviously awarded in the first week since most events are in heat rounds rather than finals, it's still quite disappointing that the Olympics host has failed to win a gold medal. There's chances of a few today though, but so far the British Olympians have disappointed - many not getting into finals when they were expected to.
Today's recording stats are all 24 channels, 23 sports and 54 slots totalling 211 hours and 2 minutes recording time - this includes 3 minutes pre-padding and 5 minutes post-padding for every time slot. pc2 has generally been recording more than pc1 (up to 16 HD channels simultaneously in fact) and its first 3TB disk is now 92% full. My transmedia program should therefore start using the second 3TB disk in pc2 by lunchtime.
Just been checking digiguide.tv's listings for the 24 channels through to the 10th August (yes, 2 days short of the end) and the 8th August is apparently only using 12 of the 24 channels! A "half-day" of sport next Wednesday then? Or a listings error? Who knows.
I'm going to experiment with a tuner allocation program I wrote the other day. It basically suggests which PC/tuner should be allocated for the next event to avoid over-allocating tuners like I mentioned in yesterday's post. If either PC is already recording the same transponder it is used again for the new event, otherwise it's the PC with most free tuners available. If that ties, then it's the PC with the most tuners overall, which is currently pc2's 4 compared to pc1's 3.
I have no doubling-up code in it yet, but that gets trickier because there will times where you'll have to cancel one or more of the double-ups to free up a tuner for a new slot that needs a fresh transponder.
Hey, did we just have five events start simultaneously at 08:55 this morning? Two badminton and one each of beach volleyball, archery and fencing. That may be the first time it's happened because I can only remember four simultaneous starts prior to today. That fencing slot has also joined the bad boys hall of fame of overly long slots at a painful 7 hours and 15 mins and will be split today. The only other scheduling note of interest is that basketball sets a new latest-ending record by finishing at 00:30 tomorrow morning (update: strike that, it looks like basketball finished well before midnight and left timetable video up when it was done in the slot).
Just been watching the swimming heats this morning on BBC Olympics 1 HD and I've aways liked the two commentators, but they're making a classic error - probably the production team not prompting them - of stopping commentary on the sat channel whilst Sharron Davies interviews whoever just finished the previous heat (presumably for one of the terrestrial channels, I dunno). Problem is that the sat channel continued with the live action and never showed the interview at all. We even had the silly point where Michael Phelps starts his heat to total commentary silence on the sat channel for a length and a half of the pool!
Needless to say, I missed the first GB gold in this Olympics whilst watching the swimming - Glover and Stanning, who amazingly (considering our good gold medal record in men's rowing) are our first ever women gold medallists in rowing, albeit the sport was only introduced to the Olympics in 1976.
A tennis session seems to have appeared out of nowhere on channel 24 - it was supposed to be badminton until 15:40, but the Now/Next has kicked in tennis between 14:45 and 20:00 today on the same channel. I've left both recording for the moment and I'm sure this has happened once or twice before as well.
No golds for 7 days and then we get 2 in one day. Watching Bradley Wiggins win the cycling road time trial was great, only soured as usual by Hugh Porter's utterly useless commentary. Why that guy still has a BBC job is anyone's guess - misidentifying the riders regularly, stating who was leading time checks without actually looking at a computer screen first (and therefore getting it wrong and having to correct himself when actually looking at the screen afterwards) and even calling the event the team time trial at one point! I believe he was equally bad in the men's road race (which I didn't watch because I wasn't convinced we'd get a medal despite the pre-race hype). Liggett and Sherwen on ITV4's TDF coverage were just so much better.
I decided to take the one and only fsync() call out of my transmedia program today. It's a C library call used usually just before you close an open file you're writing - to HDD in this case - to physically commit the data to HDD. It does take many seconds - proportional to the file size - to execute fsync() because the writes are buffered in RAM and I have 12GB/16GB in the PCs. However, Linux is very good at disk buffering and flushing smoothly at regular intervals, so I've taken the fsync() out.
Although the file written to is only on HDD, I'm not convinced that the Linux kernel doesn't cause it to affect other filing systems. For example, it's very strange that the equivalent command line program, "sync", doesn't let you specify a file, directory, mount point or device at all! It does mean that a power failure may lose video, but I have a UPS on both PCs, so that's quite unlikely to happen. It also makes transmedia "finish" its SSD->HDD copy significantly more quickly, though of course it's not truly finished until the buffered disk writes are written to HDD a little later (I suspect that'll generally be completed within 30 seconds).
I was reviewing the transmedia source code further today and spotted two minor stupidities. When the verify pass is turned off, I still calculated the checksums for each 1MB of data read in, despite never actually comparing those checksums with the data written and then re-read from the HDD (because I don't do that re-read if verify is turned off). That was an easy fix, but the second dumb bit of code was that if the source file couldn't be deleted after the copy to HDD was successful, I'd madly delete the HDD copy too!
The reason that deletion was stupid is that if the source file is deleted or renamed after transmedia opens the file, Linux is neat enough to allow the reads to continue on the open file handle until the file is closed again. Yes, the source file has gone from a user-visible point of view (e.g. "ls" doesn't list it), but Linux will not finally delete files until all processes that have it open actually close the file. Now I just log a warning about not being able to delete the source file, leave the probably fine HDD copy intact and then continue on with the code, which is much more robust IMHO.
Day 8 recording size: 1132GB - grand total so far: 6220GB (6.1TB)