Jump to content


Photo

Stream stop


  • Please log in to reply
119 replies to this topic

Re: Stream stop #101 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 18 December 2015 - 21:53

gs = green screen
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Stream stop #102 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 18 December 2015 - 22:09

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.


Re: Stream stop #103 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 19 December 2015 - 10:12

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.


Re: Stream stop #104 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 19 December 2015 - 10:51

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
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Stream stop #105 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 19 December 2015 - 11:05

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 ??



Re: Stream stop #106 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 20 December 2015 - 15:25

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.



Re: Stream stop #107 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 20 December 2015 - 15:29

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

Can you test it?
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Stream stop #108 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 20 December 2015 - 15:40

unfortunately not.

 

Im unable to compile the new servicemp3 file.

 

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

 

Ian.



Re: Stream stop #109 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 21 December 2015 - 20:31

@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



Re: Stream stop #110 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 22 December 2015 - 09:33

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.



Re: Stream stop #111 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 23 December 2015 - 09:43

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.



Re: Stream stop #112 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 26 December 2015 - 13:23

Anyone ?

 

Is the fix going to be applied or not ?



Re: Stream stop #113 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 27 December 2015 - 10:40

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.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Stream stop #114 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 28 December 2015 - 09:28

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.



Re: Stream stop #115 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 6 January 2016 - 09:30

@MX3L

 

Are you going to contribute your patch ?

 

It desperately needs adding.

 

Ian.



Re: Stream stop #116 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 6 January 2016 - 20:47

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.



Re: Stream stop #117 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 6 January 2016 - 21:33

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.



Re: Stream stop #118 mickd

  • Member
  • 5 posts

0
Neutral

Posted 5 September 2016 - 14:41

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.

Re: Stream stop #119 betacentauri

  • PLi® Core member
  • 7,185 posts

+323
Excellent

Posted 5 September 2016 - 16:42

Some servers except special user agents. E.g. when you try to open streams which should be used by TVs (Hbbtv).
Xtrend ET-9200, ET-8000, ET-10000, OpenPliPC on Ubuntu 12.04

Re: Stream stop #120 mickd

  • Member
  • 5 posts

0
Neutral

Posted 5 September 2016 - 17:30

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?


4 user(s) are reading this topic

0 members, 4 guests, 0 anonymous users