I looked at rb-daap-mdns-browser-avahi.c a bit. If it's hard to do that, an option to show local shares would be appreciated.

We currently uses Avahi's "is local" flag for determining whether to show the share. If we want to replace this, we'd need some code that accurately determines whether a share is our own or not.

I think we could put the username (or uid?) in the mdns text record for the share and then only ignore local shares with the same username/uid.  The code for adding the password-required flag to the mdns record shows how to do this.  I'm not sure what the default behaviour would be for records with no username/uid field.

I'm not sure putting usernames in mdns records is a good idea, as it will let everyone on your (possibly untrusted) network know a valid username for your machine.

I agree.  Using the uid would be better.  It's not useful information (except when it's 0), and the uid of the user running rhythmbox would be 1000 for just about every typical single-user linux machine out there.

Created attachment 67964 [details] [review]
patch

Adds "User ID" key to our mdns records, and uses them to decide whether to ignore local daap shares or not.  Shares with no "User ID" key are not ignored, but I'm not sure if this is the right thing to do.

Looks sane to me.

This is probably the kind of thing we should bring up on gnome-multimedia, as it's probably more likely the user will running two different things that can be DAAP servers (e.g. RB and Tangerine) than two instances of RB.

Please try to implement your own is_local() function like this:


int is_local(char* cb_sn, char*cb_st, char *cb_dn, char *cf_sn, char *cf_st) {
        char domain1[AVAHI_DOMAIN_NAME_MAX9], domain2[...];

        avahi_service_name_join(domain1, sizeof(domain1), cb_sn, cb_st, cb_dn);
        avahi_service_name_join(domain2, sizeof(domain2), cf_sn, cf_st, avahi_client_get_domain_name(client));

        return avahi_domain_equal(domain1, domain2);
}


cb_sn: service name you got on the browse callback
cb_st: service type you got on the browse callback
cb_dn: domain you got on the browse callback

cf_sn: the configured service name of the local rb service
cf_st: the service type (_daap._tcp)

This enhancement sounds like a great idea to me. I've had to rewrite the rhythmbox code in the past two versions I've downloaded to get it to see my local mt-daapd server.

In my case, I've got about 100GB of music, and it's just too much for Rhythmbox to both play it and serve it to others without a huge delay on startup. Plus, using the mt-daapd server means that the iTunes share is always on, not just when I'm logged in.

Anyway, adding this enhancement would definitely make my life easier.

Ignoring the no-userID shares is probably a bad idea.

When I'm on my laptop, I frequently SSH in to my desktop with the DAAP port forwarded, then use avahi-publish-service to publish the service as coming from my laptop, so that I can use DAAP to play my music locally on my laptop.  In this case, I wouldn't have a UserID field, but want to play the share from Rhythmbox.

I currently work around this by running a locally patched Rhythmbox with the skip-local-share code removed.  I've been thinking about reworking it so that the local skip is controlled by a GConf key.  Would this be a decent solution, and then have an option in the preferences to show/hide local shares?

Alternatively, would it work to have Rhythmbox generate a random cookie value, and skip any share published with the same cookie as the rhythmbox looking at reading the share?

Just to give another use case:

I use firefly/mt-daapd on my home lan so I can access my music from whatever machine I happen to be using so I have my dynamic playlists set up in it. Furthermore, firefly has greater flexibility in creating playlists than Rhythmbox does (supports more meta tags and more complex logic) so I would prefer to use Firefly's daap share even when using Rhythmbox on the same host over a local library.

It is not possible for me to see a local daap share from mt-daapd with RB 0.11.2 so I hope this is changed in a future release.

I've given this a little more thought.

Hiding shares, even local ones, isn't really in the spirit of Zeroconf. If I have local web shares or other services I very much expect my local apps to see them so there's no justifiable reason for Rhythmbox to ignore local music shares. For comparison, iTunes does not hide local daap shares (not provided by itself).

If there is no way for Rhythmbox to detect its own share (a header perhaps) perhaps a solution would be for Rythmbox to simply hide a local share if it has the same name as the one it is providing?

The cleanest solution is to use the same AvahiClient object for both browsing and registering the DAAP service (which would be more resource-friendly anyway). Then you'd just have to check for the flag AVAHI_LOOKUP_RESULT_OUR_OWN everytime you get a NEW notification from the AvahiServiceBrowser object. It will tell you if the service you just discovered has been registered from the same AvahiClient context.

That sounds like the right option, but for that, we'd need to make Avahi more public. Maybe we could remove the old mDNS support, and do that?

*** Bug 551618 has been marked as a duplicate of this bug. ***

A bit of a hack in some places, but it's nothing compared to the rest of the daap code..

2008-11-09  Jonathan Matthew  <jonathan@d14n.org>

        * plugins/daap/Makefile.am:
        * plugins/daap/rb-daap-mdns-avahi.c: (client_cb),
        (rb_daap_mdns_avahi_get_client),
        (rb_daap_mdns_avahi_set_entry_group):
        * plugins/daap/rb-daap-mdns-avahi.h:
        Add some machinery to create a single avahi client to use for both
        browsing and publishing.

        * plugins/daap/rb-daap-mdns-browser-avahi.c: (browse_cb),
        (rb_daap_mdns_browser_init), (rb_daap_mdns_browser_finalize):
        * plugins/daap/rb-daap-mdns-publisher-avahi.c: (create_service),
        (rb_daap_mdns_publisher_withdraw), (rb_daap_mdns_publisher_init),
        (rb_daap_mdns_publisher_finalize):
        Use the shared avahi client.  Since we publish and browse using the
        same client, we can use the AVAHI_LOOKUP_RESULT_OUR_OWN flag (rather
        than AVAHI_LOOKUP_RESULT_LOCAL) to ignore just our own share.
        Previously, we ignored all shares on the same machine.  Fixes #342655.

*** Bug 332088 has been marked as a duplicate of this bug. ***