0.9.04a stalls after a while

Bug #1607867 reported by JeanLucCoulon
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Rapid Photo Downloader
Status tracked in Pyqt
Pyqt
Fix Released
High
Damon Lynch

Bug Description

Hi,

This applies to the 0.9 alpha version.
I run Debian GNU/Linux sid.

Desktop is gnome 3.20

The transfer begin then the remaining time stay identical and it stops working.
Sometimes it even doesnt start transfer.

This occurs from a CF card which has already transfered pictures.

After a while, gnome says the program is not responding and asks for force exit or wait.

Version of python is 3.5.2

Regards

Jean-Luc

Related branches

Revision history for this message
Damon Lynch (dlynch3) wrote :

Hi, thanks for your bug report. Without the log files from ~/.cache/rapid-photo-downloader/log , I cannot diagnose the problem. Please attach them to this bug report. Thanks.

Revision history for this message
JeanLucCoulon (jean-luc-coulon-f) wrote :

Hi,
Sorry for the late answer. I was on the travel from holidays.

So, I've done a new backup and here is the workflow and the requested files (I didnt know how to debug when I help reported the bug).

- I first launched rpl from the menu so I've no console data. It stays with 0%, nothing reported on the GUI and after a while, got unresponsive (clic on the menu/pause button has no effect).
gnome asked for "force exit" or wait. I canceled it.
- After this run, I had no transfer in the destination directories (and nothing on the backup drive). But I've a bunch of files in [destination]/rpd-tmp-<something>.

- So I retried from a terminal -> attached the rpdl-1.txt file. I got the same behaviour. I can see it was complaining about libmediainfo so I installed the package.

- I retried again with libmediainfo installed -> attached rpdl-2.txt. I've some errors but I cannot interpret them. This time, it increased the % counter on the right-bottom to 7%. But no file transfered and it stalled as before. I canceled it again, replying yes to 'force exit'.

Please fine attached rpdl-1.txt, rpdl-2.txt and rapid-photo-downloader.log (it probably contains data from previous sessions).

Note& : when I launched rpd, it asks if I want it remember the card reader I use, I reply "Yes", but it asks again each time (even if the session was closed cleanly).

Note2 : With 0.4.11, I can transfer the photo. But the backup is never done while it says it will be done to the drive I've plugged in)

Best regards

Jean-Luc

Revision history for this message
JeanLucCoulon (jean-luc-coulon-f) wrote :
Revision history for this message
JeanLucCoulon (jean-luc-coulon-f) wrote :
Revision history for this message
Damon Lynch (dlynch3) wrote :

It looks like the installation of mediainfo is broken on your system. You can confirm that by using pymediainfo from a python 3.5 session. See this for more information: https://pymediainfo.readthedocs.io/en/latest/

To diagnose the card reader not being remembered, please attach the file:

~/.config/Rapid Photo Downloader/Rapid Photo Downloader.conf

In any case, unless you have a specific reason to be downloading from devices with a DCIM folder, I recommend setting the key device_without_dcim_autodetection to the value false e.g.

[Device]
device_autodetection=true
device_without_dcim_autodetection=false

Revision history for this message
JeanLucCoulon (jean-luc-coulon-f) wrote :

Hi,

1 - for the libmediainfo problem.
I dont understand what I can do with the pieces of code I've found on the "doc" link for libmediainfo.
If I enter the proposed code (and correct the syntax problem), I've "some" result...

2 - about the card reader.
I've a compact flash and I need to access DCIM subdir.

Here is the structure of my card (Canon EOS 7D)

tree /media/jean-luc/EOS_DIGITAL
/media/jean-luc/EOS_DIGITAL
├── DCIM
│   ├── 100EOS7D
│   │   ├── JLC_3026.CR2
│   │   ├── JLC_3027.CR2
│   │   ├── JLC_3028.CR2
│   │   ├── JLC_3029.CR2
│   │   ├── JLC_3030.CR2
│   │   ├── JLC_3031.CR2
│   │   ├── JLC_3032.CR2

Attached the config file.
I've used --import-old-version-preferences to get the preferences from 0.4.11 as the gui is missing for the preferences in 0.9.0a4.

J-L

Revision history for this message
Damon Lynch (dlynch3) wrote :

In the config file, change this line:

device_without_dcim_autodetection=true

to this:

device_without_dcim_autodetection=false

Given the number of times EOS_DIGITAL is mentioned in the config file, it looks very likely there is a bug in the code that deals with that. You can delete all those EOS_DIGITAL instances if you like.

Regarding libmediainfo, I suspect you haven't installed that package yet. Did you use my install script or not? I use Ubuntu 16.04, not Debian, but on my system the required package is libmediainfo0v5. You must install that. pymediainfo is just a wrapper around it.

I might need to add some code that throws an error dialog when pymediainfo does not work because libmediainfo is not installed. I'll look into it.

Revision history for this message
JeanLucCoulon (jean-luc-coulon-f) wrote : Re: [Bug 1607867] Re: 0.9.04a stalls after a while

EOS_DIGITAL, I've removed it (them) and changed the dcim behaviour. I've no
question anymore.

I've installed rpd according to your instructions.
I had no libmediainfo installed on this computer and never the install
process complained about it.

I've installed mediainfo, I've:
libmediainfo-dev 0.7.85-1
libmediainfo0v5:amd64 0.7.85
python3-mediainfodll 0.7.85-1

This latest package is the wrapper

J-L

2016-08-01 17:58 GMT+02:00 Damon Lynch <email address hidden>:

> In the config file, change this line:
>
> device_without_dcim_autodetection=true
>
> to this:
>
> device_without_dcim_autodetection=false
>
> Given the number of times EOS_DIGITAL is mentioned in the config file,
> it looks very likely there is a bug in the code that deals with that.
> You can delete all those EOS_DIGITAL instances if you like.
>
> Regarding libmediainfo, I suspect you haven't installed that package
> yet. Did you use my install script or not? I use Ubuntu 16.04, not
> Debian, but on my system the required package is libmediainfo0v5. You
> must install that. pymediainfo is just a wrapper around it.
>
> I might need to add some code that throws an error dialog when
> pymediainfo does not work because libmediainfo is not installed. I'll
> look into it.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1607867
>
> Title:
> 0.9.04a stalls after a while
>
> Status in Rapid Photo Downloader:
> New
>
> Bug description:
> Hi,
>
> This applies to the 0.9 alpha version.
> I run Debian GNU/Linux sid.
>
> Desktop is gnome 3.20
>
> The transfer begin then the remaining time stay identical and it stops
> working.
> Sometimes it even doesnt start transfer.
>
> This occurs from a CF card which has already transfered pictures.
>
> After a while, gnome says the program is not responding and asks for
> force exit or wait.
>
> Version of python is 3.5.2
>
> Regards
>
> Jean-Luc
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/rapid/+bug/1607867/+subscriptions
>

Revision history for this message
Damon Lynch (dlynch3) wrote :

So everything is working as expected now?

libmediainfo0v5 is included in the install.py script. If your system was detected as Debian (which it should have been), then it should have been installed.

Revision history for this message
JeanLucCoulon (jean-luc-coulon-f) wrote :
  • rpdl.txt Edit (1.7 KiB, text/plain; charset=US-ASCII; name="rpdl.txt")

No, not "everything" is working:
- The problem of asking for the card reader to be remembered is fixed.

- But I still have the program with the error I mentionned before : the
program stalls and gnome asks for cancel it. I have even uninstalled and
reinstalled it... Attached the console output while running it.

- When I have installed it (according to the procedure), I had no
libmediainfo installed... and it didnt complained about it.

2016-08-01 18:43 GMT+02:00 Damon Lynch <email address hidden>:

> So everything is working as expected now?
>
> libmediainfo0v5 is included in the install.py script. If your system was
> detected as Debian (which it should have been), then it should have been
> installed.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1607867
>
> Title:
> 0.9.04a stalls after a while
>
> Status in Rapid Photo Downloader:
> New
>
> Bug description:
> Hi,
>
> This applies to the 0.9 alpha version.
> I run Debian GNU/Linux sid.
>
> Desktop is gnome 3.20
>
> The transfer begin then the remaining time stay identical and it stops
> working.
> Sometimes it even doesnt start transfer.
>
> This occurs from a CF card which has already transfered pictures.
>
> After a while, gnome says the program is not responding and asks for
> force exit or wait.
>
> Version of python is 3.5.2
>
> Regards
>
> Jean-Luc
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/rapid/+bug/1607867/+subscriptions
>

Revision history for this message
Damon Lynch (dlynch3) wrote :

The console output indicates you've got multiple files with the same file name. Rapid Photo Downloader should handle that without crashing, certainly. But if you want to solve the problem today, you need to eliminate the duplicate file names. The best way to do that generally is to use sequence values, and simply ignore the camera generated numbers.

Check the install.py for yourself and see if it's possible to run that script without installing the libmediainfo package. It's a simple script, nothing complex.

Revision history for this message
JeanLucCoulon (jean-luc-coulon-f) wrote :

About the duplicate name, this didnt happened inside the camera. I was using my notebook during holidays to transfer my photos. When I remarked the problem, I switched back to 0.4.11, which worked fine.
So maybe during this operation I have had a file transferred and 0.9.0 tried to transfer it again.

I tried to uninstall everything including libmediainfo on my desktop computer.
If libmediainfo is missing on the system, then the install script ask to apt-get it... And it install it. If I refuse, the script exits without installing the software.
So there was "something" which removed libmediainfo *after*... I cannot remember.

So, I've accepted. libmediainfo was installed. But then, I get a bunch of errors like the following ones.

I can launch the program anyway and it seems to have a "normal" behavior. I've not tested further... I will see that tomorrow :)

Building wheels for collected packages: psutil, gphoto2, pyzmq, pyxdg, arrow, pyprind, colour, pymediainfo
  Running setup.py bdist_wheel for psutil ... error
  Complete output from command /usr/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-43948wm2/psutil/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" bdist_wheel -d /tmp/tmp4m0j_v0ppip-wheel- --python-tag cp35:
  usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
     or: -c --help [cmd1 cmd2 ...]
     or: -c --help-commands
     or: -c cmd --help

  error: invalid command 'bdist_wheel'

  ----------------------------------------
  Failed building wheel for psutil
  Running setup.py clean for psutil
  Running setup.py bdist_wheel for gphoto2 ... error
  Complete output from command /usr/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-43948wm2/gphoto2/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" bdist_wheel -d /tmp/tmpbf7_nb5ypip-wheel- --python-tag cp35:
  usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
     or: -c --help [cmd1 cmd2 ...]
     or: -c --help-commands
     or: -c cmd --help

  error: invalid command 'bdist_wheel'

  ----------------------------------------
  Failed building wheel for gphoto2
  Running setup.py clean for gphoto2
  Running setup.py bdist_wheel for pyzmq ... error
  Complete output from command /usr/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-43948wm2/pyzmq/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" bdist_wheel -d /tmp/tmpojzlnm9xpip-wheel- --python-tag cp35:
  usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
     or: -c --help [cmd1 cmd2 ...]
     or: -c --help-commands
     or: -c cmd --help

  error: invalid command 'bdist_wheel'

Revision history for this message
JeanLucCoulon (jean-luc-coulon-f) wrote :
Download full text (4.0 KiB)

Hi,
So....

I've deleted all the already existing files. And after a while, I managed
to have all the files on the disk.

So I retried everything.
I deleted the sqlite base, the folders with the video and pictures.
And I launched rpd.

Once again, it stalled.
- The cursor is at 38%.
- This time, the system respond to comand (menu...)
- All the Photos files have been downloaded
- The same for the Video files
- I have a rpd-tmp-xxxx directory in both Photos and Videos directories.
But they are empty.

On the backup external disk, I get only 1 (one) photo in the photos
directory
On the same disk, I've only 1 (one) video.

Attached the log.
Thereafter the console messages.

About libmediainfo missing: there is a command in debian (orphaner or
deborphan) to remove "unused" packages (the package with nothing depending
on). As rpd is not "packaged" (at least this version), libmediainfo was
deleted by such a command. I use it to cleanup the system time to time.

Regards

Jean-Luc

---
Console messages:

rapid-photo-downloader
Traceback (most recent call last):
  File
"/home/jean-luc/.local/lib/python3.5/site-packages/raphodo/backupfile.py",
line 272, in <module>
    backup = BackupFilesWorker()
  File
"/home/jean-luc/.local/lib/python3.5/site-packages/raphodo/backupfile.py",
line 50, in __init__
    super().__init__('BackupFiles')
  File
"/home/jean-luc/.local/lib/python3.5/site-packages/raphodo/interprocess.py",
line 845, in __init__
    self.do_work()
  File
"/home/jean-luc/.local/lib/python3.5/site-packages/raphodo/backupfile.py",
line 252, in do_work
    self.save_fdo_thumbnail(rpd_file, backup_full_file_name)
  File
"/home/jean-luc/.local/lib/python3.5/site-packages/raphodo/backupfile.py",
line 123, in save_fdo_thumbnail
    if rpd_file.fdo_thumbnail_128_name:
AttributeError: 'Photo' object has no attribute 'fdo_thumbnail_128_name'
Traceback (most recent call last):
  File
"/home/jean-luc/.local/lib/python3.5/site-packages/raphodo/backupfile.py",
line 272, in <module>
    backup = BackupFilesWorker()
  File
"/home/jean-luc/.local/lib/python3.5/site-packages/raphodo/backupfile.py",
line 50, in __init__
    super().__init__('BackupFiles')
  File
"/home/jean-luc/.local/lib/python3.5/site-packages/raphodo/interprocess.py",
line 845, in __init__
    self.do_work()
  File
"/home/jean-luc/.local/lib/python3.5/site-packages/raphodo/backupfile.py",
line 252, in do_work
    self.save_fdo_thumbnail(rpd_file, backup_full_file_name)
  File
"/home/jean-luc/.local/lib/python3.5/site-packages/raphodo/backupfile.py",
line 123, in save_fdo_thumbnail
    if rpd_file.fdo_thumbnail_128_name:
AttributeError: 'Video' object has no attribute 'fdo_thumbnail_128_name'

2016-08-01 21:52 GMT+02:00 Damon Lynch <email address hidden>:

> The console output indicates you've got multiple files with the same
> file name. Rapid Photo Downloader should handle that without crashing,
> certainly. But if you want to solve the problem today, you need to
> eliminate the duplicate file names. The best way to do that generally is
> to use sequence values, and simply ignore the camera generated numbers.
>
> Check the install.py for yourself and see if it's possible to run that
> script...

Read more...

Damon Lynch (dlynch3)
Changed in rapid:
importance: Undecided → High
assignee: nobody → Damon Lynch (dlynch3)
milestone: none → 0.9.0a5
status: New → In Progress
Revision history for this message
Damon Lynch (dlynch3) wrote :

Well I do believe that's a record for Rapid Photo Downloader: your bug report brought to the surface five different bugs and one not-yet-implemented-feature, with just one of the bugs being minor. Good job! :-)

Revision history for this message
JeanLucCoulon (jean-luc-coulon-f) wrote :

Hi,

Be careful: at the office (I'm retired now) nobody wanted I test his software... Because I always reported lots of bugs (it was automation real time software for locomotives).

J-L

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.