[DONE] KDE problems with "camera" files

[mla]

I have a fairly elderly Topfield PVR, with a USB connectivity allowing its internal disk to be accessed from outside. I haven't used this facility for quite a while (as a guess a couple of years), but recently needed to copy out a couple of recordings -- around 3GB in size each.

Surprise number one: my KDE desktop classified the PVR disk connected via USB as a camera and thus gave me no option to mount it as a disk. However Dolphin listed the contents via a URI via the camera: protocol and one can ask Dolphin to "Copy to" a given location.

Surprise number two: an attempt to copy a file from the PVR in this matter promptly produced an error notification: "Unable to claim USB device". Howeever, I fiddled about, split the Dolphin window, pointed the new part of the window to the desired location and dragged the file across, replying with "Copy" to the question as to my actual intent. All seemed well.

Surprise number three: after a while the copy aborted with "The process for the camera protocol died unexpectedly.". Trying again produced the same result. On both occasion the copied fragment was about 2GB in size. So I tried Konqueror, which also recognised the PVR as a camera, but was unable to claim the USB device. However, after a reboot, Konqueror saw the files and allowed a copy -- which crunched out in the same manner after copying about 2GB.

A Google search showed that this behaviour was reported on other distros -- e.g. Ubuntu. One discussion thread was marked [Solved] -- it's advice was: use gphoto2. This seemed doubtful, since Digicam accessed the "camera" but refused to acknowledge the files, presumably reckoning them not to be photos? However...

Surprise number four: "gphoto2 --list files", produced a file list and "gphoto2 --get-file 1" happily copied the complete first file on the list.

Conclusion: this aspect of KDE is rather badly bugged. (1) There is the claim USB problem. (2) There seems to be a limit of 2GB that can be extracted from a camera: URI -- anything bigger than that fails non-gracefully.

And a question... How do I tell the system that my PVR is *not* a camera? Having dug about a bit, I note that systemd appears to be somehow involved, and I have bad experiences with systems's imperial ambitions beyond simply replacing SVR4 init.

[mla]

Well, I now have to do some more file shifting to and from my PVR (Personal Video Recorder). Any suggestions as to how I persuade Mageia 5 to mount it as an external USB disk rather than as a camera?

[doktor5000]

You would probably have to configure that on the PVR, as the device has to expose access via usb mass storage protocol.
Or you can try to adjust or add a udisks rule for that.

Can you show the output of

Code: Select all

solid-hardware query 'IS StorageDrive'
mtp-detect

with the PVR connected?

Also please do the following after unplugging your PVR - Open a terminal, and as root run:

Code: Select all

journalctl -af

then wait a few seconds, and connect the PVR, and wait again fifteen seconds or so, until no new output appears.
Then post everything here.

FWIW, found some related bug report and a mail thread
https://bugs.launchpad.net/ubuntu/+sour ... bug/155788
which suggests to move away /usr/lib/udev/rules.d/40-libgphoto2.rules and rename/edit /usr/share/kde4/services/camera.protocol
http://linux.derkeiler.com/Mailing-List ... 00007.html

[mla]

Can't do anything about the PVR. It exposes its disk via USB, but the details of that are not available to me to fiddle with. It used to be mounted as a disk by default. And yes, both bug reports you mention sound exactly like what I am seeing -- including the occasional double occurrence of kio_kamera (I *think* that's what is causing the "unable to claim USB" problem).

I'll go and fire up the laptop and the PVR to get the information you request. Just one query... Presumably you'll want "journalctls -af" *after* reconnecting the PVR too? Or rather, the diff between the before and after?

[mla]

Sorry, I should have guessed that 'f' was for "follow".

Anyway, here are the results... The relevant journal entries are the ones stamped 12:44

Code: Select all

LG580: journalctl -af
-- Logs begin at Fri 2015-07-17 11:48:11 BST. --
Aug 06 12:40:38 LG580 org.a11y.Bus[6488]: Activating service name='org.a11y.atspi.Registry'
Aug 06 12:40:38 LG580 org.a11y.Bus[6488]: Successfully activated service 'org.a11y.atspi.Registry'
Aug 06 12:40:38 LG580 org.a11y.atspi.Registry[7519]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
Aug 06 12:40:38 LG580 org.a11y.atspi.Registry[7519]: Xlib:  extension "XEVIE" missing on display ":0".
Aug 06 12:40:45 LG580 mgaapplet[7487]: running: ionice -p 7487 -n7
Aug 06 12:40:55 LG580 systemd-timesyncd[636]: interval/delta/delay/jitter/drift 128s/+0.001s/0.048s/0.001s/+3ppm
Aug 06 12:41:33 LG580 su[8621]: pam_tcb(su-l:auth): Authentication passed for root from mla(uid=1000)
Aug 06 12:41:33 LG580 su[8621]: (to root) mla on pts/1
Aug 06 12:41:33 LG580 su[8621]: pam_tcb(su-l:session): Session opened for root by mla(uid=1000)
Aug 06 12:43:03 LG580 systemd-timesyncd[636]: interval/delta/delay/jitter/drift 256s/+0.001s/0.047s/0.001s/+6ppm
Aug 06 12:44:26 LG580 kernel: usb 3-2: new high-speed USB device number 2 using xhci_hcd
Aug 06 12:44:26 LG580 kernel: usb 3-2: New USB device found, idVendor=11db, idProduct=1000
Aug 06 12:44:26 LG580 kernel: usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug 06 12:44:26 LG580 kernel: usb 3-2: Product: Topfield (http://www.topfield.co.kr)
Aug 06 12:44:26 LG580 kernel: usb 3-2: Manufacturer: Topfield Co., Ltd.
Aug 06 12:44:26 LG580 kernel: usb 3-2: SerialNumber: 1000
Aug 06 12:44:26 LG580 mtp-probe[12691]: checking bus 3, device 2: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-2"
Aug 06 12:44:26 LG580 mtp-probe[12691]: bus: 3, device: 2 was not an MTP device

Code: Select all

LG580: solid-hardware query 'IS StorageDrive'
udi = '/org/freedesktop/UDisks2/drives/ST750LM022_HN_M750MBB_S2USJ9FC517562'   
udi = '/org/freedesktop/UDisks2/drives/Multiple_Card__Reader_058F63666435'     
udi = '/org/freedesktop/UDisks2/drives/MATSHITA_DVD_RAM_UJ8C1_SHC2316000'
LG580: mtp-detect
libmtp version: 1.1.8

Listing raw device(s)
   No raw devices found.

[doktor5000]

Hmmm, appears as USB device, but no partitions read and no device nodes appear.
Can you please add the output from

Code: Select all

solid-hardware list
solid-hardware list details

when it's plugged?

FWIW, what's that LG580 device that shows up?

[mla]

That's just the hostname, which I stick into my command line prompt. LG580 as in "Lenovo G580". It reminds me which machine I am on if I happen to open console windows to other machines on my network.

I'll go and fire up that laptop again.

[mla]

Here's the PVR entry as shown by "solid-hardware list details" (the first line is the one shown by the command without "details".

Code: Select all

udi = '/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2'
  parent = '/org/kde/solid/udev'  (string)
  vendor = 'Topfield Co., Ltd.'  (string)
  product = 'Topfield (http://www.topfield.co.kr)'  (string)
  description = 'Camera'  (string)
  Block.major = 189  (0xbd)  (int)
  Block.minor = 2  (0x2)  (int)
  Block.device = '/dev/bus/usb/001/003'  (string)
  Camera.supportedProtocols = {'proprietary'}  (string list)
  Camera.supportedDrivers = {'gphoto'}  (string list)

Or did yuo really want to see the *whole* list?

[doktor5000]

Nope, the properties for the PVR are sufficient

Seems it speaks a proprietary protocol and is only supported via the gphoto backend, according to solid.
So probably if you move away /usr/lib/udev/rules.d/40-libgphoto2.rules chances are that this thing is not accessible as camera at all, but may be worth trying just to see what happens.

Apart from that, sorry, can't help much further. There are probably also no alternate means to access that thing?
Like 3rd party firmware which allows to run software like sshd or something providing a network share or such. What about enigma2 which is even covered in topfield forums ?
There seems to be at least the possibility to use FTP to transfer files directly from/to the PVR ...

edit doktor5000:
You might have a better change asking there: http://www.toppy.org.uk/

There's also puppy http://www.nslu2-linux.org/wiki/Puppy/HomePage
which seems to be able to comunicate with Topfield PVRs.

[mla]

Alas, moving that rules.d file out of the way simply means that the device is ignored (though lsusb is aware of it).

My apologies, I should have said that I only asked here after exhausting possibilities apparently on offer at toppy.org.uk. The site is largely moribund and tools it offers for file transfers are old and broken (both for Linux and for Windows, I tried both), because USB handling has changed since then. Ditto for puppy. This is hardly surprising -- the Linux tools, at least, became obsolete once Linux started mounting the PVR as a USB drive. As it mounted cameras too, of course. At that stage it was not at all clear that Topfield devices were deemed to be cameras -- nor did it matter.

The stupid thing is, the system *knows* how to communicate with the PVR, provided it is done through a camera URI, but that interface is at best inconvenient and at worst bugged, as described in the initial entry of this thread. So, I suppose, the real problem is that one no longer gets even the option of simply mounting devices reckoned to be cameras simply as external storage. The two complaints you found on the net are exactly about that, but for real cameras, not fake ones.

I suppose a real solution would be some udev rule change which would once again enable cameras to be treated optionally as drives.

[doktor5000]

Well, you may have to ask upstream about that, on either udisks or gphoto developer mailing lists.

I suppose the issue is not only the camera protocol, but also that the PVR uses some proprietary filesystem called FAT24 - which could explain the issue with files bigger then 2GB.

[mla]

It's a bit hard to decide where to take it. Gphoto has no problem with files in excess of 2GB, so at least that aspect is not their problem. KDE people can legitimately say that KDE simply does not support the weirdo FAT24 protocol. The problem of 2GB limit arises only in the hybrid Gnome/KDE environment. Would the udisks crowd be interested? I see their website a longish list of outputs they want to see. I'll try those commands and ponder, before prodding.

Maybe I should install Gnome alongside KDE and see what happens in a Gnome session...

[mla]

Gnome session did not help. But I finally worked around my problem by using VirtualBox to run Windows XP -- the old transfer tools offered by toppy.org.uk work fine for that.

[doktor5000]

Please mark the thread accordingly by editing the topic of the first post and prefix it by [DONE], thanks

[mla]

If you insist... But it grates having to do it by running WinXp as a guest OS, when gphoto2 understands FAT24.

[doktor5000]

Well, I have no further suggestions that what I already provided, sorry. And you see to have found at least a workaround.
I can fully comprehend that this is not a nice situation, but at least there is a feasible way for you.