Bug 497135 - Custom-made, non-player device can't be accessed via MTP in Dolphin after libmtp 1.1.22 update, although MTP command-line tools do work
Summary: Custom-made, non-player device can't be accessed via MTP in Dolphin after lib...
Status: REPORTED
Alias: None
Product: kio-extras
Classification: Frameworks and Libraries
Component: MTP (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-12-06 17:42 UTC by fuga
Modified: 2024-12-18 17:28 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description fuga 2024-12-06 17:42:20 UTC
SUMMARY


STEPS TO REPRODUCE
1. Plug a non player device into USB.
2. The notification drawer pops up. It shows "Open in files manager"
3. Click on "Open in files manager"

OBSERVED RESULT

Dolphin opens. The device is not shown in the storage list and cannot be browsed.

EXPECTED RESULT

Dolphin opens. The device is shown in the storage list. It can be browsed, files copied, and so on.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 6.11.8
KDE Plasma Version: 6.2.4
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.0

ADDITIONAL INFORMATION
The behaviour was correct until the latest update of libmtp9-1.1.22 or libmtp-dev-1.1.22, on November 14th. Rolling back to 1.1.21-5 fixes it.
The USB device is a custome device, it is not player device but exposes the filesystem using mtp (umtpresponder precisely). it works fine on Windows 11 (with proper drivers) and on linux before libmtp 1.1.22.
Comment 1 John Kizer 2024-12-16 22:00:09 UTC
Hi - are you able to check if any of the libmtp example CLI tools are able to access that device? (Thinking of a way to see if it's a libmtp upstream issue, or something in how KIO talks to it)
Comment 2 fuga 2024-12-18 15:08:05 UTC
Hi, thanks for your comment.
I did a small test, since I could not remove the working libmtp, I entered init3 to avoid interferences from other daemons, rebuilt libmtp all static and linked mtp-filetree statically. I used ./configure --enable-static --disable-shared CFLAGS="-static" and then built the examples with CFLAGS="-static". that seems to have worked:

```
$ldd mtp-filetree
	linux-vdso.so.1 (0x00007fb6db565000)
	libusb-1.0.so.0 => /lib64/libusb-1.0.so.0 (0x00007fb6db51c000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fb6db200000)
	libudev.so.1 => /lib64/libudev.so.1 (0x00007fb6db4d7000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fb6db567000)
	libcap.so.2 => /lib64/libcap.so.2 (0x00007fb6db4c9000)
```

And then

```
$ mtp-filetree
Attempting to connect device(s)
Android device detected, assigning default bug flags
Device: Bridgemate 3 Scoring Device Storage
Storage: Data
2 ColdStorage.db
Storage: LogFiles
8 hald.log
7 crash
6 update.log
5 system.log
Storage: Updates
OK.
```

I'm not sure the test is 100% valid here, it would have been better to use the system mtp-1.1.22 but I cannot break it, I need the mtp working.
Let me know if I can do any other test.
Comment 3 fuga 2024-12-18 15:14:51 UTC
Additional note I forgot to mention.
Of course the VID and PID are not recognized. The message doesn't appear in the output, but it was printed in the console.
Comment 4 John Kizer 2024-12-18 17:28:30 UTC
Thanks, this one's outside my expertise but updating the title to reflect what you found