GNOME Bugzilla – Bug 683536
souphttpsrc: Handles long pause (long enough to timeout TCP socket connection) as EOS
Last modified: 2013-11-09 09:45:31 UTC
Handling long pause as EOS makes it hard to distinguish in between the following two scenarios: ================================================================================================ Scenario a) - EOS because of entire content being read by the souphttpsrc. Scenario b) - EOS because of resume after long pause (that caused timeout of TCP socket connection). The EOS up to the gstreamer app might be delayed by minutes depending on the amount of buffering and the consumption rate. IMHO, this would make it hard for the user to realize that the "pre-mature" EOS was caused by the long pause. Desired bahvior: ================ Have create() return GST_FLOW_ERROR plus send error message to gstreamer app whenever user resumes after long pause (that caused timeout of TCP socket connection). Question: ========= In order to distinguish in between scenario a) and b), could we check during the handling of the got_body signal ... - whether we have_size - and if yes, whether content_size is larger read_position ?? This is probably not the most elegant option, but still thought to throw it out to get discussion going... Please be so kind on comment on this. It would be much appreciated. Somewhere online I've read the following below. Copied and pasted here as additonal background. ================================================================================================ If you let pipeline in PAUSED state for a long time, TCP receive queue (advertisement window) will be decreased, continuously. The reason is, 1. souphttpsrc will try to streaming the content even though in PAUSED state 2. Some feeding context (gst_pad_push) will be blocked in some case queue full, adec/vdec buffer full…. 3. libsoup can’t read data from socket because our process is blocking 4. unread packets in TCP receive queue are will be grown 5. your device advertise TCP zero window 6. TCP streaming will be blocked 7. Server will close connection if the TCP persist timeout is occurred ... If the number of retries exceed above value, kernel will close current socket and send a FIN to peer. When a client receive FIN packet in the middle of socket reading, syscall (read, recv..) will return zero and libsoup handle this case as a EOF.
Still an issue with current git. 0.10 is not getting any more development. So moving issue to 1.x.
Created attachment 256653 [details] [review] souphttpsrc: do not emit EOS when connection drops If the pipeline is stalled for too long, souphttpsrc will block and stop fetching data from the network. This can cause the connection to drop and souphttpsrc would handle it as an EOS. This patch makes it persist and try to fetch more data until the end of the content length or until receiving an error that it is beyong limits in case the content is unknown.
Does this already solve bug #663542 then?
Created attachment 256759 [details] [review] souphttpsrc: do not emit EOS when connection drops Updated patch to check on finished_cb for the content_length and stop earlier. Tested full playback, long pauses and killing the connection with tcpkill. All 3 scenarios are still working.
*** Bug 663542 has been marked as a duplicate of this bug. ***
Review of attachment 256759 [details] [review]: Did you also check if you broke seeking? ;) If you didn't, please push :)
commit 856c07ea0084bf249103c2b58dc61f151c3d7c98 Author: Thiago Santos <ts.santos@partner.samsung.com> Date: Mon Oct 7 14:27:21 2013 -0300 souphttpsrc: do not emit EOS when connection drops If the pipeline is stalled for too long, souphttpsrc will block and stop fetching data from the network. This can cause the connection to drop and souphttpsrc would handle it as an EOS. This patch makes it persist and try to fetch more data until the end of the content length or until receiving an error that it is beyong limits in case the content is unknown. https://bugzilla.gnome.org/show_bug.cgi?id=683536