After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 645745 - multifdsink: timeout property improperly disconnect clients
multifdsink: timeout property improperly disconnect clients
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.32
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-03-26 13:41 UTC by Nicola
Modified: 2011-10-10 15:57 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nicola 2011-03-26 13:41:23 UTC
Hi,

with this settings in my app:

g_object_set(G_OBJECT (multisink),"resend-streamheader",FALSE,NULL);
g_object_set(G_OBJECT (multisink),"sync-method",2,NULL);
g_object_set(G_OBJECT (multisink),"recover-policy",3,NULL);
g_object_set(G_OBJECT (multisink),"buffers-soft-max",48,NULL);
g_object_set(G_OBJECT (multisink),"sync",FALSE,NULL);
g_object_set(G_OBJECT (multisink),"timeout",10000000000,NULL);

I get

gstmultifdsink.c:2329:gst_multi_fd_sink_queue_buffer:<multisink> [fd    14] client 0x7f3c18002540 is too slow, removing
0:01:36.295588709 18128      0x2113230 INFO             multifdsink gstmultifdsink.c:1157:gst_multi_fd_sink_remove_client_link:<multisink> [fd    14] removing client 0x7f3c18002540 because it was too slow
0:02:19.051654249 18128      0x2113230 WARN             multifdsink gstmultifdsink.c:2329:gst_multi_fd_sink_queue_buffer:<multisink> [fd    34] client 0x21c6690 is too slow, removing
0:02:19.051676947 18128      0x2113230 INFO             multifdsink gstmultifdsink.c:1157:gst_multi_fd_sink_remove_client_link:<multisink> [fd    34] removing client 0x21c6690 because it was too slow

while with this settings:

g_object_set(G_OBJECT (multisink),"resend-streamheader",FALSE,NULL);
g_object_set(G_OBJECT (multisink),"sync-method",2,NULL);
g_object_set(G_OBJECT (multisink),"recover-policy",3,NULL);
g_object_set(G_OBJECT (multisink),"buffers-max",96,NULL);
g_object_set(G_OBJECT (multisink),"buffers-soft-max",48,NULL);
g_object_set(G_OBJECT (multisink),"sync",FALSE,NULL);

in the same test environment I can see the stream for hours, so timeout property seems broken, please note that when multifdsink disconnect the client the video is not freezed (and the date/time overlay show no delay) so the client is properly reading the stream
Comment 1 Vincent Penquerc'h 2011-08-25 12:03:44 UTC
Do you have a gst-launch pipeline showing this behavior ?
Comment 2 Akhil Laddha 2011-10-07 05:50:56 UTC
Nicola, ping
Comment 3 Nicola 2011-10-07 07:03:26 UTC
Sorry for the delay, I tryed to reproduce this using tcpserversink with no success, I'll try to wrote a test app this weekend, thanks
Comment 4 Nicola 2011-10-10 06:29:19 UTC
I'm unable to reproduce this issue with recent gstreamer release (0.10.35 and git)
Comment 5 Tim-Philipp Müller 2011-10-10 15:57:37 UTC
Ok, will close as obsolete then, thanks for testing.