MSC = Mass Storage Class = UMS
http://en.wikipedia.org/wiki/USB_mass-storage_device_class
a) MTP didn't work out of the box with ViBE as a mountable filesystem
b) I've always had issues in the past with MTP, so I just set to MSC which
is more of an industry standard and is more mature on linux
c)
Public bug reported:
Binary package hint: udev
Philips GoGear ViBE (usb vendor/model = 471/2075) is set to MSC but
recognized as MTP by udev. ('s brokened)
Fix for me was to comment out line 785 of
/lib/udev/rules.d/40-libgphoto2-2.rules
#ATTRS{idVendor}==0471, ATTRS{idProduct}==2075,
** Attachment added: Troubleshooting info from udevadm
http://launchpadlibrarian.net/5352/typescript
** Attachment added: BootDmesg.txt
http://launchpadlibrarian.net/53527308/BootDmesg.txt
** Attachment added: CurrentDmesg.txt
http://launchpadlibrarian.net/53527309/CurrentDmesg.txt
Umm - obviously I already 'fixed' the problem on my system and the
device mounted ok; P'raps I should have rebrokened it before running
ubuntu-bug so that all the system files that automatically get attached
reflect the problem. Nonethess I think all the info needed is in my
attachment
@Till
As mentioned the gnome printing dialog also hangs if the name of one of the
printer's hosts is unresolvable. In any case it shouldn't hang even if
localhost doesn't come up for some reason - in that case it should present some
sane warning message to help users locate the problem at the
Thanks Till for your prompt response! I'm sorry I don't know appropriate
ettiquette for inline/attachments here - I have inlined a heap of
output: (1) debug output from cups as requested (2) debug output from
cups during the print-dialog hang (3) gdb stacktrace of gedit during a
print-dialog hang.
Same problem here, caused by having a remote (ipp) printer defined, and
the name of the host on which the queue is defined is unresolvable. It
is not the default queue -- in this case one printer defined on a server
at home, the hostname of which is normally discovered by zeroconf. If
that server
Very surprised this bug is not biting a lot of users - eg. when
connecting to a wireless connection via nm_applet, it fails to make a
connection and there is no obvious indication given of what the problem
is. The immediate implication for the niave user (me!) in this case is
that there is a
