GNOME Bugzilla – Bug 547693
Not all DAAP shares discovered
Last modified: 2020-03-17 08:35:21 UTC
Please describe the problem: Not all available daap shares are discovered when banshee starts. Restarting will often find others, but rarely all. There are about 10 shares here at work and banshee typically will only find 4 per invocation. One work around that seems to work is first open Rhythmbox, which always finds all shares, and then open banshee. Banshee will generally find all available shares at this point. Steps to reproduce: 1. Start banshee 2. 3. Actual results: Not all daap shares are discovered or populated under "Shared Music" Expected results: All available daap shares become available Does this happen every time? Yes Other information: Feels like some type of race condition
What type of shares are they?
There are 2 mt-daap (firefly) shares and the rest are people sharing iTunes from their laptops. They all come and go but I don't pay much attention to the iTunes shares. I'm interested in the firefly share I pipe into work over openvpn.
I do have the source checked out and building if you want my to try patches are add logging/debugging bits.
OK, gotcha. I was mostly wondering if they were all iTunes shares or something; those are notoriously spotty because of the way Apple publishes them. The only DAAP-related bug that has a patch is bug 363813. Looks like it *could* be relevant, but it looks like it'd take some work to get it to apply in trunk at this point, let alone whether it's still relevant in the new codebase. 'banshee-1 --debug' should give a good deal of debugging output, and that would definitely be helpful. Please attach what you can find out.
Created attachment 116595 [details] HumeTunes found, but not resolved
Created attachment 116596 [details] HumesTunes is found and resolved AFTER first opening Rhythmbox
--debug shed a little more light on what's happening. Looks like all DAAP shares are being found but not always being resolved. The two attachments show this for the share I'm interested in, HumeTunes.
Thanks for all the testing; that'll be critical in determining the cause of the problem. I'm not sure (I never have the chance to see that many shares simultaneously), but I wonder if it's some sort of timeout.
Additionally, they share I'm interested in HumeTunes, always resolves when I'm at home. My home machine and work machine are both update to date 32bit Hardy Heron machines. There are obviously a lot more machines on the network at work and most people are using Macbook Pro machines. Lots of muticast traffic. Very little muticast traffic here at home.
Hi! I can confirm this bug. I have a machine in my network with rythmbox sharing the songs using daap and when I use banshee in my laptop the daap share sometimes appear and sometimes not.
I'm using banshee 1.4.3 by the way in ubuntu hardy.
This bug had been happening to me more often than not with my one DAAP share so I took a look into it. It turns out this isn't really a Banshee problem it's a Mono.Zeroconf bug, which is what Banshee is using to do the finding and resolving of shares. I've submitted a bug report to them at https://bugzilla.novell.com/show_bug.cgi?id=510791 and will be posting a patch there soon. I haven't received and feedback on the Mono.Zeroconf bug yet, but hopefully they will accept my patch (or something similar) and then Banshee will not have to deal with this problem after the next update of mono.
I'm also bitten by this bug very often. I already exchanged my router because of this. Is there any chance the Mono guys will be fixing this soon?
The problem is still present in Banshee 2.0.0
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.