search

dceejay / tfjs-coco-ssd

Node-RED node for tensorflowjs coco ssd
Apache License 2.0
14 stars 10 forks source link

"Error: ENOENT: no such file or directory, open" #25

Closed krambriw closed 1 year ago

krambriw commented 1 year ago

"Error: ENOENT: no such file or directory, open"

From time to time I get this error message in the debug log. Normally it runs fine but then suddenly I can see one or two of those. Using version 1.05 on a RPi4 (used "npm rebuild @tensorflow/tfjs-node --build-from-source" to make it work after installation via palette i NR)

dceejay commented 1 year ago

odd - tricky to suggest anything when it doesn't mention which file or directory. Is there any more to the message like a line number and file that the error is coming from ?

krambriw commented 1 year ago

This is all I get in the NR debug tab. I will run the node-red-log in a command prompt to check if it says more, Otherwise I guess the string might reside somewhere in a module, maybe in a library that is used??

krambriw commented 1 year ago

For the time being, think we can close this issue since now I do suspect that it is the provided image data that might be corrupt. Images are pushed by ffmpeg and to debug I attached another node in parallel (Image tools by Steve). After a while I got this in the NR log (similar in the debug tab): 8 Feb 11:08:51 - [error] [jimp-image:bdd8bcc7e83e70f0] Error: property 'image' is not valid 8 Feb 11:08:51 - [error] [tensorflowCoco:5caa26e6b8f321be] Error: ENOENT: no such file or directory, open

So it seems the image data is corrupted in some way, obviously no good. Nothing wrong with tf-coco-ssd node

Best regards, Walter

dceejay commented 1 year ago

Ok - thanks for letting me know - is it corrupt or jus not present ? (IE can you detect that fact before passing to tfjs and stop it trying to process bad/null data ?

krambriw commented 1 year ago

I found the reason: the text message "no such file or directory, open" is coming from ffmpeg when it fails to open the url. When this message (the content of the msg.payload) is forwarded to the tf-coco-ssd node, it generates that error message as described above. Fully understood and adding some smart filtering before forwarding it to the node will solve the problem. Right now, just putting Steve's Image tool node in front of the tf-coco-ssd node does stop it from being forwarded further in the flow