Client can't connect on Motorola KRZR K1

[GoogleCodeExporter]

* OS: Ubuntu 9.10
* Remuco version: 0.9.2
* Client device: Motorola KRZR K1
* Player: Rhythmbox

The Client can be installed and launched without problems, and is able to
discover the bluetooth PC host.
When the connection is selected, the "Connecting to Player" waiting dialog
appears, and fails after a few seconds with the message
"There was an IO error while sending client description (flush error/a:
errno=-1)."
, and offers to reconnect.

Original issue reported on code.google.com by Jonathan...@gmail.com on 11 Feb 2010 at 4:40

[GoogleCodeExporter]

This is not really a bug, it is an "expected" error - that's why you see the 
message and not a crash :). Expected 
means that IO/network communication may fail and in your case unfortunately it 
does. The question is what 
causes the error. It may be anything between the Bluetooth stack of the KRZR 
and the Bluetooth stack of your PC. 

While I'd really like to help, the only hints I can give are to try again in 
another setup, i.e. have a try with another 
phone or with another PC. This may help to narrow down the error source. You 
could also have a try with the 
tool 'hcidump' or another Bluetooth monitor, though it's not fun to read the 
logs of these tools.

Original comment by obensonne@googlemail.com on 11 Feb 2010 at 10:04

• Changed state: Accepted
• Added labels: Bluetooth, Device-Motorola-KRZR-K1, Type-Support
• Removed labels: Type-Bug

[GoogleCodeExporter]

No feedback yet, closing this issue.

Original comment by obensonne@googlemail.com on 14 Mar 2010 at 2:08

• Changed state: Done

[GoogleCodeExporter]

Please reopen. I ran into this problem with my K1. A hcidump is attached (I 
only changed my MAC and my phone name).

OS: gentoo linux
Version: remuco 0.9.5
Client: Motorola KRZR K1
Player: MPD

Original comment by jbuec...@gmail.com on 29 Aug 2011 at 8:42

Attachments:

• hcidump.txt

[GoogleCodeExporter]

Does setting a fixed Bluetooth channel (in ~/.cache/remuco/remuco.cfg and, if 
needed, on the client in the connection setup) solve this problem? See also 
http://code.google.com/p/remuco/wiki/FAQ#Bluetooth_problems. According to some 
user reports, it is worth to try several port numbers (the lower ones are 
sometimes reserved to special services. By default Remuco chooses a "random" 
free channel ("random": mostly it is 1)

Original comment by obensonne@googlemail.com on 29 Aug 2011 at 9:00

• Changed state: Chatting

[GoogleCodeExporter]

I set server and client to fixed channel 7 before this post. Does not work. I 
read the FAQ.

Original comment by jbuec...@gmail.com on 29 Aug 2011 at 9:13

[GoogleCodeExporter]

A mpd.log with DEBUG on and remuco 0.9.5 and channel 8.

Tried to use different channels, just to be safe. Then its a different error 
message (IO Error while setting up the connection (errno=-1) and no reconnect 
option)

Original comment by jbuec...@gmail.com on 29 Aug 2011 at 9:33

Attachments:

• mpd.log

[GoogleCodeExporter]

According to the log, the server successfully receives the client description 
message. However, for some reason the client device does not think so. It looks 
like the error happens here: 
http://code.google.com/p/remuco/source/browse/client/common/src/remuco/client/co
mmon/io/Connection.java#464

So the K1 JavaVM might be a bit buggy here. You could have a try with a client 
without this line. Building a custom client is not that hard: 
http://code.google.com/p/remuco/wiki/MIDP

Original comment by obensonne@googlemail.com on 30 Aug 2011 at 3:28

[GoogleCodeExporter]

Yes that worked. Thanks.

I deleted 
                dos.flush();
from function
                private void sendPrivate(Message m) throws IOException 
and used last hg checkout (rev. 1438:152d10ba9749).

This customized client works.

Original comment by jbuec...@gmail.com on 31 Aug 2011 at 5:46

[GoogleCodeExporter]

This issue was updated by revision 09deaa661d3b.

The release tarball now contains an additional pre-built client variant
named 'motorola-k1-fix'. It does not call the flush method on output
streams - this method seems to be buggy on the named device. Note that
this fix theoretically might delay the sending of messages to the server.

Original comment by obensonne@googlemail.com on 31 Aug 2011 at 7:10

• Changed state: Fixed