OK I did a rant a while back, and I reckon after rebuild after rebuild I think I was right all along it is octoprint that is adding to the problem.
In a certain set of conditions, ATMEGA is 250k baud rate max, whereas later boards with real USB are megabit data transfer and have faster CPU's so maybe not a problem.
basically it is a complex print with lots of retracts and travels to small detail circular mounts and small circles require a lot of data throughput to do lots of small moves/prints
1. watching the print in octoprint on firefox on a not-massively-fast machine on local net but that has many many firefox windows and tabs up browsing ebay/stackexchange/assorted web sites and youtube to watch videos.
because I think network acces can be blocking and maybe the timeouts and all the extra code to cater for timeouts may cause millisecond type delays this can interrupt the data flow to 3d print board at the rate it needs to print
BASICALLY IF YOU HAVE PRINTS THAT FAIL STRANGELY TRY JUST LOADING THE PRINT USING OCTOPRINT AND STARTING IT AND THEN SHUTTING DOWN THE OCTOPRINT BROWSER WINDOW AND DON'T WATCH IT IN BROWSER
A WATCHED POT NEVER BOILS LOL
ANYWAY SEEMS TO HAVE WORKED FOR ME!
I KNOW THERE ARE FEED PROBLEMS ON MY PRINTER AS WELL DUE TO UPGRADE TO e3d and old 3mm filament being larger than 3mm and being a bit sticky in the feed chamber and bit of damage to hobbed bolt. Ordered a replacement hobbed bolt and they sent me a blunt one that would not grip anything!
edit: now I think about it, maybe I can go all the way back to openscad and lower the detail of circles that will then further up the chain need less gcode to print a mount....
funny how making a post/comment makes a further self-answer to the question appear...
maybe it is in the codification of the problem for a post that pops up some logical possible solutions for yourself?