[Bug 683536] New: Souphttpsrc handles long pause (long enough to timeout TCP socket connection) as EOS.

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=683536
  GStreamer | gst-plugins-good | 0.10.31

           Summary: Souphttpsrc handles long pause (long enough to timeout
                    TCP socket connection) as EOS.
    Classification: Platform
           Product: GStreamer
           Version: 0.10.31
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: nwaschbu at opentv.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.