I'm going to guess it's somewhere in the Cura printer definition. I have looked and I can't find it but one of the common features of earlier data posted was a Creality printer - Ender 3, CR10 etc. If anyone knows the answer, please share.
The main thing is it is solved 
See you in the Octoprint On Air on Friday
I'd wonder if either of you use Cura post-processing scripts.
Generally I don't. I have experimented with changing print head temp at different levels when testing for stringing etc but 99% of the time I just use the plain gcode that Cura produces. There must be a setting or a config file somewhere which adds the CR but it's beaten me.
I just reviewed the Cura code itself and I can't see where it might inject a CR/LF as a pair. The post-processing plugin area could potentially do this, though.
I have the same issue using simplify3D
I don't have Simplify3d but it is going to be an issue with any slicer which produces gcode with CRLF at the end of each line rather than just LF. I have just tried the Fusion360 slicer as a test (I wouldn't recommend it!) and that produces CRLF line ends too.
But it's fixed now - in the short term with @foosel's plugin, or in version 1.4.1 when it's released.
Yes I see..... btw I'll use vscode to save the file with LF instead CRLF 
By the way, Thanks for the plug in fix. It works great and I find that I enjoy printing much more when I can check progress on the Viewer correctly.
Cheers,
jon
I hate to be a party pooper on your solution, but my problem is similar, but inverted... my gcode viewer finishes, and things like OctoPod report that the print has completed, several layers (on large items, too) before the actual printing process ends. I have not had a chance to install your plugin fix yet, as both CR10v2s are busy on long prints, but from your description, I don't see that the CRLF situation will fix it. I'll give your plugin a shot when the next print finshes in a few hours, and try one of the troublesome files after running it through BBEdit to fix the CRLFs to the right way, and let you know, but it's just a head's up that the opposite instance of what everyone has been reporting is happening to me, every print since I upgraded to 1.4.0. Prior to that, it was close to spot-on.
Here's an example, this is just layer 2, and notice how far behind the print head is... it's only about 2/3 of the way through layer 2, and the gcode viewer is almost ready to go on to layer 3!
Different issue, please check if the issue persists in safe mode, and of so share a file with which to reproduce. A bit of being ahead is normal due to buffer sizes in the firmware btw, OctoPrint cannot know when your printer actually executes the moves it sends to it.
I'll give it a try in safe mode when I have a chance, but being "a bit ahead" is not the same as being several complete layers ahead with large objects, and never having had the problem before the upgrade. Right now, that same build I shared earlier is 4 layers ahead, even taking into account that the gcode viewer and Dashboard/layer progress is 2 layers difference normally.
Edit (because the forum won't let me post more than 3 replies to a topic as I'm a "new user"):
Curiouser and curiouser... I changed a roll of filament during that print (using the printer control panel, not coctoprint). When I returned to Octoprint to dismiss the dialogs that had popped up, the print had nearly "caught up" with the gcode viewer. Now the viewer is starting to pull ahead again.
I'm aware. I was just pointing this out since I wanted to prevent everyone and their mother chiming in with "mine is ahead a bit too!" as has happened in the past 
In addition to you testing safe mode and also providing a file with which to reproduce, I think at this point it would also be a good idea to share some information about your setup, plus an octoprint.log and a serial.log. I'm especially interested in
OK
Raspberry Pi 3b+ and 4 (both are affected)
Can access either way, using assigned separate IPs for each (1 each WiFi/Lan for each printer)
Firefox 74.0 (64-bit) on Mac OS10.15.3
Cura 4.5
All files, much more noticeable on files for large objects, as it gets progressively worse as the print progresses
CR10v2 x 2
Running a version of Marlin 2 compiled by Nic Wilson, and yes, recently updated to that, but the problem started prior to the upgrade.
Hi, I have the same problem as Photog1. Before I updated to the latest version it was quite synchronized.
Sorry, I';ve been busy with both printers doing a massive, multi-part print that has a scheduled delivery date I have to meet. The problem is still ongoing, and one of the parts I just printed ended up 19 layers (and almost 4 hours) ahead on gcode viewer (and echoed by OctoPod), but normal deviation (slightly off) on Display Layer Progress/Dashboard When this project is done, I'll do a smaller file and provide logs and gcode file for one.
installed plugins,
NONE
the hardware on which you run OctoPrint,
RPI 4 2gb
whether you access it via wired or wireless LAN,
Wireless 5g
from which kind of client you access it (browser interface or some third party client, if browser on what OS, what browser, what version),
Windows 10 - Chrome 81.0
what slicer you have used,
Cura 4.3 , 4.4, 4.5 and 4.6
if all files are affected or only some and if possible also any differences between affected and non affected that come to you mind (e.g. different slicer profile, different slicer, different slicer version etc etc),
what printer,
Ender 3
what firmware you are running on your printer and if you recently upgraded that too by any chance
Marlin 2.5.3
Same problem here. I installed the fix, but now, print viewer is ahead real position.
No problem with Previous octoprint versions.
Any news for this problem??
Regards!!!
It will always be slightly ahead of the position, your printer has buffers which prevent OctoPrint from knowing which command it already executed, the viewer shows you what commands have been sent to the printer.
Hello @all, this is my first post. Sorry if I missed something.
Thank's a lot for OctoPrint and OctoPi!
@foosel, you wrote Mar. 17 .:
I've looked through the difference in the GCODE viewer files between 1.3.12 and 1.4.0 and this is literally the only difference:
Did you notice the difference in the signs (= 1, = -1)?
Maybe it makes a difference?
I'm using S3D 4.1.2 with firmware 3.8.1 on my Prusa MK3S.
I'm back to OctoPrint 1.3.12 and the g-code viewer works now as expected.
Greetings Holger 
