mythmetadatalookup doesn't terminate causing commflagging to fail

[mitch.capper@…]

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: ​http://pastebin.com/k5EgXBtF

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.

[robertm]

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.

[beirdo]

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.

[robertm]

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

[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.

[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).

[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

[mitch.capper@…]

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

[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.

[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.

[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.

[mitch.capper@…]

Yes no further issues.

[Raymond Wagner]

User reported problem fixed.