Closed fastcat closed 11 years ago
Is the avahi-daemon running on your backend and frontends?
You can also load a stand alone zeroconf browser on your laptop/desktop to see what is broadcasting on your network. There is one available in the ubuntu repos, but not sure of the status of other distros.
On Sun, Jan 13, 2013 at 4:20 AM, Matthew Gabeler-Lee < notifications@github.com> wrote:
I looked at the code and the network, and I don't see why, but neither backend nor frontend discovery via mDNS queries is working for me.
I used wireshark to verify that the mDNS queries are going to my backend machine, and that it is responding to them.
I used this android tool http://cafbit.com/entry/testing_multicast_support_on_android to make sure that my tablet and phone can receive the multicast packets, and they can.
But no matter what I do, I can't use the mDNS discovery to find the backend (ok, type it in manually), and once the backend is connected, I can't use the mDNS to find the frontend, which means no mythmote :(
— Reply to this email directly or view it on GitHubhttps://github.com/MythTV-Clients/MythTV-Android-Frontend/issues/105.
My Google Profile http://www.google.com/profiles/dmfrey
yes, the avahi daemon is running on the system (backend and frontend are the same machine). mdns-scan on the laptop can see both of them, and that android app I linked can too from the android devices.
@Churten, great detail in your report, thanks.
I was able to duplicate this once. But I was testing too many things at the time and didn't notice this failure until much later in the day. The 'solution' was re- starting my frontend.
Could you/have you already tried the following command on one of your hosts? I added the output from one of mine for comparison (ofc0 is a frontend.) And, I'm not suggesting that IPv6 is required.
avahi-browse -a ... + eth0 IPv6 Mythfrontend on ofc0 _mythfrontend._tcp local + eth0 IPv4 Mythfrontend on ofc0 _mythfrontend._tcp local + eth0 IPv6 Mythbackend on mc0 _mythbackend-master._tcp local + eth0 IPv4 Mythbackend on mc0 _mythbackend-master._tcp local ...
Note that in the failure mode, the two frontend entries were missing from the above.
I'd be interested in knowing what distribution and version of Linux you're running and if in /etc/defaults you have an avahi related file with: AVAHI_DAEMON_DETECT_LOCAL=1 in it (this is what I have with ubuntu.)
From my laptop:
$ avahi-browse -a
...
+ wlan0 IPv4 Mythbackend on cheetah.lo _mythbackend-master._tcp local
+ wlan0 IPv4 Mythfrontend on cheetah.lo _mythfrontend._tcp local
(server and laptop have link local ipv6 enabled, but I think the myth apps are only listening on localhost for ipv6)
/etc/defaults/avahi-daemon has AVAHI_DAEMON_DETECT_LOCAL=1
I'm running debian testing (wheezy)
Also, I tested what I assume is the "original" mythmote (http://code.google.com/p/mythmote), and while it does not support mDNS discovery, I was able to enter in the connection information into it and control the frontend.
@Churten in your last response, is cheetah.lo the real hostname, or is that just the avahi-browse tool truncating cheetah.local? As to your comment about MythTV apps only listening on IPv6, I know if I do: sudo netstat -pant | grep myth, on my backend, it's listening on both.
@pot8oe, @dmfrey, I'm labeling this as a bug. Do either of you know of a method for diagnosing this? @Churten seems to have proven that his backend/frontends are setup as required and his tablet & phone can see the multi-cast packets.
cheetah.lo is a "real" local hostname, in that I have a DNS server running resolving my LAN addresses forwards and backwards for the fake ".lo" domain. LAN clients connecting via DHCP see that dns server (really a dnscache instance that knows about both that local dns server and the public internet).
I was a bit unclear on the ipv6 part ... what I meant was that, for ipv6, I thought they were only listening on ::1 ... I was wrong, though, they are also listening on the link-local (fe80::...) address. For ipv4, they listen on localhost and the LAN interface address.
I have been having intermittent issues with auto discovery. It does not appear to have anything to do with the android app. Mine has not been working for the last week. This morning I updated and rebooted my backend and frontends. Also I restarted my router. I'm not sure why exactly but as I write this auto discovery started working. It's driving me sh*t house because it is getting in the way of testing the app and I cannot find the root cause. I'm sure it will stop working again soon. If I ever figure out my problem here I'll keep you posted.
-Tom
@Churten, I was able to duplicate this by starting my backend with the --noupnp option. avahi-browse still reported the "_mythbackend-master._tcp local" string, but discovery from the Android didn't work. If your backend is running, check with:
ps ax|grep mythbackend|grep -v grep
Thanks.
My backend is running with these args: /usr/bin/mythbackend --daemon --syslog local6 --pidfile /var/run/mythtv/mythbackend.pid
I'm using the myth packages from http://www.deb-multimedia.org/ FWIW.
I checked the database tables to see if there was anything related to UPnP being disabled. I have some old log entries about disabling upnp at runtime when the backend was only listening on localhost, but that stopped when I told it to listen on the LAN interface to enable this app to work.
The only other UPnP stuff in the database dump are:
INSERT INTO `settings` VALUES ('UPnP/UDN/MediaServer','64977659-eddb-42ae-9d30-b3cca954f719','cheetah.lo');
INSERT INTO `settings` VALUES ('UPnP/UDN/MasterMediaServer','55de87c2-c071-4efd-997f-ab3f13097e2a','cheetah.lo');
INSERT INTO `settings` VALUES ('UPnP/WMPSource','0',NULL);
INSERT INTO `settings` VALUES ('UPnP/RebuildDelay','30','cheetah.lo');
I'm not really sure exactly what those mean, or if they might have anything to do with the problem.
@Churten, the above matches my settings (other than the uuids.) With upnp logging on, you should see lines like:
LookupUDN(urn:schemas-upnp-org:device:MediaServer:1) sName=UPnP/UDN/MediaServer...
with you uuids in them. But, I suspect that since you've seen the backend on your devices already, that's not the problem.
I did try the tool you mentioned in you initial post, as well as Bonjour Browser and ZeroConf Browser from the Play Store.
The response from the query on my system is:
192.168.1.204:5353 ->:5353
Mythbackend on mc0._mythbackend-master._tcp.local
TXT
OTHER data [12]
_mythbackend-master._tcp.local
PTR Mythbackend on mc0._mythbackend-master._tcp.local
mc0.local
AAAA/<my Unique Local Address>
A/192.168.1.204
That should match yours except for the mc0 and IPs.
I think of changing my mc0.local to mc0.lo to match yours, but, as you probably know the hostname is a 'profile' name in the MythTV database, so I don't want to mess mine up. Could you do the following for me 1st (your password is in ~/.mythtv/config.xml just in case you don't know.)
mysql -umythtv -p mythconverg -e \
"SELECT DISTINCT hostname FROM settings"
I'd expect about two lines of data, so please paste here, thanks. (Full disclosure, I'm grasping at straws, so this may be it for me.)
$ mysql -u mythtv -p mythconverg
Enter password:
...
mysql> select distinct hostname from settings;
+------------+
| hostname |
+------------+
| cheetah.lo |
| NULL |
+------------+
2 rows in set (0.01 sec)
Hmm ...
$ avahi-browse -a -r
...
+ wlan0 IPv4 Mythbackend on cheetah.lo _mythbackend-master._tcp local
...
= wlan0 IPv4 Mythbackend on cheetah.lo _mythbackend-master._tcp local
hostname = [cheetah.local]
address = [10.0.0.1]
port = [6544]
txt = []
Is this mismatch between hostnames perhaps part of the problem?
Thanks for getting the SQL and yes, it appears to be related to the suffix. I changed my /etc/hosts to simulate your DNS setup:
Old: 192.168.1.223 mc1.local mc1
New: 192.168.1.223 mc1.lo
Here's what avahi-browse -r _mythbackend-master._tcp looked like:
http://paste.ubuntu.com/1577413/ (mc0 = OK, mc1.lo = fails)
Of course that meant my MythTV profile (a.k.a. hostname) changed too so I had to go through the setup process. But the app did fail to discover the 'New' backend. I also tested with mc1.blah and mc1.local, they also fail.
If I changed ~mythtv/.mythtv/config.xml (and my ~bill copy) from:
<LocalHostName>my-unique-identifier-goes-here</LocalHostName>
to my Old hostname/profile name:
<LocalHostName>mc1</LocalHostName>
That allowed the hostname to remain mc1.lo, but used just mc1 as the MythTV profile and it works. I'm on 0.27-pre2 so I didn't have to change mysql.txt.
N.B.:
If you were to add a nickname of cheetah for cheetah.lo, I suspect you'd be running. BUT, then all your settings would have to be redone (I had to change the IP in General, re add my capture card, add it's input and build a Default storage group.)
There's a hostname changer script in the mythtv distribution that I've used before successfully, so I'll give that a shot and drop the id to just the short hostname and give that a try.
I looked at the code and the network, and I don't see why, but neither backend nor frontend discovery via mDNS queries is working for me.
I used wireshark to verify that the mDNS queries are going to my backend machine, and that it is responding to them.
I used this android tool http://cafbit.com/entry/testing_multicast_support_on_android to make sure that my tablet and phone can receive the multicast packets, and they can.
But no matter what I do, I can't use the mDNS discovery to find the backend (ok, type it in manually), and once the backend is connected, I can't use the mDNS to find the frontend, which means no mythmote :(
I checked https://github.com/MythTV-Clients/MythTV-Android-Frontend/wiki/MythTV-Configuration-Suggestions to make sure that the backend is setup correctly, and it is, as evidenced by the test tool being able to find the back/front end via the same mDNS queries this app sends.
Tablet is Transformer Infinity (TF700T) running android 4.1, phone is Droid 4 running android 4.0