[Touch-packages] [Bug 1438510] Re: [REGRESSION] bluetooth headset no longer supports a2dp
Same problem here. The workaround partially fixes it, but still I have sometimes problems to connect. Is it dependent on the bluetooth adapter, headset or both? Are there know-to-work adapters? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1438510 Title: [REGRESSION] bluetooth headset no longer supports a2dp Status in bluez package in Ubuntu: Confirmed Status in pulseaudio package in Ubuntu: Confirmed Status in bluez source package in Vivid: Confirmed Status in pulseaudio source package in Vivid: Confirmed Bug description: Just installed 15.04 fresh from the latest ISO (beta2). I'm bummed to see my bluetooth headset (Bose Soundlink overear) seems to have regressed in functionality. In 14.10, I was able to set the output profile either to a2dp or hsp/hfp (telephony duplex). In 15.04, it only works in telephony duplex mode. I can't get high fidelity sound playback to work at all. This thread seems to be related, though the workaround within did not solve the problem for me: https://bbs.archlinux.org/viewtopic.php?id=194006 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1438510/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 94940] Re: mdns listed in nsswitch.conf causes excessive time for dns lookups
>From https://en.m.wikipedia.org/wiki/.local#Multicast_DNS_standard "Implementers MAY choose to look up such names concurrently via other mechanisms (e.g., Unicast DNS) and coalesce the results in some fashion. Implementers choosing to do this should be aware of the potential for user confusion when a given name can produce different results depending on external network conditions (such as, but not limited to, which name lookup mechanism responds faster)." So wouldn't that solve the issue? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/94940 Title: mdns listed in nsswitch.conf causes excessive time for dns lookups Status in avahi package in Ubuntu: Confirmed Status in nss-mdns package in Ubuntu: Confirmed Status in nss-mdns package in Debian: Fix Released Bug description: Binary package hint: avahi-daemon I encountered this problem on a machine that is integrated into our work network. I performed a dist-upgrade to Feisty on my desktop and all went well. I've noticed recently that any dns based work seemed to take a significantly longer time then normal. My system is getting dns information on our company internal systems from two dns servers. Previously, if I tried to establish an ssh connection with another system I could generally expect the connection in under 3 secs. After the dist-upgrade the time went from under 3 seconds to approximately 25 seconds. After searching around the system I found an entry in /etc/nsswitch.conf that cause me a little concern. The line in question is: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 I looked around a bit and it seems that the references to mdns are really talking about communication with the Avahi mDNS/DNS-SD daemon. Since this looks to be a part of a zeroconf configuration I wasn't expecting too much in my current environment, as we really only have three Mac's. What concerned me is the idea that if we hit files with no answer there is a delay while we hit the other options until we hit dns, which is where the information I seek existed. For an experiment I tried two separate tests. The first changed the line to looks like: hosts: files dns mdns4_minimal [NOTFOUND=return] mdns The change should have improved the time, but I was still looking at approximately 23 seconds to return a command prompt on the destination machine. Finally, I change the entry to simply: hosts: files dns After this change I was again receiving the destination command prompt in under 3 seconds. I don't know if simply changing the file will correct the problem long-term or not. Seems to help me, but might be the way to go for most Ubuntu users. ProblemType: Bug Architecture: i386 Date: Thu Mar 22 18:10:54 2007 DistroRelease: Ubuntu 7.04 Uname: Linux samdesk 2.6.20-12-generic #2 SMP Wed Mar 21 20:55:46 UTC 2007 i686 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/94940/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 94940] Re: mdns listed in nsswitch.conf causes excessive time for dns lookups
This thing is a real problem and there must be a solution for that. every new Ubuntu computer I set up in our wrongly configured Windows network has connection problems. There is this msdn article which recommended setting up the network so lots of people are doing that. Can't there be some connection check after the installation which makes the user aware of the problem and tell him to fix his Network or go to compatibility mode where printers might not work ? this is something I would expect from user-friendly distribution with Ubuntu definitely is. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/94940 Title: mdns listed in nsswitch.conf causes excessive time for dns lookups Status in avahi package in Ubuntu: Confirmed Status in nss-mdns package in Ubuntu: Confirmed Status in nss-mdns package in Debian: Fix Released Bug description: Binary package hint: avahi-daemon I encountered this problem on a machine that is integrated into our work network. I performed a dist-upgrade to Feisty on my desktop and all went well. I've noticed recently that any dns based work seemed to take a significantly longer time then normal. My system is getting dns information on our company internal systems from two dns servers. Previously, if I tried to establish an ssh connection with another system I could generally expect the connection in under 3 secs. After the dist-upgrade the time went from under 3 seconds to approximately 25 seconds. After searching around the system I found an entry in /etc/nsswitch.conf that cause me a little concern. The line in question is: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 I looked around a bit and it seems that the references to mdns are really talking about communication with the Avahi mDNS/DNS-SD daemon. Since this looks to be a part of a zeroconf configuration I wasn't expecting too much in my current environment, as we really only have three Mac's. What concerned me is the idea that if we hit files with no answer there is a delay while we hit the other options until we hit dns, which is where the information I seek existed. For an experiment I tried two separate tests. The first changed the line to looks like: hosts: files dns mdns4_minimal [NOTFOUND=return] mdns The change should have improved the time, but I was still looking at approximately 23 seconds to return a command prompt on the destination machine. Finally, I change the entry to simply: hosts: files dns After this change I was again receiving the destination command prompt in under 3 seconds. I don't know if simply changing the file will correct the problem long-term or not. Seems to help me, but might be the way to go for most Ubuntu users. ProblemType: Bug Architecture: i386 Date: Thu Mar 22 18:10:54 2007 DistroRelease: Ubuntu 7.04 Uname: Linux samdesk 2.6.20-12-generic #2 SMP Wed Mar 21 20:55:46 UTC 2007 i686 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/94940/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
