Disconnect of unicast clients about mumudvb

[braice]

indeed dvr_buffer_size is on the reading side.

These errors says your os cannot send as fast as it should, this could be
because of full buffers, ack not coming fast enough etc...

you can try to play with
http://mumudvb.braice.net/doc/mumudvb-1.7.2/README_CONF.html#_http_unicast_parameters

There is also system wide options for tcp stream, I don't remember exactly
but you can find theam easily on google.

Anyway keep me updated about your results (fore more help and documentation)

Best

2013/9/2 Patrick Huber [email protected]

When receiving a full playlist in parallel, I get disconnects from mumudvb
when receiving a full multiplex. Is there a way to debug this? I've tested
dvr_buffer_size but that doesn't seem to have an influence on this. Also,
the disconnect doesn't seem to be clean, the client (java URLConnection)
doesn't abort.

Deb0: Unicast : Error when writing to client 192.168.2.101:20901 : Interrupted system call
Info: Unicast : Consecutive errors when writing to client 192.168.2.101:20901 during too much time, we disconnect
Deb0: Unicast : Error when writing to client 192.168.2.101:20133 : Resource temporarily unavailable
Deb0: Unicast : Error when writing to client 192.168.2.101:19877 : Resource temporarily unavailable
Deb0: Unicast : Error when writing to client 192.168.2.101:19621 : Resource temporarily unavailable
Deb0: Unicast : Error when writing to client 192.168.2.101:21157 : Resource temporarily unavailable
Deb0: Unicast : Error when writing to client 192.168.2.101:20389 : Resource temporarily unavailable
Info: Unicast : Consecutive errors when writing to client 192.168.2.101:19877 during too much time, we disconnect
Info: Unicast : Consecutive errors when writing to client 192.168.2.101:19621 during too much time, we disconnect
Info: Unicast : Consecutive errors when writing to client 192.168.2.101:20133 during too much time, we disconnect
Info: Unicast : Consecutive errors when writing to client 192.168.2.101:21157 during too much time, we disconnect
Info: Unicast : Consecutive errors when writing to client 192.168.2.101:20389 during too much time, we disconnect

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/28
.

[braice]

Hello
Do you have news on this topic ?

[stackmagic]

Not much except that it looks like that now, that the client is running on a different host the problem seems to have gone away. I haven't had time to do much in-depth testing on this. The system in question used a usb-ethernet adapter with an asix chip which apparently can drop packets every now and then.

Do you have any way to send a RST on the connection? I had a look around your code and you do a normal close(socket) and there's probably not much you can do. Everything seemed alright (but I'm really not a C wizard).

[braice]

Normally the OS deal with the exact TCP flags

I also recently corrected a few bugs in this part like double close etc...

Please open this issue again if you experience new troubles

Best regards

2013/10/2 Patrick Huber [email protected]

Not much except that it looks like that now, that the client is running on
a different host the problem seems to have gone away. I haven't had time to
do much in-depth testing on this. The system in question used a
usb-ethernet adapter with an asix chip which apparently can drop packets
every now and then.

Do you have any way to send a RST on the connection? I had a look around
your code and you do a normal close(socket) and there's probably not much
you can do. Everything seemed alright (but I'm really not a C wizard).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/28#issuecomment-25566111
.

[scramatte]

I got similar issue with HD stream, I'm unable to open it through HTTP. Multicast works well

Error when writing to client x.x.x.x:23248 : Resource temporarily unavailable

[braice]

Hello

http://stackoverflow.com/questions/5737493/sendto-resource-temporarily-unavailable-errno-11

It means that we are still waiting for the ack of the previous packet.

Does this kind of thing helps ?
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-Reducing_the_TCP_delayed_ack_timeout.html
http://serverfault.com/questions/357799/improving-tcp-performance-over-a-gigabit-network-with-lots-of-connections-and-hi

If yes tell me which one so I can improve the FAQ

Best

Brice

2014-08-06 20:19 GMT+02:00 scramatte [email protected]:

I got similar issue with HD stream, I'm unable to open it through HTTP.
Multicast works well

Error when writing to client x.x.x.x:23248 : Resource temporarily
unavailable

—
Reply to this email directly or view it on GitHub
#28 (comment).