hostname lookup goes wrong

[jp <jpeter@…>]

My master backend is in a different subnet than some of the frontends. So I have a port forwarding do the backend in the router that is in between the backends:

The backend is locally 192.168.1.106. To the troubled frontends it is 192.168.0.105.

I have the setting MasterServerIP 192.168.0.105 in the db for each external frontend. This works so far as that the frontends connect to the backend and get e.g. the recorded list, can watch recordings etc. But they can't watch liveTV or shows being recorded at the time (which is sort of the same thing, technically).

What happens is they try to reach the backend under the wrong IP (192.168.1.106 instead of 192.168.0.105).

Maybe the backend looks up the hostname in some situations instead of leaving it to the frontend? Preview pictures and preview videos don't work for the same reason.

I use ubuntu gutsy ppa (svn-trunk) packages from ​https://launchpad.net/~mythbuntu-trunk/+archive but the problem exists in standard ubuntu svn-fixes packages also.

Here's the shell output:

[...]
2007-12-02 20:38:10.122 MythThemedMenuPrivate: Unknown tag image in background
2007-12-02 20:38:14.529 XMLParse::LoadTheme using /usr/share/mythtv/themes/G.A.N.T/ui.xml
2007-12-02 20:38:14.817 Connecting to backend server: 192.168.0.105:6543 (try 1 of 5)
2007-12-02 20:38:14.838 Using protocol version 36
2007-12-02 20:38:43.089 New DB connection, total: 2
2007-12-02 20:38:43.115 Connected to database 'mythconverg' at host: 192.168.0.105

//finished recording: (works like it should)

2007-12-02 20:38:43.272 TV: Attempting to change from None to WatchingPreRecorded
2007-12-02 20:38:43.384 DPMS Deactivated 
2007-12-02 20:38:47.081 AFD: Opened codec 0x84ec3d0, id(MPEG2VIDEO) type(Video)
[...]
2007-12-02 20:38:49.600 New DB connection, total: 3
2007-12-02 20:38:49.611 TV: Changing from None to WatchingPreRecorded
2007-12-02 20:38:49.612 New DB connection, total: 4
2007-12-02 20:38:49.695 Connected to database 'mythconverg' at host: 192.168.0.105
2007-12-02 20:38:49.824 Connected to database 'mythconverg' at host: 192.168.0.105
[...]
2007-12-02 20:42:37.740 TV: Changing from WatchingPreRecorded to None
2007-12-02 20:42:38.054 DPMS Reactivated.

//ongoing recording (wrong IP contacted)

2007-12-02 20:42:40.100 TV: Attempting to change from None to WatchingRecording
2007-12-02 20:42:40.136 RemoteFile::openSocket(control socket): 
                        Could not connect to server "192.168.1.106" @ port 6543
2007-12-02 20:42:43.142 RemoteFile::openSocket(file data socket): 
                        Could not connect to server "192.168.1.106" @ port 6543
2007-12-02 20:42:43.142 RingBuffer::RingBuffer(): Failed to open remote file (myth://192.168.1.106:6543/1003_20071202201000.mpg)

[Anduin Withers]

What you are attempting to do will not work. Programs have an associated host, that host is contacted directly to stream the data.

[jp <jpeter@…>]

I think I didn't make my point clear enough.

The recordings are saved in the database with their corresponding host (as a hostname, not IP). Watching finished recordings works perfectly, so the frontend is able to resolve the hostname of the corresponding backend and contact the backend (which happens to be the same as the master backend). But when I try to watch live tv, the frontend tries to contact the backend which is recording with the wrong IP. So it works in one situation but not in another. I am positive that this is because the hostname that comes from the db is not handled quite right (maybe as I suspected earlier the backend looks up the hostname instead of passing it to the frontend?!).

[jp <jpeter@…>]

awithers explained by email that DNS is not used in this process at all. So this is not really a bug, just not a feature.. Ticket can be closed. Thank you

[Anduin Withers]

Closed after clarification that the IP comes from the settings table in this case.

[jp <jpeter@…>]

I forgot to mention my solution:

I redirect all tcp-traffic to the backend to the correct IP using iptables on the frontend:

iptables -A OUTPUT -t nat -d 192.168.1.106 -p tcp -j DNAT --to-destination 192.168.0.105

does the job in my case.