# Python API streaming broken in 4.1.1.1? **URL:** \ **Category:** Support & Troubleshooting\ **Created:** [January 7, 2026, 6:24pm UTC](https://forum.liquidinstruments.com/t/python-api-streaming-broken-in-4-1-1-1/1258 "2026-01-07T18:24:12Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![JackAttack720](https://avatars.discourse-cdn.com/v4/letter/j/ce7236/32.png) [@JackAttack720](https://forum.liquidinstruments.com/u/JackAttack720)\ **Post date:** [January 7, 2026, 6:24pm UTC](https://forum.liquidinstruments.com/t/python-api-streaming-broken-in-4-1-1-1/1258/1 "2026-01-07T18:24:12Z")
**Moku model: Go M2, Firmware 634.0** **Operating system: Windows 11** **Software version: API: 4.1.1.1, CLI: 4.1.1.1, MokuOS 4.1.1** **Bug or support request description:** I’m trying to start a streaming on one of my Moku:Gos, set up as a PID controller, which previously was working before updating to OS 4.1.1. Currently I’m getting an Error code 6 when I try to start streaming for the first time. If I handle and try again, no error is raised, but then the stream status immediately goes into overflow, even for a very relaxed streaming duration of 5s with a 10Hz sample rate. I’d appreciate any insight into this error. See my simplified code example + output below. ```auto from moku import instruments, exceptions # Establish PID controller instrument i = instruments.PIDController(ip='169.254.154.147', force_connect=True) # Setup PID Controller Behavior: i.enable_input(1, enable=True) i.enable_input(2, enable=True) i.set_by_frequency(channel=1) i.set_by_frequency( channel=1, prop_gain=-30.0, int_crossover=0.75, diff_crossover=None, ) i.enable_output(channel=1, signal=True, output=True) i.enable_output(channel=2, signal=True, output=True) i.set_monitor(1, "Output1") i.set_monitor(2, "Input1") # Try to start streaming try: i.start_streaming(duration=5, rate=10, mode="Precision") #Fails with error code 6 except exceptions.MokuException as e: print(e) print('Trying again') # Try again: i.stop_streaming() i.start_streaming(duration=5, rate=10, mode="Precision") print(i.get_stream_status()) # No error print(i.get_stream_data()) # Returns {'':[]} print(i.get_stream_status()) # Overflow error ``` Which outputs ```auto ['An error occurred while starting the logging session (error code 6)'] Trying again {'available_memory': 40800256, 'cumulative_size': 0, 'error': '', 'no_of_chunks': 0, 'status': 'RUNNING', 'stream_id': 'logsink0'} {'': []} {'available_memory': 41029632, 'cumulative_size': 0, 'error': 'Overflow, out of memory', 'no_of_chunks': 0, 'status': 'ERROR', 'stream_id': 'logsink0'} Process finished with exit code 0 ``` ---
**Author:** ![Dylan](https://avatars.discourse-cdn.com/v4/letter/d/e95f7d/32.png) [@Dylan](https://forum.liquidinstruments.com/u/Dylan)\ **Post date:** [January 8, 2026, 1:52am UTC](https://forum.liquidinstruments.com/t/python-api-streaming-broken-in-4-1-1-1/1258/2 "2026-01-08T01:52:37Z")
Hi @JackAttack720 , I have attempted to replicate this but haven’t seen the error on my side. Could you tell me a bit more about the setup, how are you connected to Moku (ethernet, USB, wifi, access point)? Does starting the stream always raise an error or is it intermittent? Are you able to log the data even though you can’t stream? We also just released MokuOS 4.1.2 which I would highly recommend to upgrade to. Looking forward to hearing from you! -Dylan ---
**Author:** ![JackAttack720](https://avatars.discourse-cdn.com/v4/letter/j/ce7236/32.png) [@JackAttack720](https://forum.liquidinstruments.com/u/JackAttack720)\ **Post date:** [January 8, 2026, 2:03am UTC](https://forum.liquidinstruments.com/t/python-api-streaming-broken-in-4-1-1-1/1258/3 "2026-01-08T02:03:44Z")
Hi Dylan, Connected via ethernet. Streaming always raises an error in api, but works fine from the OS. Logging seems to be fine as well. I’ll give OS 4.1.2 a try and see if that resolves it. ---
**Author:** ![JackAttack720](https://avatars.discourse-cdn.com/v4/letter/j/ce7236/32.png) [@JackAttack720](https://forum.liquidinstruments.com/u/JackAttack720)\ **Post date:** [January 9, 2026, 12:08am UTC](https://forum.liquidinstruments.com/t/python-api-streaming-broken-in-4-1-1-1/1258/4 "2026-01-09T00:08:27Z")
Hi @Dylan - an update to 4.1.2 seems to have fixed my problem but given rise to a new one. Streaming now seems last for ~2x as long as the specified duration. Doesn’t seem to be a problem in the OS, but if I ask for a 10s stream in the API, I get a 19.8s one. This is pretty easily solved by manually stopping the stream after finding a time value above a certain timestamp, but certainly a little annoying. I saw in the change logs that the Moku:Lab was having issues where it sometimes turned on in a bad state- could it have been the same for the moku:go? I wonder if a power cycle would’ve solved the problem as well then. ---
**Author:** ![Dylan](https://avatars.discourse-cdn.com/v4/letter/d/e95f7d/32.png) [@Dylan](https://forum.liquidinstruments.com/u/Dylan)\ **Post date:** [January 10, 2026, 1:21am UTC](https://forum.liquidinstruments.com/t/python-api-streaming-broken-in-4-1-1-1/1258/5 "2026-01-10T01:21:29Z")
Hi @JackAttack720 , I have tested both versions of FW (634 and 635) and there doesn’t appear to be a difference in the streaming capabilities. Is it possible that your script has changed? Also, when you mention streaming in the app works, do you mean data logging works as expected? There is no streaming available in the app, it is only supported through use of the API. The symptoms of your issue were different than the issue that was affecting Moku:Lab so I don’t suspect that your unit was affected. ---
**Author:** ![JackAttack720](https://avatars.discourse-cdn.com/v4/letter/j/ce7236/32.png) [@JackAttack720](https://forum.liquidinstruments.com/u/JackAttack720)\ **Post date:** [January 27, 2026, 6:23pm UTC](https://forum.liquidinstruments.com/t/python-api-streaming-broken-in-4-1-1-1/1258/6 "2026-01-27T18:23:29Z")
Hi Dylan, I can confirm that the script did not change, and I did mean data logging. You’re right that it’s not a fair comparison for data logging in app vs streaming in API. The streaming going longer than expected is pretty interesting given that there’s literally a duration that gets passed in as an argument. It’s not a blocking issue at the moment so I haven’t really been investigating it very much. -Jack