Connection Troubleshooting Guidelines

###The "Cut It In Half" Introduction The phone/tablet is all setup and yet messages or (lack of) results keep suggesting that the MythTV backend can't be reached. Or, the connection is OK but recordings can't be watched.

As with any device that connects to another over a network, sometimes deciding where the problem is can become a guessing game. The purpose of this Wiki is, at the very least, to cut the problem in half and identify if the Android device is sending messages to the MythTV backend or if the backend isn't getting or responding to the messages.

###Connection Tests Here are some tests, in increasing complexity, that can help diagnose a problem:

1. From a browser on the Android device go to http://<Backend IP>:6544/ Expect to see the MythTV Status page. If it doesn't display, consider the following:

   • The backend might not be running or
   • may be running on a version below 0.25
   • Incorrect IP address in the tablet/phone
   • Firewall blocking, not likely if remote front ends work
   • IPTables or UFW (backend resident firewalls)

2. Look at the MythTV backend log files. First, see the Where are the log files? section if their location is unknown. The log generated by mythbackend is the log of interest here, at least for starters.

   Now that the log location is known, users can type: tailf <log file> Then, from the Android device, retry whatever was failing and see what the logs are saying. Type: control-C to abort the tailf.

   Here are some samples of the output. There will be other entries, but for each action, these are the key ones:

   Starting the application and pressing, Home will generate a line like this:

2013-02-14 15:43:47.565359 I [8992/9963] HttpServer74 servicehost.cpp:293 (ProcessRequest) - ServiceHost::ProcessRequest: GetHostName : GET /Myth/GetHostName HTTP/1.1

From the `Home` screen, pressing `Recording Rules` will generate lines like this:

2012-11-21 10:58:40.958152 I [3384/4916] HttpServer77 httprequest.cpp:1339 (ExtractMethodFromURL) - ExtractMethodFromURL(end) : GetRecordingArtwork : /Content
2012-11-21 10:58:40.958178 I [3384/4916] HttpServer77 servicehost.cpp:281 (ProcessRequest) - ServiceHost::ProcessRequest: GetRecordingArtwork : GET /Content/GetRecordingArtwork?Inetref=&Type=Banner HTTP/1.1

Pressing `Recordings` will generate a line like this:

2013-02-14 15:28:26.456275 I [8992/9333] HttpServer74 servicehost.cpp:293 (ProcessRequest) - ServiceHost::ProcessRequest: GetRecordedList : GET /Dvr/GetRecordedList HTTP/1.1

Pressing `Recording Rules` will generate a line like this:

2012-11-01 16:42:17.487302 I [2758/5013] HttpServer97 httprequest.cpp:1339 (ExtractMethodFromURL) - ExtractMethodFromURL(end) : GetRecordScheduleList : /Dvr

###Note that the following suggestions are really debugging level tools. They shouldn't be required by a user of this application. They're just here to document their availability and get users started if that level of analysis is needed.

1. Logcat

   Please see: Logcat Extreme for instructions on how to upload logs.

2. tcpdump

   If nothing is seen in the backend logs, then the messages from the Android device aren't getting to the backend's Services API. To see if messages are even getting to the backend's host, type the following: sudo tcpdump -c 500 -A 'host <tablet/phone IP or hostname>' Expect to see some cryptic protocol fly by, but there should also be some text that can be recognized, such as:

Server: Linux 3.2.0-32-generic, UPnP/1.0, MythTV 0.27.20120906-1
{"ProgramList": {"StartIndex": "0", "Count": "145", "TotalAvailable": "145", ...
GetImageFile?StorageGroup=Fanart&FileName=\/CSI: NY Season 9_fanart.jpg", ...

If nothing prints, not even `SYN` and `ACK` packets, then either `tcpdump`

is setup incorrectly (1st choice), or the Android device's messages aren't getting to the backend's host. This is pretty serious, because the steps at the top of this page should have cared for basic configuration issues. Please review them.

More likely tcpdump is being used to watch the raw protocol exchange. For each connection, expect to see the traditional three way handshake SYN, SYN-ACK, ACK followed by some messages between the Android and backend host and then FIN, FIN-ACK.

1. Wireshark

   This is a graphical interface with excellent displays and protocol analysis features, however, if a user hasn't had any experience with it, it may present too much of a learning curve to be of value.

   The messages captured will, of course, be the same as with the previous step, but in a much easier to read format. Setting a filter to: ip.host == <tablet/phone hostname/ip address> will remove any other traffic on the users network. The output can be saved in a file. Typing: pastebinit <filename> will return a URL that can be pasted in Issues for others to look at.

2. tshark

   This is very useful because is can be run on a remote host without using a GUI. The results can then be copied to a local host and processed by Wireshark.

   A command line version of the above. An example is:

    tshark -i eth0 -ta -N nmt -T text -f "host tab0" -x