Interface falls into an "disabled" state on warmup

[imitation]

With the latest devel 260a378 , Octoprint chokes on my start.gcode. The interface goes into an "disabled" state, where all controls are disabled and the console is greyed-out. A reconnect to the printer does not fix the issue, a restart of Octoprint does.
I'm using two extruders in Marlin, one is my hotend, the other the second half of my bed.

This is my start gcode, Octoprint makes it approximately to ";Aufheizen":

;init
M80
M666
M220 S80
M221 S100
M201 Y600
M203 E40 Y150
M205 X15 E0.3
T0
;Licht
M42 P27 S255
M42 P25 S255
M42 P23 S0
M42 P17 S0
M42 P9 S0
;Temp während Home
T1
M104 S[first_layer_bed_temperature]
T0
;M104 S[first_layer_temperature]
M140 S[first_layer_bed_temperature]
;Home, Parken
G28 Z Y
G0 Z200
G28 X
G0 X20 Y10 Z2
G1 Z0.1 F200000
M400
G92Z1.9
G1 Z0.1 F200000
M84
;Aufheizen
M104 S0
M190 S118
M140 S[first_layer_bed_temperature]
M109 S[first_layer_temperature]
M190 S[first_layer_bed_temperature]
M400
M42 P17 S255
M42 P23 S255
M42 P9 S255
;Purge
G92 E0
G1 Z2 F9001
G0 X2 Y10 Z0.3 F100000
G1 E6 F150
G1 E9.5 Y50 F500
G0 Z1.5 Y5 E9.1 F200000
G92 E0
G92 E0
T1
M109 S120
T0
M333 L222 R222 A

[foosel]

Could you provide serial.log and octoprint.log? -> https://github.com/foosel/OctoPrint/wiki/How-to-file-a-bug-report

Also:

M140 S[first_layer_bed_temperature]
M109 S[first_layer_temperature]
M190 S[first_layer_bed_temperature]

I guess you copied that from the actual start.gcode definition in your slicer, not from an actual gcode file, right? If yes, if you could should an actual file my way, that would be great too.

[imitation]

Your're right, sorry.
Octoprint.log: http://pastebin.com/9u5Nvbrp
Serial.log: http://pastebin.com/9t4xKLGL
First 500 lines of gcode, as generated by Slic3r: http://pastebin.com/efgY8XU9
Full gcode (likely not available forever): https://www.dropbox.com/s/glw5geqt6ycxa0q/speakerGrill%20%28repariert%29.gcode
I'm actually not so sure anymore when exactly it is that the interface becomes unresponsive - I hit print and the print information immediately looked funky, so i reloaded the page and got the defunct interface.

[imitation]

Ok, this is interesting: Printing a file that was uploaded before the latest git pull works just fine. Both files have an identical startup gcode and the (defunct) file in .octoprint/uploads has apparently uploaded properly.

[imitation]

Reuploaded the known-good gcode, and that also crashes the UI. So i think it's safe to assume that any file that is uploaded in the current state will end up failing the UI.

[foosel]

Currently simulating the print of your complete gcode file (uploaded via the devel version) without issues. This is a long shot but: have you tried clearing the browser cache? I've switched around so many things, and especially the format of the metadata for the gcode files has changed, so maybe some old code is getting confused here.

I guess the communication timeout messages in the serial.log are the regular long-move-things, at least judging from the preceding commands. Still haven't come around to looking further into reworking the communication layer, sorry :/

[imitation]

Yes, the timeouts are normal, they're just the long move of the z-axis.
I tried reproducing the error in Chrome (freshly cleared), and it persists.
After removing .octoprint, the error is still there.
Even with a from-scratch clone i'm seeing the exact same behavior.

[foosel]

Do you see any javascript errors in Chrome? (F12 > Console)

[imitation]

Yes.

[foosel]

The fresh config combined with a multi extruder file appears to be the trick, because OctoPrint then tries to access offset information for an extruder (T1 in your case) that isn't available and falls flat on its face. Just triggered that and see the exact same problem now that you saw. Fixed it and pushed the commit, can you confirm that it works for you too?

Now looking into the javascript error above, that's probably caused by the backend hiccuping and returning invalid data, but some more error resilience would be nice there I guess.

[foosel]

And should have fixed that too.

[imitation]

Seems like that second commit did the trick. Awesome, thanks!