Thank you mx3L, I was going through all the gdb docs but couldn't find a good example.
So anyways, I think I've found out one of your experimental patches will cause the freeze way more often when stopping a movie.
However it does speed up iptv zapping on all of my other receivers.
diff --git a/lib/service/servicemp3.cpp b/lib/service/servicemp3.cpp
index 7559042..fd59b62 100644
--- a/lib/service/servicemp3.cpp
+++ b/lib/service/servicemp3.cpp
@@ -782,14 +782,6 @@ RESULT eServiceMP3::stop()
m_state = stStopped;
GstStateChangeReturn ret;
- GstState state, pending;
- /* make sure that last state change was successfull */
- ret = gst_element_get_state(m_gst_playbin, &state, &pending, 5 * GST_SECOND);
- eDebug("[eServiceMP3] stop state:%s pending:%s ret:%s",
- gst_element_state_get_name(state),
- gst_element_state_get_name(pending),
- gst_element_state_change_return_get_name(ret));
-
ret = gst_element_set_state(m_gst_playbin, GST_STATE_NULL);
if (ret != GST_STATE_CHANGE_SUCCESS)
eDebug("[eServiceMP3] stop GST_STATE_NULL failure");
I was so caught up in comparing the servicemp3 source code from OpenPLi, OpenATV and Taapat's enigma2 tree that I totally forgot about the patches I was applying myself.
If I don't use the above patch, I can stop my movie and it will go back to the main menu most of the time.
Still I got it to freeze once (I had to play and stop my movie many times though).
action -> DPS_Player exitFunction
authHeaderPartOne {}
[eServiceMP3] stop /run/movies/A.Bronx.Tale.1993.720p.x264.AC3-Riding High/A.Bronx.Tale.1993.720p.x264.AC3-Riding High.mkv
[eServiceMP3] stop state:PLAYING pending:VOID_PENDING ret:SUCCESS
[gRC] main thread is non-idle! display spinner!
But unfortunately I can't debug it once the spinner comes up since gdb will not go back to the prompt when I press CTRL+C.
I believe this is because enigma2 is using 150% CPU at this time and gdb is unable to halt it.
However when I press CTRL+C a second time it will go back to the prompt but I cannot do a backtrace (for the above reason):
(gdb) c
Continuing.
^C
^CQuit
(gdb) thread apply all bt
Cannot execute this command while the target is running.
Use the "interrupt" command to stop the target
and then try again.
Now I guess the spark receiver (which is a bit of a slow one) just needs some more time to stop and flush.
I think what happens is that there is a timing problem between the dvbmediasink and enigma2's servicemp3.cpp.
Here's the code in the gstdvbvideosink.c
case GST_EVENT_FLUSH_STOP:
#ifdef VIDEO_FLUSH
/* required for spark drivers */
ioctl(self->fd, VIDEO_FLUSH, 1/*NONBLOCK*/); //Notify the player that no addionional data will be injected
#endif
if (self->fd >= 0) ioctl(self->fd, VIDEO_CLEAR_BUFFER);
GST_OBJECT_LOCK(self);
self->must_send_header = TRUE;
while (self->queue)
{
queue_pop(&self->queue);
}
self->flushing = FALSE;
GST_OBJECT_UNLOCK(self);
/* flush while media is playing requires a delay before rendering */
if (self->using_dts_downmix)
{
self->ok_to_write = 0;
self->playing = FALSE;
}
self->flushed = TRUE;
break;
I guess setting VIDEO_FLUSH to 1 in the spark driver needs a little bit more time.
I'll try and modify servicemp3.cpp to include a little 100 ms sleep and see where it gets me :-)