119 replies to this topic

[athoik]

gs = green screen

[christophecvr]

No just the message service not found. check tuner config.

 

Read toppic with the revert all back ok.

 

 

http://forums.openpl...ndpost&p=519840

Edited by christophecvr, 18 December 2015 - 22:09.

[mx3L]

I tried to find out why was http timeout introduced. I find this commit:

https://github.com/O...d4d1edc6ab5b4f9

 

In commit message it says "introduces feature #551". Does anybody know where can I find out what feature #551 means?

 

Then I find out this modification to http timeout:

https://github.com/O...6b1f3e5dc435912

 

In commit message is interesting part:

"As the UI is not blocked anymore I suggest this may not harm."

 

So UI was blocked until http timeout was reached?

 

I was trying to find commit which unblocked UI, but to no avail.

 

Perhaps somebody could clear this up, since I don't remember of UI being blocked until http stream started to play.

Edited by mx3L, 19 December 2015 - 10:13.

[athoik]

In commit message it says "introduces feature #551". Does anybody know where can I find out what feature #551 means?

I guess this one: "[enigma2-cvs] branch, feature_551_rtspstreaming, created"

https://lists.elited...uly/006851.html

[christophecvr]

There is something weird on that time out. But could quit be possible that it's required for gst-0.1xx and not by gst-1.0 ??

[ian1095]

Any progress on this ?

 

Has anything been decided regarding the HTTP_Timeout ?

 

Because its a right pain in the arse the way it is at the moment since recent updates have ensured that END kills the pipe and no its no longer possible to simply press OK to continue the stream,it needs addressing.

 

Ian.

[athoik]

Here is my patch: https://github.com/a...c4cbd26d5e8da32

Can you test it?

[ian1095]

unfortunately not.

 

Im unable to compile the new servicemp3 file.

 

But looking at the code it looks like that solution would be perfect.

 

Ian.

[mx3L]

@athoik

Thanks, unfortunately I still didn't find out why was timeout introduced.

 

 

I notice that we also set timeout for souphttpsrc right after we start timer with the same timeout. So timer makes sense, we shouldn't continue after souphttpsrc is timed out.

From log created by @ian1095 and previous possibility of resuming playback after EOF, it's clear that we are stopping timer too late, since souphttpsrc is clearly not timed out.

 

We are stopping timer after PAUSED_TO_PLAYING state change of pipeline. Ideally we should stop it after souphttpsrc makes connection.

 

I find out that when souphttpsrc times out, we get specific resource error messages on the bus:

 

GST_RESOURCE_ERROR_OPEN_READ or

GST_RESOURCE_ERROR_OPEN

http://gstreamer.fre...stResourceError

 

So I think we can remove timer and stop pipeline + send evEOF when one these messages is on the bus:

diff --git a/lib/service/servicemp3.cpp b/lib/service/servicemp3.cpp
index b180476..014a54b 100644
--- a/lib/service/servicemp3.cpp
+++ b/lib/service/servicemp3.cpp
@@ -401,7 +401,6 @@ eServiceMP3::eServiceMP3(eServiceReference ref):
        m_pump(eApp, 1)
 {
        m_subtitle_sync_timer = eTimer::create(eApp);
-       m_streamingsrc_timeout = 0;
        m_stream_tags = 0;
        m_currentAudioStream = -1;
        m_currentSubtitleStream = -1;
@@ -525,8 +524,6 @@ eServiceMP3::eServiceMP3(eServiceReference ref):
        if ( m_sourceinfo.is_streaming )
        {
                uri = g_strdup_printf ("%s", filename);
-               m_streamingsrc_timeout = eTimer::create(eApp);;
-               CONNECT(m_streamingsrc_timeout->timeout, eServiceMP3::sourceTimeout);
 
                if ( m_ref.getData(7) & BUFFERING_ENABLED )
                {
@@ -777,13 +774,6 @@ RESULT eServiceMP3::start()
        return 0;
 }
 
-void eServiceMP3::sourceTimeout()
-{
-       eDebug("[eServiceMP3] http source timeout! issuing eof...");
-       stop();
-       m_event((iPlayableService*)this, evEOF);
-}
-
 RESULT eServiceMP3::stop()
 {
        if (!m_gst_playbin || m_state == stStopped)
@@ -807,8 +797,6 @@ RESULT eServiceMP3::stop()
 
        saveCuesheet();
        m_nownext_timer->stop();
-       if (m_streamingsrc_timeout)
-               m_streamingsrc_timeout->stop();
 
        return 0;
 }
 RESULT eServiceMP3::stop()
 {
        if (!m_gst_playbin || m_state == stStopped)
@@ -807,8 +797,6 @@ RESULT eServiceMP3::stop()
 
        saveCuesheet();
        m_nownext_timer->stop();
 
        return 0;
 }
@@ -1750,8 +1738,6 @@ void eServiceMP3::gstBusCall(GstMessage *msg)
                                }       break;
                                case GST_STATE_CHANGE_PAUSED_TO_PLAYING:
                                {
                                {
-                                       if ( m_sourceinfo.is_streaming && m_streamingsrc_timeout )
-                                               m_streamingsrc_timeout->stop();
                                        m_user_paused = false;
                                        m_paused = false;
                                        if (m_seek_paused)
@@ -1803,6 +1789,14 @@ void eServiceMP3::gstBusCall(GstMessage *msg)
                                                m_event((iPlayableService*)this, evUser+10);
                                }
                        }
+                       else if ( err->domain == GST_RESOURCE_ERROR )
+                       {
+                               if ( err->code == GST_RESOURCE_ERROR_OPEN_READ || err->code == GST_RESOURCE_ERROR_READ )
+                               {
+                                       stop();
+                                       m_event((iPlayableService*)this, evEOF);
+                               }
+                       }
                        g_error_free(err);
                        break;
                }
@@ -2155,9 +2149,8 @@ void eServiceMP3::gstBusCall(GstMessage *msg)
                                        gst_element_get_state(m_gst_playbin, &state, NULL, 0LL);
                                        GstElementFactory *factory = gst_element_get_factory(GST_ELEMENT(owner));
                                        const gchar *name = gst_plugin_feature_get_name(GST_PLUGIN_FEATURE(factory));
-                                       if (!strcmp(name, "souphttpsrc") && (state == GST_STATE_READY) && !m_streamingsrc_timeout->isActive())
+                                       if (!strcmp(name, "souphttpsrc") && (state == GST_STATE_READY))
                                        {
-                                               m_streamingsrc_timeout->start(HTTP_TIMEOUT*1000, true);
                                                g_object_set (G_OBJECT (owner), "timeout", HTTP_TIMEOUT, NULL);
                                                eDebug("[eServiceMP3] GST_STREAM_STATUS_TYPE_CREATE -> setting timeout on %s to %is", name, HTTP_TIMEOUT);
                                        }
diff --git a/lib/service/servicemp3.h b/lib/service/servicemp3.h
index ef243bc..45f4d52 100644
--- a/lib/service/servicemp3.h
+++ b/lib/service/servicemp3.h
@@ -361,7 +361,6 @@ private:
        subtitle_pages_map_t m_subtitle_pages;
        ePtr<eTimer> m_subtitle_sync_timer;
 
-       ePtr<eTimer> m_streamingsrc_timeout;
        pts_t m_prev_decoder_time;
        int m_decoder_time_valid_state;
 

Tested this to simulate timeout, looks to be working as expected

http://stackoverflow...n-timeout-error

#SERVICE 4097:0:0:0:0:0:0:0:0:0:http%3a//10.255.255.1:timeout

Attached Files

•  0001-test_http_timeout.patch   3.31KB   11 downloads

[ian1095]

Nice one.

 

Any idea when this will be applied ?

 

Hopefully as soon as possible to get rid of this annoying bug once and for all.

 

Ian.

[ian1095]

Sorry to keep pushing this thread but can someone PLEASE apply this patch so that streaming is fixed over Christmas ?

 

Otherwise it will mean having to flash a backup from a time before all these pause commits were made to the image,just so pressing the OK button when END appears onscreen works once more.

 

Thanks.

 

Ian.

[ian1095]

Anyone ?

 

Is the fix going to be applied or not ?

[Erik Slagter]

Ask the patch contributer to contribute it properly with a good description of what it fixes and how it works. Otherwise you can wait a loooong time.

[ian1095]

So who do I ask mxl3 ? or athoik ? as I dont know which fix you prefer to use.

 

Via pm or just here ?

 

seems a shame that they have gone to the trouble of writing the code to fix this then for it not to be used.

 

Ian.

[ian1095]

@MX3L

 

Are you going to contribute your patch ?

 

It desperately needs adding.

 

Ian.

[mx3L]

Hi,

 

Sorry, I didn't have time to test this patch more thoroughly I just did brief test.

I will get to it, in the meantime, it would be great if you could you try it and confirm that it resolved your problem.

[ian1095]

Many thanks.

 

I would absolutely love to test this as I really feel it will fix this issue,but I'm unable to build a servicemp3 file so I cannot,but if someone would build one for a solo gen 1 box then I will happily test this for you.

 

Ian.

[mickd]

Is there a problem with the headers on hls streams? When the initial request is made the correct headers are sent to the server but on subsequent requests the User-Agent sent is "Gstreamer souphttpsrc...". This results in a http error 403.

[betacentauri]

Some servers except special user agents. E.g. when you try to open streams which should be used by TVs (Hbbtv).

[mickd]

The stream I am trying to open requires the correct headers, User-Agent, Connection, Accept ..etc and Cookie. On the first request all is correct.This can be the manifest file. On the next request the correct header and cookie are not sent only the User-Agent: Gstreamer souphttpsrc and some others. The server responds with the 403 error and that's the end of playback. Is there some other setting to make gstreamer pass the same header and cookie on each request?