Felipe W Damasio

hey @Neilpang, Thanks for the feedback. First of all, this is a great project, but I just digged into the code because of this issue. So, sorry for not knowing...

We’ve since upgraded to the latest stable patches (`2.4.9-f8dcd9f`) to see if help fix this, since there’s a dns-related patch in 67f6af5b.

hi @winlinvip thanks for the quick reply. Not only a conf bug, because the simple patch above seems to fix that. But the peer timeout itself seems to be completely...

hey @xiaozhihong, that's it! If the publishing-side exited, I don't see a reason for the client-side just to hang there, not exiting ever. Because I tested re-publishing after 10min on...

hey @xiaozhihong, Given the comment here https://github.com/Haivision/srt/issues/2653#issuecomment-1429651602 I guess the proper behavior on SRS-side is to break the client-facing connection if there's no more publish? Ignoring the transport keep-alive, then....

Just a quick note: I've tried recompiling haproxy with USE_SLZ=1 instead of USE_ZLIB=1...but didn't change anything. And for some reason, 2.9.7 is also affected by this.

I isolated the same config on another machine and couldn't reproduce the issue. Something about our production seems to have a special fairy dust for these kinds of things :-)

hey @capflam, thanks for the quick reply. We were able to collect these traces: ``` 2024-04-15T11:28:48.772952+00:00 [04|h1|0|mux_h1.c:2942] chunk smaller than announced : [F,RUN] [MSG_DONE, MSG_DATA] - req=(.fl=0x00001510 .curr_len=0 .body_len=0) res=(.fl=0x00011716...

Just a quick follow-up: dev6 and 2.9.6 are also affected by this symptom. Seems easy enough to cause in production, if you'd like me to test something else. Don't know...

hey @capflam I can confirm this fixes the issue. Great and fast work, as usual :-) Thanks!