Bug 174586 - Loading video from camera consumes ll memory
Summary: Loading video from camera consumes ll memory
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Import-Gphoto2 (show other bugs)
Version: 0.10.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-08 00:34 UTC by Søren Holm
Modified: 2017-08-16 06:12 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 1.0.0


Attachments
backtrace of digikam 0.10.0 rc2 using 300 Mb memory (5.64 KB, text/plain)
2009-02-16 22:18 UTC, Søren Holm
Details
gp_file_new_from_fd (1.51 KB, patch)
2009-07-12 18:50 UTC, Marcel Wiesweg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Søren Holm 2008-11-08 00:34:23 UTC
Version:           0.10.0-beta1 (using KDE 4.1.2)
OS:                Linux
Installed from:    Ubuntu Packages

When trying to load an avi-video from my canon camera (using USB PTP class camera) digikam consumes all available memory when transfering the video. Digikam never completes. The video is not more than 50 mb large.

I can provide more information if not directly reproducable.
Comment 1 caulier.gilles 2008-11-08 12:23:04 UTC
You use beta1. please try with last beta5 release...

Gilles Caulier
Comment 2 Søren Holm 2008-11-08 17:40:57 UTC
I don't know how to install beta5. Couldn't compie libkipi.

Abyway I notice that digicam 0.9.4 also has that problem. It peaked at 800 megs of used memory. It  was all free when the avi-file was successfully retreived. Since I also hav 1Gig of memory this was pretty annoying and basically locked up my machine.
Comment 3 caulier.gilles 2008-11-08 17:51:33 UTC
If problem appear in KDE3 version too, it must be a problem with libgphoto2 used by digiKam to play with non USB Mass Storage camera.

Which libgphoto2 version you use ?
Which camera type/model ?
Which video format ?

Gilles Caulier
Comment 4 Søren Holm 2008-11-08 17:56:02 UTC
camera:
cannon isux 90is 

libghoto2:
2.4.2-0ubuntu2 (I do not know if there are any ubuntu patches)

video format (reported by 'file'):
RIFF (little-endian) data, AVI, 640 x 480, 30.00 fps, video: Motion JPEG, audio: uncompressed PCM (mono, 44100 Hz)
Comment 5 caulier.gilles 2008-12-03 10:40:46 UTC
Soren, 

Can you test with last digiKam 0.10.0-beta6 if problem still exist ?

Thanks in advance

Gilles Caulier
Comment 6 Søren Holm 2008-12-07 01:29:07 UTC
sure .... having trouble compiling just now, but I will return.
Comment 7 Søren Holm 2008-12-09 23:22:47 UTC
Can't get digikam 0.10 beta6 to work. After compiling it and trying to run it, it is not even able to show my existing images...
Comment 8 caulier.gilles 2008-12-09 23:26:08 UTC
are you updated libkipi, libkexiv2, and libkdcraw from trunk before to compile digiKam ?

Gilles Caulier
Comment 9 caulier.gilles 2008-12-10 21:08:52 UTC
Soren,

well, do it. use kdegraphics/libs from trunk as explained here:

http://www.digikam.org/sharedlibs

Gilles Caulier
Comment 10 Søren Holm 2008-12-27 22:09:29 UTC
digikam-0.10 beta7 still has the problem. Any hint on how to pinpoint where the memory is actually allocated?
Comment 11 Marcel Wiesweg 2008-12-29 23:22:16 UTC
Does it use only memory or CPU as well? Watch it using a system monitor, top or ksysguard.
Any output on the console?
While digikam is running and consuming memory, attach gdb. To do this, find out the PID of the process and then call "gdb att <PID>". Type the command "thr appl all bt" and post the output here.
Comment 12 Marcel Wiesweg 2009-01-18 22:44:46 UTC
Any news on this?
Comment 13 caulier.gilles 2009-01-19 08:43:06 UTC
S0ren,

Please take a look in comment #11 and report more info in this thread. thanks in advance

Gilles Caulier
Comment 14 Søren Holm 2009-02-16 22:18:28 UTC
Created attachment 31378 [details]
backtrace of digikam 0.10.0 rc2 using 300 Mb memory

Backtrace of digikam using 300 Mb of memory during a download of a 1600 Mb AVI-file from my Canon IXUS 90IS
Comment 15 Søren Holm 2009-02-16 22:19:44 UTC
Sorry for the long delay, but my camera has been left along for a while.

Anyway top says the following - and this is only the beginning, because the sky is the limit with this. It just keeps on going until killed by OOM.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5086 sgh       20   0  492m 276m  12m T    0 31.5   0:27.45 digikam
Comment 16 Marcel Wiesweg 2009-02-17 09:58:42 UTC
Thanks for the backtrace. This indeed hints at a problem in gphoto2: the only running digikam thread is deep inside libgphoto2 called to download an item.

Gilles, I guess we should CC the gphoto2 developer?
Comment 17 caulier.gilles 2009-02-17 10:11:19 UTC
Marcel,

Gphoto2 lead developer is Marcus Meissner <marcus at jet dot franken dot de>. He is registered to B.K.O. Just add email as CC is enough...

Gilles
Comment 18 Marcus Meissner 2009-02-17 10:14:46 UTC
libgphoto2 slurps everything into memory first if you are not using filedescriptor based transfer. So for 1.6GB movie, it will try to allocate 1.6GB at least.

You can work around this by diownloadiung just this movie using
gphoto2 commandline tool, which uses a passtghrough method.
Comment 19 Søren Holm 2009-02-17 19:22:23 UTC
hmm... well I guess this is a no no. The most movie-files is normaly several megabytes pr minute, so I think digikam should indeed use filedescriptor based transfer. But this must mean that everyone has this problem, also Gilles.
Comment 20 caulier.gilles 2009-05-13 11:59:42 UTC
Well, no, because i never use PTP driver with my camera : it's too limited (No RAW preview). I always use UMS mode.

So, we need a Canon user here to confirm...

Gilles Caulier
Comment 21 Marcel Wiesweg 2009-07-05 18:15:52 UTC
So, Marcus, as I understand this, to have downloading with gphoto2 scale well with large files, we need to use the "filedescriptor based method".

What is this? Is it advisable to use? Any problems or drawbacks?
Comment 22 Marcus Meissner 2009-07-05 19:04:22 UTC
instead of doing

gp_file_new(&file);
... get file ... 
gp_file_get_data_and_size(file,...)
gp_file_unref (file);
you do:

... open fd writeable ... 
gp_file_new_from_fd(&file, fd);
... get file same as before
gp_file_unref (file);
 (no gp_file_get_data_and_size() )

The "get file" part will already write it to "fd" on the disk.
Comment 23 Marcus Meissner 2009-07-05 19:05:15 UTC
drawbacks ... hmm, not so much. needs libgphoto2 2.4.0 or newer, but this is the case for all distros these days.
Comment 24 Marcel Wiesweg 2009-07-12 17:59:00 UTC
We are currently using gp_file_save but reading the header file this is considered deprecated. I guess new_from_fd is the best choice then.
Comment 25 Marcel Wiesweg 2009-07-12 18:50:42 UTC
Created attachment 35254 [details]
gp_file_new_from_fd

See the attached patch. I switched my camera to PTP mode and managed to load the a few pictures but I get errors for about every second image (see error printout below). I dont know if this is due to my patch or any other problem because I never used the PTP mode of my camera.
Anyone here to test the patch with an established testing environment for gphoto2?
Marcus, do you know what may cause this error in my patch from gp_camera_file_get()?

printGphotoErrorDescription: Libgphoto2 error:  I/O-Problem  ( -7 )
Comment 26 Marcus Meissner 2009-07-12 21:51:38 UTC
from patch:
+    errorCode = gp_file_new_from_fd(&cfile, file.handle());
+
+    if (errorCode != GP_OK)
+    {
+        kDebug(50003) << "Failed to get camera item!" << file.handle();
+        printGphotoErrorDescription(errorCode);
+        gp_file_unref(cfile);

remove the gp_file_unref(cfile) here, cfile is not initialized when errorCode != GP_OK.

Also QFile:handle() ... does it return the fd QFile still continues to own? 

Then try using
+    errorCode = gp_file_new_from_fd(&cfile, dup(file.handle()));
instead since this call hands lifetime control of "fd" over to libgphoto2 (and we would close fd twic otherwise).
Comment 27 Marcel Wiesweg 2009-07-13 17:27:14 UTC
Thanks Marcus, I was indeed messing around with file descriptors!
Now everything works with my camera.
Comment 28 Marcel Wiesweg 2009-07-13 17:29:18 UTC
SVN commit 995957 by mwiesweg:

Use the file descriptor based method to download a file with gphoto2.
This should solve problems with very large files because they can directly be written to disk.

BUG: 174586

 M  +4 -1      NEWS  
 M  +25 -11    utilities/cameragui/gpcamera.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=995957