Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#9263 closed Bug Report (Invalid)

Cut list editor stuck in endless wait loop

Reported by: chemobejk@… Owned by: Janne Grunau
Priority: trivial Milestone:
Component: MythTV - Video Playback Version: 0.24
Severity: low Keywords: cut list editor stuck
Cc: Ticket locked: no


I'm not sure if this is related to ticket #9122. But that ticket is closed and I still have issues with the cut list editor which gets stuck and blocks the whole frontend. I've now tracked it down with gdb to this location in the code:

#0  MythPlayer::WaitForSeek (this=0xabe8bc8, frame=3794, override_seeks=false, 
    seeks_wanted=false) at mythplayer.cpp:3451
#1  0x0416ddfc in MythPlayer::DoFastForward (this=0xabe8bc8, frames=3794, 
    override_seeks=true, seeks_wanted=true) at mythplayer.cpp:3404
#2  0x0416f54c in MythPlayer::HandleArbSeek (this=0xabe8bc8, right=true)
    at mythplayer.cpp:3719
#3  0x0417f4e8 in MythPlayer::HandleProgramEditorActions (this=0xabe8bc8, 
    actions=..., frame=1) at mythplayer.cpp:3595
#4  0x0414a60e in TV::ProcessKeypress (this=0xab4ba50, actx=0xae132f0, 
    e=0xbc75c98) at tv_play.cpp:3651

i.e. the frontend is stuck in this endless loop, because decoderSeek never is set to -1:

    decoderSeek = frame;
    while (decoderSeek >= 0)

As far as I can see decoderSeek is only updated in MythPlayer::DecoderLoop?():

        if (decoderSeek >= 0)
            decoderSeek = -1;

The code looks correct to me, i.e. when WaitForSeek?() sets decoderSeek >= 0 the next run of the DecoderLoop?() should set it to -1. I probably don't have the necessary overview to understand the different threads. Maybe the DecoderThread? is disabled and therefore the code in the loop isn't executed under certain conditions?

In the debugger I programmed a breakpoint inside the loop that waits until count has reached 500 and then forces decoderSeek to -1 to break the loop. With this in place the display isn't correctly updated when the error occurs, but now the cut list editor/frontend recovers from it so that I can at least continue to use it.

The recordings I'm trying to edit are MPEG2 recordings taken from a DVB-C card.

If you need more information, please provide pointers how I can collect it for you.

Change History (2)

comment:1 Changed 9 years ago by robertm

Priority: majortrivial
Resolution: Invalid
Severity: highlow
Status: newclosed

Presumably a dupe of #9234, but since you don't give us the version information we request in the Ticket Howto (and since you've also set severity and priority against our express requests), there's no way to tell. So I'm just going to close this and when and if you've verified that you're beyond that version, you can reopen this ticket with the proper information.

comment:2 Changed 9 years ago by chemobejk@…

I'm using the RPMfusion package which is currently based on plain 0.24.

I've now rebuild the RPM with the following change sets:

and successfully edited 3 recordings without any hangs. So presumably the problem is fixed.

Thanks for pointing out the other tickets.

Note: See TracTickets for help on using tickets.