Opened 12 years ago

Closed 12 years ago

#4398 closed defect (fixed)

Changeset 15257 breaks myth backend startup in some cases

Reported by: patrickhdonnelly@… Owned by: greg
Priority: major Milestone: unknown
Component: upnp Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Some background:

After applying 15257, my main backend-only server apparently stopped working, in that it would never open a listening sicket on 6543. Further debugging revealed that it was in fact running in a sort of half-started state, stuck spewing *tons* of entries into the upnpmedia table.

Disabling upnp temporarily fixed the issue.

Tracking down when the table was created, I found in the same commit a function that populates upnpmedia recursively from the directory set at 'VideoStartupDir?' in the settings table; for whatever reason (this has always been a backend-only box so maybe it just never got set?), this was missing for this host; as a result it apparently started from "/" and began indexing there, not ideal but not the end of the world as mythtv is a very limited user. Problem is, somewhere along the line I had a symlink pointing from a child directory to a parent, resulting in an infinite loop, a hung mythbackend, and a shit-load of binlog files on my mysql server.

After manually setting 'VideoStartupDir?' to something sane, everything's back to usual; however

a) UPnpCDSVideo::buildFileList needs some sanity checking; it should error out or just exit cleanly if VideoStartupDir? doesn't exist in the settings db b) buildFileList absolutely needs to make sure it isn't indexing the same directory more than once

A patch for a is obviously fairly trivial, I'll try and submit something to handle b in a couple days, perhaps there's something in QT already to iterate over a directory tree?

Change History (6)

comment:1 Changed 12 years ago by dblain

Owner: changed from dblain to greg
Status: newassigned

comment:2 in reply to:  description ; Changed 12 years ago by greg

Tracking down when the table was created, I found in the same commit a function that populates upnpmedia recursively from the directory set at 'VideoStartupDir?' in the settings table; for whatever reason (this has always been a backend-only box so maybe it just never got set?), this was missing for this host; as a result it

If you run MythVideo? on any box, be it frontend/backend the value will be populated. It's also a Global value so it's expected to be the same on all systems. I thought I had added code to check to make sure we got a response back before doing the scan though. Gonna change that in a sec.

had a symlink pointing from a child directory to a parent, resulting in an infinite >loop, a hung mythbackend, and a shit-load of binlog files on my mysql server.

a) UPnpCDSVideo::buildFileList needs some sanity checking; it should error out or just exit cleanly if VideoStartupDir? doesn't exist in the settings db

That's done now.

b) buildFileList absolutely needs to make sure it isn't indexing the same directory more than once

There is nothing in any of the other recursive directory scanning code that checks for a user causing a symlink look(unless it's all be changed since last I looked at it). So if something is gonna be changed it should be done in MythVideo?, MythGame? and MythMusic as well.

comment:3 in reply to:  2 Changed 12 years ago by patrickhdonnelly@…

b) buildFileList absolutely needs to make sure it isn't indexing the same directory more than once

There is nothing in any of the other recursive directory scanning code that checks for a user causing a symlink look(unless it's all be changed since last I looked at it). So if something is gonna be changed it should be done in MythVideo?, MythGame? and MythMusic as well.

I guess that makes sense; I certainly don't have any directory loops within my shared media directories; I may take a stab at creating a generic recursive directory scanner anyway just to try and make things a little more robust.

comment:4 Changed 12 years ago by greg

Resolution: fixed
Status: assignedclosed

comment:5 Changed 12 years ago by keller

Resolution: fixed
Status: closednew

With latest SVN [15283], I still get a lot of this:

2008-01-02 00:02:28.761 Connecting to master server: 10.2.0.13:6543 2008-01-02 00:02:28.779 Connection to master server timed out. 2008-01-02 00:02:29.785 Connecting to master server: 10.2.0.13:6543 2008-01-02 00:02:29.818 Connection to master server timed out. 2008-01-02 00:02:30.837 Connecting to master server: 10.2.0.13:6543 2008-01-02 00:02:30.866 Connection to master server timed out. 2008-01-02 00:02:31.885 Connecting to master server: 10.2.0.13:6543 2008-01-02 00:02:31.939 Connection to master server timed out.

However, disabling UPnP fixes the issue. I think it may be related to the initial ticket. Thanks for the UPnP tip, by the way.

Please let me know what information I might be able to provide to help squash this one.

-Keller

comment:6 in reply to:  5 Changed 12 years ago by greg

Resolution: fixed
Status: newclosed

However, disabling UPnP fixes the issue. I think it may be related to the initial ticket. Thanks for the UPnP tip, by the way.

Please let me know what information I might be able to provide to help squash this one.

This looks like a seperate issue. Please open as a new ticket and include logs from both the master and the machine reporting the error with the output of a -v upnp as well.

Thanks

Note: See TracTickets for help on using tickets.