172 replies to this topic

[littlesat]

How about display only when 0, 50, 100? -> It can skip those percentage... so that does not help... In addition this a tricky work-a-round... solve the symptom and do not solve the real issue...

 

What if we copy the percentage into an integer and then put it in the debug?

Edited by littlesat, 11 January 2016 - 10:51.

[christophecvr]

I did not wen't that far but only with 0 will cause already an issue.

 

Main problem is well only the eDebug rule self. It's really not needed into logs. It's actually just making the logs unusable. Since it fill ops the console so far that we Can't trace back but are forced to output to a log file if we want to keep anything useful.

[christophecvr]

Just commenting the eDebug is enough, it even does not make sense to have a log off each bufferings msg but just makes the logs unreadable.

[christophecvr]

But creating a static-buffer percentage var and then copy the percentage into it do not now if it will be more light weight.

 

For example declaring into header:

 

gint m_buffer_current_percent;

 

and then use by the function.

		case GST_MESSAGE_BUFFERING:
			if (m_sourceinfo.is_streaming)
			{
				GstBufferingMode mode;
				gst_message_parse_buffering(msg, &(m_bufferInfo.bufferPercent));
				m_buffer_current_percent = m_bufferInfo.bufferPercent;

And replace by rest off module everywhere we use m_bufferInfo.bufferPercent  by m_buffer_current_percent ?

[christophecvr]

Also A new bug gst-1 bug has been introduced since commit :

http://cgit.freedesk...5d829047b2d9f68

 

This up to and including the last commit :

 

http://cgit.freedesk...c9cd003aafe805e

 

I set a comment on:

 

https://bugzilla.gno...g.cgi?id=760234

 

But perhaps file a new bug since I(ts new due to that commit. It does not reopens anyway.

[Akki]

I want my findings also contribute to this problem, perhaps you can identify what it.

I have 3 days ago about Taapat GIT me Image
built for the Duo2 with GST 1.71 and I was amazed that I had no spinner in the known streams.

However, if I send the Duo2 to standby and anschalte again I have no sound output.

https://github.com/T...ine/vuduo2.conf

In the vuduo2.conf section:

MACHINE_FEATURES + = "DVB-C blindscan DVBC blindscan dvbs HbbTV wol ctrlrc transcoding dvbproxy uianimation"

The entry "dvbproxy" caused me at the Duo2 I had no spinner in the streams,
However, as already written, by turning on from standby without sound output.

For testing purposes, I then built the image without the entry "dvbproxy", then I had indeed again a sound output when I turned on the Duo2 from standby, but came the spinners
again at said streams.

I hope the professionals can order what to do and it helps in problem solving.

Greeting Akki

[Taapat]

@Akki it has nothing to do with dvbproxy.
christophecvr found the reason of the problem.
As I wrote here, I'm in enigma disable this message in the log, and so you do not have a problem in this streams.

If you build without dvbproxy, is used standart openpli enigma with this message in log.

Edited by Taapat, 11 January 2016 - 13:46.

[christophecvr]

@Akki as long is not decided what will be done about this bug in e2 just apply the patch when You build to enigma2 I posted on :

 

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

[theparasol]

Main problem is well only the eDebug rule self. It's really not needed into logs. It's actually just making the logs unusable. Since it fill ops the console so far that we Can't trace back but are forced to output to a log file if we want to keep anything useful.

 

Did you guys notice that edebug() uses locking? If the messages come in rather quickly they will pile up.

But perhaps I'm mistaken, I'm just a bad hobby coder

[Akki]

@Taapat And Chris

You guys are the professionals, I just wanted to write my findings which did :-)

I'm going to apply the patch Chris and hope that all the works.

[MastaG]

Looks I have some catching up to do

Thank you Taapat and Chris for all the contribution lately.

[christophecvr]

 

Main problem is well only the eDebug rule self. It's really not needed into logs. It's actually just making the logs unusable. Since it fill ops the console so far that we Can't trace back but are forced to output to a log file if we want to keep anything useful.

 

Did you guys notice that edebug() uses locking? If the messages come in rather quickly they will pile up.

But perhaps I'm mistaken, I'm just a bad hobby coder

 

Well I'm also just a hobby coder . But bad or good that's all relative . I personally find You pretty good as coder .

 

Everyone is learning each day

 

but perhaps should be asked why eDebug uses locking ? Could be required to keep some msg's into sequence I gues, but it's clear that in other situations it will block the whole process.

The sometimes weird and or runtime errors could be caused by the eDebug locking.

Edited by christophecvr, 11 January 2016 - 15:17.

[Akki]

Image ready built, great work from you @ Chris Spinner no zapping of the
Streams..genial ... Thank you

Greeting Akki

Edited by Akki, 11 January 2016 - 18:03.

[buc61b]

Did the new relase fix low simbol rate on spark 7111

Can someone confirm this?

[MastaG]

Chris,

 

Is this patch still required?

From 6702d913ade96f8b462eabb971b75745fbc88e63 Mon Sep 17 00:00:00 2001
From: christophecvr <stefansat@telenet.be>
Date: Thu, 24 Dec 2015 11:47:47 +0100
Subject: [PATCH] Freeze when changing audiotrack if media is paused.

 When user paused the media then tried to select a higher number
 off audio track the stb freezed. Just replaced the already inserted
 launch off gstreamer to play during seekToImpl procedure.
 Now user can pause media select another track up or down.
 No freeze anymore and no loss off audio/video fragments.

    modified:   lib/service/servicemp3.cpp
---
 lib/service/servicemp3.cpp | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/lib/service/servicemp3.cpp b/lib/service/servicemp3.cpp
index 5af48e8..cae3cd2 100644
--- a/lib/service/servicemp3.cpp
+++ b/lib/service/servicemp3.cpp
@@ -895,6 +895,12 @@ RESULT eServiceMP3::getLength(pts_t &pts)
 
 RESULT eServiceMP3::seekToImpl(pts_t to)
 {
+    if (m_paused)
+    {
+        m_seek_paused = true;
+        m_paused = false;
+        gst_element_set_state(m_gst_playbin, GST_STATE_PLAYING);
+    }
         /* convert pts to nanoseconds */
 #if GST_VERSION_MAJOR < 1
     gint64 time_nanoseconds = to * 11111LL;
@@ -912,12 +918,6 @@ RESULT eServiceMP3::seekToImpl(pts_t to)
         return -1;
     }
 
-    if (m_paused)
-    {
-        m_seek_paused = true;
-        gst_element_set_state(m_gst_playbin, GST_STATE_PLAYING);
-    }
-
     return 0;
 }
 
@@ -1755,6 +1755,7 @@ void eServiceMP3::gstBusCall(GstMessage *msg)
                     if (m_seek_paused)
                     {
                         m_seek_paused = false;
+                        m_paused = true;
                         gst_element_set_state(m_gst_playbin, GST_STATE_PAUSED);
                     }
                     else
--
1.9.1

[christophecvr]

If You want to avoid a stb full freeze when changing (not only reselecting) the audio track if media is paused (only possible by filesrc media streamsrc media can't be paused). Yes then You must still apply the patch.

It's not in e2 .

 

But it's not the best solution.

 

mx3L tries to find the why it causes a full freeze only if a higher then the current audiotrack is done during.

 

However the patch is anyway not so good.

 

The only save we could do at this time = removing the

    if (m_paused)
    {
        m_seek_paused = true;
        gst_element_set_state(m_gst_playbin, GST_STATE_PLAYING);
    }

and also by going to state playing the

                     if (m_seek_paused)
                     {
                         m_seek_paused = false;
                         m_paused = true;
                         gst_element_set_state(m_gst_playbin, GST_STATE_PAUSED);
                     }
                     else

Since they do not make sence att all.

 

And perhaps just allow audioreselection off same track during pause fase. Doeing this action cause a nice resync off all. When You then unpause all runs 100 % fin and in sync.

The track change during paused fase should be prohibited.

Edited by christophecvr, 11 January 2016 - 23:45.

[christophecvr]

@MastaG

 

The patch which really should be done is this one that I set on :

 

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

 

That debugging is actually a blocker for some media on all vu+ series and .....

[MastaG]

Thank you Chris,

 

I've both of them checked in atm.

Or will the second one  http://forums.openpl...ndpost&p=523917 fix the problem as well?

[christophecvr]

Also do not go higher in version for gst-plugins-base then :

 

http://cgit.freedesk...a7e2c81706dd2d8

 

Every higher commit does break a lot off media.

 

bug report filed see

 

https://bugzilla.gno...g.cgi?id=760477

[christophecvr]

Thank you Chris,

 

I've both of them checked in atm.

Or will the second one  http://forums.openpl...ndpost&p=523917 fix the problem as well?

No the possible full freeze is not solved whit the eDebug patch (has nothing to do with each other).

Edited by christophecvr, 12 January 2016 - 00:02.