Opened 13 years ago

Closed 11 years ago

Last modified 10 years ago

#1968 closed Enhancement (wontfix)

Advertise Web interface through mDNS (avahi)

Reported by: hadess Owned by: charles
Priority: Low Milestone: None Set
Component: Daemon Version: 1.51
Severity: Normal Keywords: patch-needed
Cc: tom@…, hadess@…, chrysn@…

Description

Currently, one has to know the IP address, as well as the port on which the service is running.

Exporting all this through mDNS would make finding the web interface a doodle. Avahi is the library to use on Linux.

Attachments (3)

transmission-publish-web-interface.patch (4.8 KB) - added by hadess 13 years ago.
First pass, compiles, but probably doesn't work, comments welcome
ticket-1968-export-web-interface-through-mdns.patch (5.3 KB) - added by wereHamster 12 years ago.
0001-Advertise-Web-interface-through-mDNS-avahi.patch (6.4 KB) - added by chrysn 10 years ago.
updated patch with ipv4 and path TXT record fixes

Download all attachments as: .zip

Change History (25)

comment:1 Changed 13 years ago by charles

  • Resolution set to wontfix
  • Status changed from new to closed
  • Version changed from 1.50+ to 1.51

The gtk+ client has a button in the preferences dialog to launch the web interface.

This would be nice to have but isn't really essential IMO. If someone coded up a patch for this I'd likely use it, but I'm not going to write it.

Note to future ticket readers: if you *do* want to scratch this itch and write a patch, please attach it to this ticket and reopen the ticket. Thanks!

comment:2 Changed 13 years ago by hadess

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Changed 13 years ago by hadess

First pass, compiles, but probably doesn't work, comments welcome

comment:3 Changed 13 years ago by hadess

Just a note. For "might be nice" enhancements, it would be better to leave the bugs opened, otherwise they won't show up in the lists you get following the links from the website, and you're going to end up with duplicates.

Mark them as "notme" in the keywords, and only close the ones with enhancements you wouldn't wish to see in your code.

comment:4 Changed 13 years ago by charles

Looks good. Can someone confirm that this works?

comment:5 Changed 13 years ago by charles

confirmed.

Clean patch, too.

comment:6 Changed 13 years ago by charles

  • Resolution set to fixed
  • Status changed from reopened to closed

Committed in r8149.

The only change I made was moving configure.ac's avahi test outside of the gtk+ clause. It's possible that a user only building the daemon would also want the web interface to be advertised.

comment:7 Changed 13 years ago by charles

  • Resolution fixed deleted
  • Status changed from closed to reopened

The current implementation consistently crashes in avhai's code if you start Transmission and then exit it again a second later.

comment:8 Changed 13 years ago by charles

I've now spent half an hour reading through the avahi docs and finally just reverting this code... this after saying I didn't want to be the one to spend time on this patch.

reverted in r8152

comment:9 Changed 13 years ago by charles

In addition to fixing the shutdown error, a revised patch will probably also want to handle the case where there's a collision. It's possible for users to accidentally start up a daemon + gtk client, both trying out for the same web address and port.

comment:10 Changed 13 years ago by hadess

Well, yeah... I really didn't expect it to work first time. I was just wondering whether the premise and first patch was acceptable in its style.

I certainly wasn't expecting you to commit this first throw.

comment:11 Changed 13 years ago by charles

It was my mistake for committing it. :)

To answer your question, yes it's acceptable in its style.

comment:12 Changed 13 years ago by charles

  • Resolution set to duplicate
  • Status changed from reopened to closed

I had completely forgotten about this ticket which is also about adding avahi support.

I'm going to mark this ticket closed as a duplicate of #1394. Could you please attach your revised patch to that ticket too?

Also, there's already an incomplete patch attached to that ticket. I don't know if it's something worth keeping and/or merging into your patch, but you might want to look at it and see if it's useful.

comment:13 Changed 12 years ago by charles

  • Keywords patch-needed added
  • Priority changed from Normal to Low
  • Resolution duplicate deleted
  • Status changed from closed to reopened

Thanks to Waldorf for setting me straight. This is not a duplicate of #1394, which is about peer discovery, not about advertising the web interface.

So, I'm reopening this ticket and adding the "patch-needed" keyword.

Here, the "patch-needed" keyword means this feature might be nice, but IMO wouldn't be used by enough people to be worth the time it takes to write, test, debug, and maintain. If someone feels the itch strongly enough to write a clean and simple patch, it would stand a good chance of being added to Transmission.

comment:14 Changed 12 years ago by wereHamster

Updated patch available at request (forward-ported the patch to r10023 and added a small change to enable avahi regardless of which clients are built). It seems to work fine (avahi-browser -a lists the address). I'll see if I can get Firefox or some other web browser to listen to mDNS announces so I can test if the announces are in the proper format and readable by other applications.

comment:15 Changed 12 years ago by wereHamster

  • Cc tom@… added

comment:16 Changed 12 years ago by hadess

  • Cc hadess@… added

Could you please post your patch? You can test the website with both Safari and Epiphany. You could also post the output of "avahi-browse -ar" for us to check.

comment:17 Changed 12 years ago by wereHamster

It works in firefox, and avahi-browse -ar lists the address fine. But there seems to be a problem when shutting down. On my opensolaris box when I press ctrl-c the daemon crashes with:

Assertion failed: *_head == _item, file entrygroup.c, line 247

And on my gentoo linux box with:

arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid (path)" failed in file ...

comment:18 Changed 12 years ago by wereHamster

Alright, seems to be fixed. The old code freed the avahi client before the entry group. I reordered the shutdown sequence and now the daemon doesn't crash anymore.

comment:19 Changed 11 years ago by charles

I've got mixed feelings about this patch. On the one hand it's clean and simple. On the other hand, it adds an extra library dependency for something that not many people will use.

It looks like Avahi has a dbus interface. Is there any way we could use that instead?

comment:20 Changed 11 years ago by charles

  • Resolution set to wontfix
  • Status changed from reopened to closed

Given the low demand users have shown for this feature, I'm against adding another library dependency for it.

If there's a way to do this in straight DBUS that would be better...

Changed 10 years ago by chrysn

updated patch with ipv4 and path TXT record fixes

comment:21 Changed 10 years ago by chrysn

  • Cc chrysn@… added

attached, you'll find an updated patch to svn revision 13283. apart from changed context, some new make/project files needed adaptions.

the dbus option, if it is an option at all (judging from a quick inspection using d-feet, this can't be done, but i might easily be wrong here), is one i'd rather not follow, considering that "daemon only" builds (as they're used on NAS devices or similar) don't depend on dbus currently afaict.

i'd appreciate if this became a feature of transmission -- the /etc/avahi/services/ workaround from ticket #1394 (comment 8) works for me, but has several shortcomings.

comment:22 Changed 10 years ago by chrysn

  • Component changed from GTK+ Client to Daemon

there's now an updated version of the patch. there, avahi is configured to only announce ipv4 services (as the server currently doesn't listen to ipv6), and to not announce the precise /transmission/web path in a TXT record (as / works just as well, and a configuration option would have to be evaluated otherwise).

by the way, the patches also apply to the 2.50 release.

adding an option to turn announcements on and off would be worth considering imo, as not everyone who has zeroconf available wants to use it (especially, distributions will enable zeroconf support). once that's implemented, it will also be reasonably easy to disable zeroconf announcements if permitted clients are configured to "localhost only", as even locally, zeroconf would produce a 169.254.x.x address.

Note: See TracTickets for help on using tickets.