i was trying [iemnet/udpsend] - looked promising for an hour! but then: iemnet: socket-shutdown: Transport endpoint is not connected this was printed not to console but to the terminal several times before it switched to watchdog: signaling pd…. at which point pd was gone.
as for the workaround: “catching the 0 message” does not work for me since neither [iemnet/udpsend] nor [netsend -u -b] acknoledge that their connection is lost. it acknoledges if the network itself is down…like, if there is no WLAN reachable... but one can issue arbitrary IP addresses, and the obejct will tell you it established connection. i guess this is consistend with the UDP protocol
On 17 Feb 2019, at 13:35, Christof Ressi christof.ressi@gmx.at wrote:
Just for the record, do you get the freeze only with [netsend] or also with [iemnet/udpsend] resp. [mrpeach/udpsend]?
Gesendet: Sonntag, 17. Februar 2019 um 11:53 Uhr Von: "michael strohmann" itsnotfair9@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-List pd-list@lists.iem.at Betreff: Re: Aw: Re: [PD] non-socket (88)
This non-socket(88) gives me the creeps because it seems to freeze pd immediately without any possibility to recover/interact with pd. Also I could find out what caused the non-socket Problem - actually don’t know where to look...
Am 17.02.2019 um 10:52 schrieb Christof Ressi christof.ressi@gmx.at:
in the meantime, are there any options to send osc via udp regardless of the existance of a receiver?
You can use the workaround described by iohannes in the github issue: simply reconnect whenever the socket is closed (catching the 0 message). I want to really make a PR for those network issues, can you open an issue on github for your problem (88)? I have time in march.
Gesendet: Sonntag, 17. Februar 2019 um 09:23 Uhr Von: "michael strohmann" itsnotfair9@gmail.com An: "Lucas Cordiviola" lucarda27@hotmail.com Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: [PD] non-socket (88)
i am sending OSC messages with [netsend -u -b]
there is obviously an issue with [netsend] closing the socket if nobody is listening. which it should not do in UDP mode. https://github.com/pure-data/pure-data/issues/373 https://github.com/pure-data/pure-data/issues/373
but this:
netsend: Socket operation on non-socket (88)
is lethal to my patch. immediate freeze unfortunatly it occurs quite often.
i also know next to nothing about Sockets is it a pd problem or does it stem from the os (unix jessie in my case, on raspberry) ???
also due to Christof Ressi: I can confirm that both [iemnet/udpsend] [mrpeach/udpsend] (from Pd extended) close the socket on Linux but only [mrpeach/udpsend] gives a warning and sends a 0. I'll do a bug report.
in the meantime, are there any options to send osc via udp regardless of the existance of a receiver?
cheers! michael
On 16 Feb 2019, at 20:06, Lucas Cordiviola lucarda27@hotmail.com wrote:
Did you tried sending every second an empty message [send ( instead of "reopening a connection" ?
Mensaje telepatico asistido por maquinas.
On 2/16/2019 3:57 PM, michael strohmann wrote: i finally could caught pd in the act of freezing:
the console said:
recv: Connection refused (111) netsend: Socket operation on non-socket (88) warning: 33 removed from poll list but not found
i connect every second to mobile phones that run Lemur to send and receive OSC usually if a phone leaves the network, nothing bad happens, the console says:
recv: Connection refused (111) netsend: Bad file descriptor (9) warning: 32 removed from poll list but not found
So it seems to me that this non-socket(88) problem manages to freeze pd (or is it this number: 88, which has a bad connotation in austria ?)
Thanks! michael
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list