Skip to content


Broadband in Herefordshire: Openreach’s ironic name

If there’s one utility that a website design business needs to function, it’s Internet access (with the possible exception of electricity). Unfortunately, in rural Herefordshire, decent broadband remains a dream.

At our office location, a few miles from Kington, in the village of Titley, standard ADSL has provided a downstream speed of around 2.5Mbps: not great, but usable with a degree of care. Fibre broadband has been supposedly coming for years, and it was anticipated that this would finally provide the necessary boost to a half-decent speed. This work was due, according to BT Openreach, to be completed by the end of 2016.

It is with much annoyance and even a hint of anger, therefore, that I come to outline the hopelessly inadequate practices of BT Openreach in relation to the purported rollout of fibre broadband. Openreach could hardly be a less suitable name: they’re neither open with their information nor keen to reach out.

A bit of background: during most of 2016, our telephone line was officially connected to Cabinet 2 on the Kington exchange. This received a relatively early fibre upgrade; from memory this was completed in 2015. Unfortunately for our line, Cabinet 2 is situated on the edge of Kington, 3 miles or so from Titley, meaning that VDSL cannot be provided to any of the Titley properties due to the distance.

We raised this matter with Fastershire, mentioning our concerns that many on Cabinet 2 would not actually be receiving fibre; we wanted to make sure that we weren’t forgotten. Fastershire did not give any specific indications about what would be happening in Titley, beyond referring us to the county-wide broadband strategy, and confirming that Titley would not be receiving FTTP.

Screenshot of the BT Openreach checker, showing fibre as available on our phone number
Fibre available? Don’t count your chickens.

However, during 2016, work had started in Titley on what looked suspiciously like another fibre cabinet, bearing the number 9. In December 2016, the Openreach checker declared that we were now on Cabinet 9, and that FTTC would be available by the end of the year. We put out the bunting. On 28 December 2016, Openreach’s checker indicated that Cabinet 9 was now “accepting orders”. Naturally, we promptly ordered a fibre service.

A few days later, we received an “Order Rejected” email from our ISP, which stated that it had come to light that fibre was not available on our line after all. Bizarrely, the Openreach checker was now showing our line as being connected to Cabinet 11, another new cabinet. Cabinet 11 is situated near Rushock, about a mile out from Kington. Unlike Cabinet 9, it’s still in the process of being provisioned.

Our line shouldn’t be on Cabinet 11 at all. We’re a matter of metres from Cabinet 9; we’re miles from Cabinet 11, so we wouldn’t be able to order fibre even if it were enabled on 11, for the same reason that we couldn’t order it when we were on Cabinet 2.

The other oddity was that if we entered our postcode rather than phone number into the Openreach checker, it claimed our property was on Cabinet 9 – as it should be.

We contacted Fastershire and they attempted to chase up Openreach, but at time of writing had no response from Openreach to pass back to us.

The next step was to contact Openreach directly, explaining the situation in detail, including the matter of the checker indicating we were on the wrong cabinet.

Openreach have been diabolically bad when it comes to responding to queries. First of all, there is the small matter of their response time: they give an estimated turnaround time of twenty – twenty! – working days. In what business would an official three-week response time be considered remotely acceptable?

If one was being cynical, one would say that this response time was extremely self-serving, allowing them to get away with an absurdly low number of customer responses.

Such a policy might be excused if Openreach’s replies were of any use. Sadly, this isn’t the case. The first Openreach response, on 23 January 2017, was as follows:

We’ve investigated and found that you are connected to cabinet 11 and exchange KINGTON.

FTTC (Fibre to the cabinet) is available for you for which a project is ongoing with an estimated completion date of Mid of February, 2017 which is subjected to change as per the work left.

Great: a response that repeats back to me what I told them in the original email. I duly responded, explaining again in details the issue with the checker. I even boiled it down to two simple questions for them to answer:

  1. Why does the checker suddenly claim that our line is on Cabinet 11 (~3km away) when it said Cabinet 9 (~300m away) until recently?

  2. Since the upgrade of Cabinet 11 will be useless for all Titley residents, when will they be put on to Cabinet 9?

A month later, I received the following response:

I am pleased to advise that Fibre to the Cabinet should now be available for you to order

This was followed by a screenshot of the Openreach checker with our postcode, which showed, as before, that we were on the FTTC-enabled cabinet 9. Unfortunately, searching using the phone number still showed us as on Cabinet 11. Essentially, Openreach were, once again, parroting back to us what we’d already explained to them.

Whether you consider Openreach to have been wilfully or accidentally obtuse depends on your level of cynicism. The long and the short of the matter is that, despite fibre supposedly having been rolled out to Titley by late 2016, two months down the line properties and businesses are still stranded without access to fibre. I know of at least three businesses in the Titley area in a similar situation; there are likely to be others out there, in addition to many home users.

To make things worse, our existing ADSL connections appear to have sharply degraded in the last couple of months, with high latency, daily dropouts, and dramatic crashes in sync speed all common experiences.

Fastershire seem to want to help, but it appears that their power to force Openreach to open up is limited. They need users to supply specific detail of failed orders.

There’s no doubt that Openreach have done much to supply the infrastructure of rural Herefordshire broadband, but their lack of openness in information supply threatens to eradicate any public goodwill.

Solving the PrimoPDF “Invalid XML Document” exception

You need to delete the PrimoPDF settings XML file, which can be found in your Application Data folder.

  1. Navigate to %AppData%\PrimoPDF
  2. Delete PrimoSet.xml. You could back it up first, but I wouldn’t say it’s important.

After doing so, upon opening PrimoPDF again, the settings file will be re-created. Note that your previous PrimoPDF settings will have been lost, so make sure you set them correctly again.

Credit goes to for pointing in the right direction (though with slightly outdated instructions).

KB2836988 for Windows 8 may cause BSOD on some AMD chipsets

After a recent Windows 8 update, my computer refused to boot properly, but attempted an Automatic Repair, which was unsuccessful. The system would flash a blue screen of death and reboot with no more illuminating error message. I also encountered this when booting from the Windows 8 DVD – sudden blue screens with no error messages.

My Windows 8 installation is on a SSD on a system with an AMD chipset, and I had to switch the SSD to IDE mode access to get any sort of stability. After I did this, Automatic Repair had a longer attempt to fix it, but still ended unsuccessfully with a message informing me to check WINDOWS\System32\Logfiles\Srt\Srttrail.txt. Removing the SSD and examining this file on my laptop showed me the following error message:

Boot critical file E:\Windows\System32\drivers\amdsbs.sys is corrupt

Replacing that file with a fresh copy did not appear to help. To get Windows to boot properly, I had to boot to a command prompt (clicking the Advanced Options button from the screen with the Srttrail.txt error message) and use the dism.exe tool with this command:

dism.exe /image:D:\ /cleanup-image /revertpendingactions

where D: is the Windows drive.

After doing this and rebooting, on the next boot Windows detected a failed update and reverted changes. I was then able to enter Windows.

The update at fault appears to be KB2836988 and I suspect it may be causing problems with systems using the AMD 700 series chipset. Other people seem to be experiencing similar problems. We will see whether Microsoft do anything to address the problem; in the meantime, I’ve turned off Automatic Updates, and am avoiding that particular update for the moment.

Mazda MX-5 mk.1 headlight bulb replacement guide

It’s remarkably dangerous to drive with one headlight out—not necessarily because it reduces your vision, but because it reduces your visibility to other road users. It’s all too easy to look like a motorcyclist, and hence a much narrower hazard, to a tired driver, with potentially lethal results.

It’s therefore wise to get a blown headlamp bulb changed as quickly as possible. On the Mark 1 Mazda MX-5 (Miata in the USA, Eunos Roadster in Japan), while it’s not as straightforward as on some cars, it’s nevertheless not a difficult procedure, as the following guide will show. I’d recommend the purchase of the Veloce Mazda MX-5 1.8i enthusiast’s manual (if you have the 1.6i, this version of the manual is preferable), which assisted me along the way. As for the replacement bulb itself, you need a 12V 60/55W bulb, such as this Lucas LLB472 bulb. I obtained one from my trusty local mechanic (thanks Gary!), who was even kind enough to drop it off at my house.

  1. Turn the lights off, and raise the headlights using the centre console switch.
  2. Remove the four screws, two on each side, on the sides of the headlight. These hold the plastic headlight surround in place. Be careful when removing them, since they each have two small washers on them.
    One side of the headlight assembly

    Mazda MX-5 headlight
    The other side of the headlight assembly

    One of the four screws to be removed. Beware of losing the two washers on each screw
  3. Lift the headlight surround away.
    Remove surround
  4. The screws that hold the headlight unit should now be visible. Be careful: there are three that hold the headlight in place, and two others that merely adjust the headlight beam. Don’t touch the latter, and be careful with the others, as I’ll explain.
    The screws to be removed are highlighted by green circles. Don’t touch the two screws marked with red crosses.
  5. You need to loosen, not remove, the three that are spaced roughly 120 degrees apart. When I first did this, I didn’t realise that I didn’t need to remove them, and indeed it’s quite tricky to remove them all, due to their positions. Just loosen them enough to allow the shiny headlight retention ring to rotate slightly, causing the screws to line up with the larger holes in the ring. Have WD-40 at the ready to lubricate them.
    One of the three screws to be slackened, in the locked position

    With the screw slackened, the ring can be rotated to this position.
  6. Rotate the retention ring and remove it. In my case, it had become stuck to the headlight unit, so I ended up removing the unit at the same time, as described in the next step.
    Remove retaining ring
  7. Carefully start to remove the headlight unit.
    Remove unit carefully
  8. The wiring loom will be connected to the back of the unit: disconnect it to release and remove the unit completely.
    The connector

    Disconnect connector
  9. Pull the dust boot off. Note any damage: if it’s no longer sitting snugly over the assembly, you’ll need to replace it soon.
    Remove dust boot
  10. Undo the bulb clip.
    Clip holding the bulb

    Unclip bulb
  11. Remove the bulb carefully.
    Remove bulb
  12. Install the replacement bulb, making sure you don’t touch the bulb with bare fingers—this can leave a residue on the bulb that leads to the bulb’s premature destruction. Clip the bulb in.
    Insert new bulb
  13. Reassemble carefully.

With your new headlamp bulb thus installed, you’ll be all set to get safely back on the road.

Sony Vegas 8.0 and mp4v files may conflict with QuickTime 7.6.8

Sony Vegas 8.0 projects that use mp4v files may not display the video properly, presenting only audio with a black screen. It appears that QuickTime 7.6.8 causes the problems. In my case, the .mov files, which originated from a camera phone, would play fine in VLC, but not in Windows Media Player.

The solution is to uninstall QuickTime 7.6.8 and install QuickTime 7.6. Unfortunately, this does mean you lose the updated security features of 7.6.8; one hopes Apple rectifies the situation in a future release.