[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#368049: About your bug: "kamera: can not open/copy big AVI files" on the Debian BTS



Ana Guerrero wrote:
Hi,

We (the Debian Qt/KDE team) are trying to update the bug status of some
old bugs in the BTS.

You filed the bug
 #368049 "kamera: can not open/copy big AVI files"
some time ago, you can read the bug report at:
http://bugs.debian.org/368049

We are sorry if nobody responded when you filed the bug, KDE has gotten more bugs
in the past years than the maintainers could handle. We are trying to fix this now,
but we need your help. So please respond to this mail and tell us if:

- you are still experiencing this bug (adding in what version)
- the bug was already fixed, - or if you have extra information on how reproduce this bug.

--- Thanks in advance,
  Ana Guerrero,
  on behalf of the Debian Qt/KDE team


Sorry for the delay, your email was put in my 'junk' folder...
Please find below the answers to your questions.
Thank you for taking the bug into account : you make a good job.
Regards,
   Laurent

Yes, the bug is still present with kernel 2.6
 Here are my software versions numbers of the day :
      Kernel : Linux 2.6.17-2-686
      kamera : 3.5.5-3
      kdelibs4c2a : 4:3.5.5a.dfsg.1-6
      libc6 : 2.3.6.ds1-13
      libgcc1 : 4.1.1-21
      libgphoto2-2 : 2.2.1-16
      libgphoto2-port0 : 2.2.1-16
      libstdc++6 : 4.1.1-21
(note also that I use udev instead of hotplug).

Extra information : not really. Actually I do not use kamera anymore
(I prefer digikam which does a much better/complete job for me).

From my experiments though, I have checked that the file size above
which destination file is empty is between 15.7 Mb and 17.4 Mb
(1 Mb = 2^20 bytes)
A file of size 15.7Mb is correctly opened/copied.
A file of size 17.4Mb creates an empty file.
I determined this by repeatedly copying/pasting the same video file,
cutting the end of the video in between each transfer -- the cut decreases
the source file size.

I have also noticed that the destination file seems to appears directly with a size of 0 byte, but not until the end of the transfer. For a source video of say,
120Mb, the transfer needs ~ 10 seconds (the progress bar however remains
sticked to 0%). When transfer/copy is finished, the dest. file appears with a
size of 0b.
I checked this by running a simple script like :
while [ 1 ]  ; do ls -l MVI_2382.AVI ; done
This script is launched before the 'paste' operation. I got as output :
ls: MVI_2382.AVI: Aucun fichier ou répertoire de ce type
ls: MVI_2382.AVI: Aucun fichier ou répertoire de ce type
...
ls: MVI_2382.AVI: Aucun fichier ou répertoire de ce type
ls: MVI_2382.AVI: Aucun fichier ou répertoire de ce type
-r--r--r-- 1 lol users 0 2007-02-02 18:56 MVI_2382.AVI
-r--r--r-- 1 lol users 0 2007-02-02 18:56 MVI_2382.AVI
...
-r--r--r-- 1 lol users 0 2007-02-02 18:56 MVI_2382.AVI
-r--r--r-- 1 lol users 0 2007-02-02 18:56 MVI_2382.AVI
I don't know where do the bytes go during the transfer, so that I could
try to monitor something... Are they kept in memory ? in /tmp ? in /var ?

By the way, konqueror (or kamera, or libgphoto2, I don't know) has problems
when one unplug / replug the camera : the 'refresh view' operation either does nothing, or tells that the directory does not exist. The camera led which indicates USB operation does not even blink a single time. I have to quit and launch a new konqueror to
make it scan again the usb camera, and even this does not work always...
But this is another story, and in practice it is very unlikely that we would unplug / replug
the camera for transferring files.





Reply to: