Jump to content


Photo

Stream stop


  • Please log in to reply
119 replies to this topic

Re: Stream stop #81 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 18 December 2015 - 18:03


<346807.014500> [eServiceMP3] cutfile not found!
<346807.639339> [eServiceMP3] async-done - 1 video, 1 audio, 0 subtitle
<346807.644315> [eServiceMP3] AUDIO STRUCT=audio/mpeg
<346807.655547> [eServiceMP3] audio stream=0 codec=audio/mpeg language=und
<346809.646661> [eServiceMP3] Buffering 68 percent done
<346810.905799> [eServiceMP3] Buffering 69 percent done
....
<346814.889697> [eServiceMP3] Buffering 84 percent done
<346814.899171> [eServiceMP3] Buffering 85 percent done
[AutoRes] determineContent
<346815.441620> [eServiceMP3] http source timeout! issuing eof...
It seems we have async-done before buffering complete. So on async-done we need to stop timeout.
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 #82 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 18 December 2015 - 18:12

On async done the GST_STATE_PLAYING should do the work. MAybe the following doesn't executed?

                        if(!m_user_paused)
                                gst_element_set_state (m_gst_playbin, GST_STATE_PLAYING);

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 #83 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 18 December 2015 - 18:28

Nice one Athoik

 

So with a bit of luck this massively annoying bug will be fixed in an update in a few days time ?

 

thats great news.

 

Ian.



Re: Stream stop #84 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 18 December 2015 - 18:28

<346806.893818> [eServiceMP3] state transition READY -> PAUSED
...
<346807.639339> [eServiceMP3] async-done - 1 video, 1 audio, 0 subtitle
...
<346815.441620> [eServiceMP3] http source timeout! issuing eof...
...
<346815.442924> [eServiceMP3] stop state:PLAYING pending:VOID_PENDING ret:SUCCESS
resolved to PAUSE
....
<346817.057541> [eServiceMP3] Buffering 100 percent done
<346817.571974> [eServiceMP3] state transition PAUSED -> PLAYING
...
<346817.900948> [eServiceMP3] Buffering 0 percent done
<346817.902677> [eServiceMP3] state transition PLAYING -> PAUSED
<346817.907685> [eServiceMP3] state transition PAUSED -> READY

It looks to be executed, only thing which looks weird is that gst_element_get_state is already stating in stop, that we are in PLAYING, while we get state change message on the bus later.


Edited by mx3L, 18 December 2015 - 18:29.


Re: Stream stop #85 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 18 December 2015 - 18:43

Its probably not required but just in case here's the Livestreamersrv log whereby you can see that the pipe is broken after END shows onscreen.

Fri Dec 18 17:39:00 2015 Server Starts - :88
localhost.localdomain - - [18/Dec/2015 17:39:12] "GET /hls://https://secure.brig
htcove.com/services/mobile/streaming/index/rendition.m3u8?assetId=4436699898001&
expiration=1450719600000&token=60bf1ea563ad2c53865819a091660098b03adfbf&videoId=
4436636326001 HTTP/1.1" 200 -
localhost.localdomain - - [18/Dec/2015 17:39:12] URL: hls://https://secure.brigh
tcove.com/services/mobile/streaming/index/rendition.m3u8?assetId=4436699898001&e
xpiration=1450719600000&token=60bf1ea563ad2c53865819a091660098b03adfbf&videoId=4
436636326001 Quality: best
Streams: ['live', 'worst', 'best']
<HLSStream('https://secure.brightcove.com/services/mobile/streaming/index/rendit
ion.m3u8?assetId=4436699898001&expiration=1450719600000&token=60bf1ea563ad2c5386
5819a091660098b03adfbf&videoId=4436636326001')>
Got Exception:  [Errno 131] Connection reset by peer
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 43492)
Traceback (most recent call last):
  File "/usr/lib/python2.7/SocketServer.py", line 582, in process_request_thread
  File "/usr/lib/python2.7/SocketServer.py", line 323, in finish_request
  File "/usr/lib/python2.7/SocketServer.py", line 640, in __init__
  File "/usr/lib/python2.7/SocketServer.py", line 693, in finish
  File "/usr/lib/python2.7/socket.py", line 303, in flush
error: [Errno 32] Broken pipe
----------------------------------------

So your new code to stop the pipe when END appears is indeed working,its just stopping it too early.

 

Ian.


Edited by ian1095, 18 December 2015 - 18:45.


Re: Stream stop #86 dhwz

  • Senior Member
  • 227 posts

+20
Neutral

Posted 18 December 2015 - 19:23

@mx3L
Yes hbbtv uses its own user agent string but that has nothing to do with the Default which was/is used in servicemp3? I'm not aware of any "normal" Plugin which requires the default "Enigma2 Mediaplayer" :-)

Re: Stream stop #87 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 18 December 2015 - 19:47

@mx3L
Yes hbbtv uses its own user agent string but that has nothing to do with the Default which was/is used in servicemp3? I'm not aware of any "normal" Plugin which requires the default "Enigma2 Mediaplayer" :-)


OpenOpera uses Enigma2 User-Agent.
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 #88 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 18 December 2015 - 19:49

@dhwz

Currently is default User-Agent set to "Enigma2 HbbTV/1.1.1 (+PVR+RTSP+DL;OpenPLi;;", before it was "Enigma2 Mediaplayer".

 

I don't have any problem to have both options of setting custom User-Agent, but we should make sure that custom User-Agent set via config, will be not used after usage for every gstreamer service. That's all.


Edited by mx3L, 18 December 2015 - 19:50.


Re: Stream stop #89 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 18 December 2015 - 19:50

It looks to be executed, only thing which looks weird is that gst_element_get_state is already stating in stop, that we are in PLAYING, while we get state change message on the bus later.


I think we never get to this:

                                case GST_STATE_CHANGE_PAUSED_TO_PLAYING:
                                {
                                        if ( m_sourceinfo.is_streaming && m_streamingsrc_timeout )
                                                m_streamingsrc_timeout->stop();

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 #90 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 18 December 2015 - 19:53

I think we get to this in PAUSED_TO_PLAYING, but it's already stopped when that happens, since m_streamsrc_timeout timer was triggered in "<346815.441620> [eServiceMP3] http source timeout! issuing eof..."



Re: Stream stop #91 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 18 December 2015 - 20:00

I think we get to this in PAUSED_TO_PLAYING, but it's already stopped when that happens, since m_streamsrc_timeout timer was triggered in "<346815.441620> [eServiceMP3] http source timeout! issuing eof..."


Then stop the timeout since we are buffering?

                case GST_MESSAGE_BUFFERING:
                        if (m_sourceinfo.is_streaming)
                        {
+                                if (m_state == stIdle && m_streamingsrc_timeout)
+                                         m_streamingsrc_timeout->stop();
Or better make timeout configurable on user interface with default value 30.
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 #92 ian1095

  • Senior Member
  • 462 posts

+6
Neutral

Posted 18 December 2015 - 20:06

Thats an excellent idea Athoik.

 

Whatever is causing this I feel is a long standing bug and has not been picked up on before because users used to be able to simply press OK and the stream would continue.

 

I know that I myself have been doing this for at least the last 12 months everytime END appeared onscreen and it stopped buffering.

 

But a configurable timeout would be great because that way it takes into account different internet speeds that users have and also to a degree,different box processing speeds too.

 

Ian.


Edited by ian1095, 18 December 2015 - 20:07.


Re: Stream stop #93 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 18 December 2015 - 20:10

Agree for both :),

 

we should test if timer is active:

                case GST_MESSAGE_BUFFERING:
                        if (m_sourceinfo.is_streaming)
                        {
+                                if (m_state == stIdle && m_streamingsrc_timeout.isActive())
+                                         m_streamingsrc_timeout->stop();


Re: Stream stop #94 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 18 December 2015 - 20:24

Here is the streaming timeout configurable propery.
 
diff --git a/lib/python/Components/UsageConfig.py b/lib/python/Components/UsageConfig.py
index 3ddf820..7bdbb9f 100644
--- a/lib/python/Components/UsageConfig.py
+++ b/lib/python/Components/UsageConfig.py
@@ -581,6 +581,7 @@ def InitUsageConfig():
        config.streaming.stream_eit = ConfigYesNo(default = True)
        config.streaming.stream_ait = ConfigYesNo(default = True)
        config.streaming.authentication = ConfigYesNo(default = False)
+       config.streaming.timeout = ConfigSelection(choices = ["15", "30", "60", "120", "240"], default = "30")

 def updateChoices(sel, choices):
        if choices:
diff --git a/lib/service/servicemp3.cpp b/lib/service/servicemp3.cpp
index d0c263f..cb45272 100644
--- a/lib/service/servicemp3.cpp
+++ b/lib/service/servicemp3.cpp
@@ -21,8 +21,6 @@
 #include <gst/pbutils/missing-plugins.h>
 #include <sys/stat.h>

-#define HTTP_TIMEOUT 30
-
 /*
  * UNUSED variable from service reference is now used as buffer flag for gstreamer
  * REFTYPE:FLAGS:STYPE:SID:TSID:ONID:NS:PARENT_SID:PARENT_TSID:UNUSED
@@ -2157,9 +2155,10 @@ void eServiceMP3::gstBusCall(GstMessage *msg)
                                        const gchar *name = gst_plugin_feature_get_name(GST_PLUGIN_FEATURE(factory));
                                        if (!strcmp(name, "souphttpsrc") && (state == GST_STATE_READY) && !m_streamingsrc_timeout->isActive())
                                        {
-                                               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);
+                                               int http_timeout = eConfigManager::getConfigIntValue("config.streaming.timeout", 30);
+                                               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);
                                        }
                                }
                                if ( GST_IS_PAD(source) )
Do you think config.streaming.timeout is a good key selection?

Edited by athoik, 18 December 2015 - 20:25.

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 #95 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 18 December 2015 - 20:36

On async done the GST_STATE_PLAYING should do the work. MAybe the following doesn't executed?
 

                        if(!m_user_paused)
                                gst_element_set_state (m_gst_playbin, GST_STATE_PLAYING);

Now it does execute, that's not the problem. And also the reason off m_user_paused and not the use off m_paused.

 

What can be done eventually (however by me there is no difference att all = :

   RESULT eServiceMP3::start()
    {
    	ASSERT(m_state == stIdle);
     
    	if (m_gst_playbin)
    	{
    		eDebug("[eServiceMP3] starting pipeline");
    		GstStateChangeReturn ret;
    		if(m_sourceinfo.is_streaming)
    			ret = gst_element_set_state (m_gst_playbin, GST_STATE_PLAYING);
    		else
    			ret = gst_element_set_state (m_gst_playbin, GST_STATE_PAUSED);
     
    		switch(ret)
    		{
    		case GST_STATE_CHANGE_FAILURE:
    			eDebug("[eServiceMP3] failed to start pipeline");
    			stop();
    			break;
    		case GST_STATE_CHANGE_SUCCESS:
    			eDebug("[eServiceMP3] pipeline started STATE_CHANGE_SUCCESS");
    			m_is_live = false;
    			break;
    		case GST_STATE_CHANGE_NO_PREROLL:
    			eDebug("[eServiceMP3] pipeline started GST_STATE_CHANGE_NO_PREROLL");
    			m_is_live = true;
    			break;
    		case GST_STATE_CHANGE_ASYNC:
    			eDebug("[eServiceMP3] pipeline started GST_STATE_CHANGE_ASYNC");
    			break;
    		default:
    			break;
    		}
    	}
     
    	return 0;
    }

But the timeout will still exist ,on very few streams (I can't trigger the time out at least not with gst-1).

 

It has to do with http timeout but actually that one is already set to 30 sec by default.  At last the souphttp is set to 30 seconds.


Edited by christophecvr, 18 December 2015 - 20:37.


Re: Stream stop #96 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 18 December 2015 - 20:43

We use it only for gstreamer service and only for http protocol, i.e when souphttpsrc is used.

 

So I think it should represent only http timeout, not timeout in general, also servicemp3/gstreamer could be mentioned in config, since it's related to it or not?

So at least config.streaming.httpTimeout I guess.

 

Another solution is to implement this timeout also for servicedvb service, so we can use it more generally.

 

 

Now I'm thinking, why we need this timeout? Why not keep trying until user decides, that enough time has passed?


Edited by mx3L, 18 December 2015 - 20:45.


Re: Stream stop #97 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 18 December 2015 - 20:52

 

Now I'm thinking, why we need this timeout? Why not keep trying until user decides, that enough time has passed?

Yes that's a good way off thinking. But problem is that stream stop is triggered. Due to http timeout. Then You need to restart the stream also.



Re: Stream stop #98 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 18 December 2015 - 21:09

But I'll make a toppic off it enigma2 tunerconfiguration is broken. with last enigma2

 

At each start now we need to reset the tuner configuration.



Re: Stream stop #99 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 18 December 2015 - 21:28

Do you have gs?
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 #100 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 18 December 2015 - 21:52

Do you have gs?

What do You mean ?


Edited by christophecvr, 18 December 2015 - 21:52.



5 user(s) are reading this topic

0 members, 5 guests, 0 anonymous users