Multipart-stream-decoder still doing something when disabled

General
1

I noticed then even after disabling the entire flow, my three multipart-stream-decoder nodes are still popping up streaming or error signals depending on what I am doing with the source feeds.

Seems a bit sus :stuck_out_tongue:

image

Probably just a quirk... as having an active debug node connected confirms no activity. But I thought I would bring it up just in case.

2

just part of the status

setTimeout(function() {
                    node.status({fill:"red",shape:"ring",text:"server not responding"});
                    node.statusUpdated = true;
                },10);

see ---> https://github.com/bartbutenaers/node-red-contrib-multipart-stream-decoder/blob/master/multipart_decoder.js

did not look though the code but I'm guessing its the only thing timing out in the code and then posting the msg. Supper odd that disabling the flow allows anything to time out.

does it do it after 10seconds of disabling the flow ?

3

It is constantly flashing the blue or red icons and messages even 24 hours later.

OK, but I got thinking about that... how would it know the status if it is not querying the source URL... and that is what I am trying to prevent it from doing by disabling.

4

Code executed by setTimeout() is called from an execution context separate from the function from which setTimeout was called.

If I had to guess by disabling the flow setTimeout() is allowed to time out :slight_smile:

5

Wrong!! Hmm, turns out that even when disabled the node keeps on ticking...

image
image999×279 38 KB

Looks like patient zero of the pending zombie-node-apocalypse :zombie:

As I am trying to test the ESP32CAMs, that these nodes connect to, with other software to determine best FPS use case... I will simply have to export and delete this flow. Not as convenient as disabling, but for sure should stop it like a headshot :laughing:

1 Like
6

OK, perhaps I was using that node incorrectly??

It seems if you enter a URL directly into it's settings... It never forgets and never stops running (think Energizer bunny) :battery: :rabbit2:

So I set it up with external URL feeds and a stop command. That seems to let me control it better.

image
image1463×312 132 KB

7

Hi @Gunner,

I should fix that, because it is indeed not good to keep streaming large amounts of data when the node or flow is disabled. Can you also raise an issue on Github, to make sure I don't forget it?

I'm off to work now, but if somebody already knows how I can check if the node or flow is disabled, then they can share that here. I don't think I have used that before.

@meeki007: thanks for helping Gunner while I was sleeping :wink:

1 Like
8

@Gunner,
I wanted to reproduce the issue quickly during my lunch break, but it "seems" to work fine.
When I disable the multipart-stream-decoder node, I have to deploy my changes which causes the streaming to be stopped:

multipart_decoder_disabled

Or do you expect the streaming to stop as soon as the node is disabled, without deploy the disabled state to the server? Not sure whether that is expected Node-RED behaviour of custom nodes?

I would expect a node to be disabled as soon as you deploy the disabling of that node to the server... But I can be totally wrong about this!

9

Correct. They are not disabled until that change deployed

1 Like
10

@Gunner,

Here is my example flow, which uses a public available camera (which makes it easy to have an exchangeable test case):

multipart_decoder_demo

[{"id":"c4261d3c.0f8f9","type":"inject","z":"500d093929e86011","name":"Life cam street view","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":"","topic":"","payloadType":"date","x":310,"y":280,"wires":[["951697d4.c20318"]]},{"id":"951697d4.c20318","type":"change","z":"500d093929e86011","name":"","rules":[{"t":"set","p":"url","pt":"msg","to":"http://209.206.162.230/mjpg/video.mjpg","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":544.7093048095703,"y":280.0633544921875,"wires":[["df0434ac.67b098"]]},{"id":"7b3f810f.f6aae","type":"comment","z":"500d093929e86011","name":"Camera feed from http://www.opentopia.com/webcam","info":"","x":394.3382110595703,"y":243.692249417305,"wires":[]},{"id":"df0434ac.67b098","type":"multipart-decoder","z":"500d093929e86011","name":"","ret":"bin","url":"","tls":"","delay":0,"maximum":"9999999999","blockSize":"1","x":750,"y":280,"wires":[["55b3f06ec598fc0f"]]},{"id":"55b3f06ec598fc0f","type":"image","z":"500d093929e86011","name":"","width":"320","data":"payload","dataType":"msg","thumbnail":false,"active":true,"pass":false,"outputs":0,"x":980,"y":280,"wires":[]}]

Can you please explain step-by-step how I can reproduce your issue with this flow?

12

Well, I had already wiped out the "offending" flow. But my initial post image clearly shows it "doing something" with everything else disabled and deployed.

However, when trying to recreate it as best as I can, based on my own screenshots above... it seems to stop as it should. Go figure.

image
image767×286 50.8 KB

image
image766×169 10.7 KB

Anyhow... all of those past issues might have been a "perfect storm" scenario :thinking:

So, short of reproducing the issue of this topic, and since it seems to work perfectly with my new fed URL, I guess I can live with what ever happened as a past issue.

13

Ah yes now I see what you mean:

image

There are 3 possibilities in my mind:

  1. You disabled the decoder node, but didn't deploy. However from what I read above, this won't be the case.
  2. The node gets input messages while it is disabled (e.g. due to a replayed old msg by the ui_control node or something like that). But that can't be the case because then all 3 decoder nodes should get those messages.
  3. There is somewhere a bug in my node. But I can't imagine how it could start without getting a message.

No idea to be honest ...

14

Actually all three nodes were constantly displaying flashing streaming messages for over a day (with the entire flow disabled)... I just wasn't paying too much attention at the time while setting up another Blue Iris Server.

It wasn't until I started taking the cameras offline, when working with Blue Iris, that the nodes gave the red "not responding" msg. I can't recall for sure, but I think they went back to the blue "streaming" message when the cameras came back on line.

Also... and I have no way of testing this anymore as I have since deleted the flow to keep those little ESP32 cameras from being overwhelmed by too many client calls, but after copying those nodes to another flow, when troubleshooting for this topic, the issue turned out to be non-reproducible.

So somewhere, somehow, I suspect that entire tab/flow was compromised during all my prior days of testing and experimenting with nodes and styles, leading up to "producing" my final results that I had posted here.

In the end, we have an unsolved mystery... but probably not one that will make it to any historical status :stuck_out_tongue:

1 Like
15

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.