Jan M

I ran into a similar problem as discussed here: 

https://cycling74.com/forums/udp-receive-crashing-live-max-for-live/

My Live Set crashes and it seems to be [udpreceive] related. Downgrading to 6.1.6 (as discussed in the thread above) is unfortunately not an option and concerts coming up in 2 days ...

However, it seems to be reasonably stable when I use a really big maxqueuesize for [udpreceive]. Currently I have set it to 18432 (512 x 36). Does anyone know wether there are theoretical or practical limits to maxqueuesize? Not speaking about max avail memory on the computer ;). My question is, if there is a point where it might affect the [udpreceive] object negatively?

I ran into a similar problem as discussed here: https://cycling74.com/forums/udp-receive-crashing-live-max-for-live/

udpreceive-maxqueuesize-limits

Hi, can't imagine there are any implications other than using more memory to have a larger queue. Are you sure you're hitting the queue limit - Max will post messages in the Max window when messages are being dropped due to queue size

No I am not 100% sure. The set is a bit too complex to really nail it down within a reasonable amount of time (before the gig starts. :)). It is a high level observation that the crashes appear when a lot of data (fast continuos streams) come in for a longer time. And the crashes seem to appear sooner in time when the maxqueue is smaller.

It is clearly a M4L problem. The same data stream is send to another computer running pure max (and taking care of the visual). No problems there.

Just in case someone bumps into this thread in the future: Thanks to Andrew, the bug was spotted. it turned out not to be [udpreceive] related, but a memory allocation issue. switching to 64 bit Live brought the answer.

[udpreceive] maxqueuesize limits?