Was told for interleaving to be disabled on a VDSL line i would need an engineer visit costing £65.
FIXED
Hi Connor, Sorry for the issues you're going through to get interleaving switched off. Unfortunately there appears to be a bit of a knowledge gap with the advisers you've spoken to, because on fibre it's not possible for us to request adjustments to the settings of a DLM profile unless a line speed is restricted by a 'banding' where we'd request a remote DLM reset which is a manual process done by the Openreach diagnostics team.
The potential engineer charge of £65 you've been quoted wouldn't be for interleaving to be removed, it's if an engineer finds no fault with the service or the problem is with your equipment. I'm afraid we can't send an engineer to solely carry out a DLM reset to remove interleaving, when we arrange engineers it's part of an investigation for example your connection may be dropping or speeds below where they should be.
Poor latency isn't considered a fault by our suppliers, it's generally a symptom of another issue although a ping of 80ms I'd say is fine unless it's spiking all over the place. Are you experiencing any perfomance issues with your service that's prompting this?
Thanks for the detail. While I understand what you've said, as a service provider we've no control over interleaving as that's handled by DLM which is in the domain of Openreach and our suppliers don't consider latency issues a fault.
Again high latency is normally a symptom rather than a cause, what performance issues is this causing you? Perhaps we can help with that. 
No problem Connor. Yeah we can still control this on ADSL because as far as I'm aware the DLM for ADSL is under BT's control and we've been given the right tools for this. For fibre, the DLM is all under Openreach's domain.
I've checked your line and as of yesterday the DLM profile is showing at: "Downstream: 0.128M-80M with Interleaving (Low). Upstream: 0.128M-20M with no error protection" so there is definitely interleaving on the downstream.
Looking at your speeds while they're at the very bottom of the speed estimates/expectations of your line between 65mbps and 80mbps, our RRT(Reactive Repair Tool) data (It's not as repairy as you'd think, it's just for diagnostics we can't change anything using it) is showing your line should be able to perform better.
I can see in the past 14 days your speeds have declined from 68.17mbps to around 61.78mbps with interleaving enabled in a high mode at the beginning of this period, and it's now in a low mode so hopefully with time the DLM will remove interleaving altogether on the downstream.
Based on this and that you've tweaked the SNR to try to artificially boost your speeds, I think there's an underlying fault here. When you've got time it may be worth running through the steps Here to connect your router into the test socket behind the faceplate of the master phone socket to rule out any issues with the internal wiring of the property.
If there are no improvements, I'd recommend raising a fault to us online at https://faults.plus.net posting back afterwards so we can arrange an engineer visit to investigate further.
When you've got a chance, to rule out your equipment it may be worth disconnecting that and connecting the router we've sent into the test socket, which would kill two birds with one stone in effect (Disclaimer, no actual birds will be harmed 
)
With regards to the mis-information, it seems more of a knowledge gap but I believe they've since had clarification by liaising with one of their colleagues.
We don't really see FEC or CRC errors on our testing as they're generally not that relevant to us. As far as I understand them they're a by-product of errored seconds, FEC errors being errors that have been corrected (likely by interleaving or another form of error correction), so a large amount of these alone isn't anything to worry about.
CRC errors on the other hand are the opposite in the way that a large amount are bad, but it's also similar in the way that they don't really tell us much as there's a lot more factors which can cause them. I find that the Kitz website is a pretty good knowledge base, particularly here may give a better explanation and some more detail.
What I'd look out for are Errored Seconds(ES) or Severely Errored Seconds(SES). I've attached a graph below of the mean time between errors (MTBE) showing that your line appears to have been erroring fairly badly on the downstream.
Unlike with ADSL they can't just click a button and it all goes through automatically.
With VDSL lines it is possible to get a DLM reset only under certain circumstances. This process is a wee bit more manual and the line must meet certain criteria such as appear to be stuck and/or the line must have been stable again for a reasonable period. iirc in the original instructions to the SP's Openreach during the trial would be doing random checks to ensure SP's weren't just requesting resets without due cause.
If the line has had Error Protection (& Interleaving) applied, then in theory if the line is stable then it should return back to Error Protection off within a certain timeframe. How soon it returns depends upon whether Error Protection has been applied in the past. If its a first offence then usually within a few days of stability. For each offence the time scale of required stability goes up eg 5 days, 10 days, 14 days, 6 weeks. {can't recall exact dates off the top of my head but something like}
However, we have noticed recently that some [ECI] lines are having Interleave applied despite not getting anywhere near the usual 2880 E/S per day. I got Interleaved last Oct for just 25 Err Secs which was a short spike of CRCs lasting less than a minute. 6 weeks later despite having less than 10 E/Secs per day I was still Interleaved.
A request for DLM reset was approved as I had gone over 6wks with an ILQ green status.
I tweaked my snr a bit and managed to get my speeds back to 52-56 which I am happy enough with.
Not such a good idea with the Openreach NGA DLM. 😕 Lower SNRM means more likelyhood of errors and much longer for the DLM to remove interleaving under its own steam. The only way we have had some sort of sucess to getting the DLM to relent faster is by capping the linespeed to give it alower sync and higher Noise Margin 
Interestingly interleaving is off for my upstream!
Upstream and downstream are treated independantly of each other. Its not unusual for it just to be on the downstream or even vice versa.
Thanks for the post back @Youngsie97
Ah sounds good, no problem I live in a shared house so I know the feeling when you go messing around with the internet. 
Yeah I'd just run speed tests and trace-routes (a good one is pingbox1.thinkbroadband.com) although once you've made the changes if you don't notice any improvement, let me know as your speed may be restricted by profiling on our side.
There's basically a profile on an account from a bygone era which should always sit below the current sync speed but when the sync speed changes, the profile can be a bit slow to adjust and will restrict your throughput/download speed if set too low. The majority of connections ignore whatever this profile is set at but on a small number, generally when you have a static IP, does the profile have an effect if too low.
Let me know how it goes.
btw and MBTE of >5000 is good, as it means ~18 Err/Secs per whole 24hr (86400 secs) period of uptime.
MTBE is the average time between errors occuring and is calculated as follows:
- MTBE = Connection uptime / Code Violations (Errors)
So usually, the higher the MTBE, the better the line.
- A good line (is/was) categorised as ILQ green if it has an MTBE >300 on the speed stability profile or >600 for standard profile.
- A bad line (is/was) categorised as ILQ red if it has an MTBE <30 on the speed stability profile or <60 for standard profile.
Based on the previously known speed profile:
MTBE of 300 = apprx 279 E/Sec per full 24hr of uptime = ILQ Green
MTBE of 30 = apprx 2880 E/Sec per full 24hr of uptime = ILQ Red
Anything inbetween those 2 figures = ILQ Amber
Back to that HOWEVER above.
Note I say (was) because after some digging Openreach have indeed been tweaking and changed something since Sept last year. Exactly what, I can't quite fathom out yet... from the limited info it may be recording different time value MBTE than 24hr... or even taking into account massive CRC spikes which run into thousands.
@Gandalf would you like to do me a massive favour please and show the my graph for my vdsl line.
I may be able to get a clue from comparing my linestats to their graph... as I've got some regular daily periods of SHINE-like CRCs over the past few days so it would be an ideal opportunity to see if it is doing anything with those.
Cheers
Thank you muchly. I'll do a compare later.