From: Miguel F. <mi...@ce...> - 2002-12-26 19:04:38
|
Hi Michael, (thanks for reducing my todo list! ;) On Thu, 2002-12-26 at 16:24, Michael Roitzsch wrote: > I experienced the same problem yesterday. This is what I found: > > The XINE_EVENT_UI_PLAYBACK_FINISHED is sent from > xine_handle_stream_end() which can be called from audio or video > decoder loop. In video decoder loop, the call is guarded by > if (stream->stream_info[XINE_STREAM_INFO_HAS_VIDEO]) > while in audio decoder look this is a > if (!stream->stream_info[XINE_STREAM_INFO_HAS_VIDEO]). This is not how it used to be. i not sure why it was changed but previously there were audio_finished and video_finished flags. so the last updated flag (either audio or video) would be responsible for calling xine_handle_stream_end. > Looks good at first sight, but this can happen: > * stream finishes > * video decoder loop notices first and sends the event > * UI receives the event and calls xine_close > * xine_close resets the metainfo by zeroing it > * UI begins to start next MRL in playlist > * audio decoder loop notices the stream finish and sends another > event, because stream_info[XINE_STREAM_INFO_HAS_VIDEO] is 0 Good catch! > Shouldn't it be possible to remove this xine_handle_stream_end() call > from audio decoder loop? or we can just revert to the previous 0.9.x behaviour. that should be a trivial thing to do because the last decoder thread to finish will be the one were (++my_counter == other_counter). should i do it or do you want to take care of this bug? regards, Miguel |