Opened 10 years ago

Closed 9 years ago

#9993 closed Bug Report - General (Fixed)

mythmetadatalookup doesn't terminate causing commflagging to fail

Reported by: mitch.capper@… Owned by: cpinkham
Priority: minor Milestone: 0.25
Component: MythTV - Mythmetadatalookup Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no


Running head (as of 8/16/11 v0.25pre-3096-ga42bfc6-dirty) qt 4.7 and x64.

it does not happen on every recording but does on several.

mythmetadatalookup when run by the backend just hangs there and never terminates, attaching by strace shows: futex(0xe4051c, FUTEX_WAIT_PRIVATE, 1, NULL

If run by hand on the command line it does end but says errors of:

2011-08-17 10:50:42.406352 I Unable to match this title, too many possible matches. You may wish to manually set the season, episode, and inetref in the 'Watch Recordings' screen. Error: Not all threads were shut down properly: Thread SSDP is still running Thread TaskQueue? is still running

full log:

Mythbackend log when it runs just shows: 2011-08-17 10:30:09.367384 I [8845/2779] Metadata_10189 jobqueue.cpp:2121 (DoMetadataLookupThread?) - JobQueue?: Metadata Lookup Starting for "Are You Smarter Than a 5th Grader?":"Jenn Barlow" recorded from channel 17 at 2011-08-17T10:30:00

But nothing after that.

Change History (12)

comment:1 Changed 10 years ago by robertm

Status: newinfoneeded_new

It appears that MML is *trying* to terminate, but some cleanup isn't happening-- there have been numerous changes to this stuff recently. Daniel or Gavin, can you comment?

Mitch, we need a backtrace connected to the MML process when/if it is hung.

comment:2 Changed 10 years ago by beirdo

Component: MythTV - MythcommflagMythTV - Mythmetadatalookup

Enough has changed recently in the cleanup code that Daniel's been fixing up that I'm not 100% sure where to look, but with a backtrace, I'm sure either of us could hunt that down for you. A futex is the low-level system call used to implement things like mutexes and some of the wait condition variables we use. It might be deadlocked waiting for something.

comment:3 Changed 10 years ago by robertm

Info: Doug Haber in #mythtv-users reporting the same issue with mythfilldatabase.

comment:4 Changed 10 years ago by danielk

Robert, it appears that MythContextPrivate::FindDatabase?() can start up a couple UPnP threads (SSDP and TaskQueue?), but we only manage teardown of those threads at the application level (i.e. in mythfrontend there is some code for this in cleanup().

As a work-around having a valid mysql.txt or config.xml should avoid the problem.

I'll move the UPnP shutdown code down to the proper level.

That explains why the MThread code is complaining; I'm not sure why it's not exiting at all though. It should only wait a few second for those threads to exit and soldier on hoping for the best.

comment:5 Changed 10 years ago by mitch.capper@…

For what its worth I start mythbackend with --noupnp what exactly is meant by a valid mysql.txt or config.xml (as I believe both of mine have valid information).

comment:6 Changed 10 years ago by Github

Refs #9993. Move SSDP and TaskQueue? thread shutdown to mythcontext.

These threads can be started by MythContext even when UPnP is otherwise disabled if we don't find a config.xml or mysql.txt so we always need to ensure that they are shutdown whenever MythContext is used.

Branch: master Changeset: 4a6dcb9195450a380bb6a4e4861bbffa49e60c11

comment:7 Changed 10 years ago by mitch.capper@…

I have ~/.mythtv/config.xml and mysql.txt is there anything else to do to ensure they can find them?

comment:8 Changed 10 years ago by robertm

Mitch, let's not try to work around the issue, instead let's solve it. Right now what we need from you is:

a) update to latest master and see if things improve b) if they don't improve, attach gdb to the mythmetadatalookup process and get a backtrace, which you can post to this ticket.

comment:9 Changed 10 years ago by mitch.capper@…

Sure, sorry I just figured if there is something wrong with my mythtv config might as well get that fixed also. 7 shows recorded all 7 metalookup and commflag worked fine on.

comment:10 Changed 9 years ago by beirdo

To the original poster: Is this still an issue, or have the code changes fixed the problem? It would be nice to close the ticket if it's actually fixed.

comment:11 Changed 9 years ago by mitch.capper@…

Yes no further issues.

comment:12 Changed 9 years ago by Raymond Wagner

Milestone: unknown0.25
Resolution: Fixed
Status: infoneeded_newclosed

User reported problem fixed.

Note: See TracTickets for help on using tickets.