This bug usually doesn't appear after starting the computer, but after a few hours.

i suspect here the pb is NFS. maybe like bug #10907

Mageia 3 changed to end-of-life (EOL) status 4 months ago.
http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ 

Mageia 3 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
The Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => OLD

Still true in Mageia 4: Gwenview is very slow (several minutes) to start, on all our computers, but the problem usually don't appear just after booting, only after a while. If I launch Gwenview from a terminal, with no argument, I now get:

Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath)
Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath)
gwenview(9274)/kdeui (kdelibs): Attempt to use QAction "edit_redo" with KXMLGUIFactory! 
gwenview(9274)/kdeui (kdelibs): Attempt to use QAction "edit_undo" with KXMLGUIFactory! 

It's high time to make things which should have nothing to do with NFS independent from NFS.

Status: RESOLVED => REOPENED
Version: 3 => 4
Resolution: OLD => (none)
Target Milestone: --- => Mageia 5
Severity: normal => major

Assigning to maintainer

CC: (none) => marja11
Assignee: bugsquad => mageia

I am having similar/worse problems with Gwenview 4.14.3 on newly-installed Mageia-5.

There is already a KDE bug that perhaps should be linked:  341594.
  I have commented there.

(Because Gwenview is one of our bread-and-butter apps, I have had to revert back to Mageia-4 pro tem...  :-)  )

CC: (none) => maurice

Hi Maurice,

(In reply to Maurice Batey from comment #6)
> I am having similar/worse problems with Gwenview 4.14.3 on newly-installed
> Mageia-5.
> 

No problems here. Some questions:

1. Can you describe your machine's setup?

2. Does it happen in a new UNIX user account on IceWM/other-lightweight-environment.

> There is already a KDE bug that perhaps should be linked:  341594.
>   I have commented there.
> 

Just for the record, here is the URL To this bug for convenience:

https://bugs.kde.org/show_bug.cgi?id=341594

> (Because Gwenview is one of our bread-and-butter apps, I have had to revert
> back to Mageia-4 pro tem...  :-)  )

It would be useful if you can provide a recipe to reproduce this bug, which may download some files from image/video sharing sites.

Regards,

-- Shlomi Fish

CC: (none) => shlomif

(In reply to Shlomi Fish from comment #7)

> Just for the record, here is the URL To this bug for convenience:
> 
> https://bugs.kde.org/show_bug.cgi?id=341594
> 
And i added to URL :)

Just out of curiosity does the problem happen in dolphin also?
is preview enabled? gw iirc add thumbnails files for previews, and maybe if
the number of picture is big that could require a lot, and via NFS also adds
network. Just a shot in the dark

(In reply to Angelo Naselli from comment #8)
> (In reply to Shlomi Fish from comment #7)
> 
> > Just for the record, here is the URL To this bug for convenience:
> > 
> > https://bugs.kde.org/show_bug.cgi?id=341594
> > 
> And i added to URL :)
> 
> Just out of curiosity does the problem happen in dolphin also?
> is preview enabled? gw iirc add thumbnails files for previews, and maybe if
> the number of picture is big that could require a lot, and via NFS also adds
> network. Just a shot in the dark

What do you mean by all that? I find what you said to be incoherent and unstructured.

I mean that gwenview could be not freezed, but it could work in foreground mode to write thumbnail info somewhere. And that, this operation could require time if the number of pictures is huge. 

Gwenview can also be opened on a directory like dolphin and, like dolphin, shows thumbnail icons as pictures preview

s/freezed/frozen

> Gwenview can also be opened on a directory like dolphin

That is what I do:  gwenview /photos/mypictures

Perahps it is apparently frozen when writing thumbnails, but the Mageia-4 gwenview does it all without delay, and has never shown any signs of freezing.

> It would be useful if you can provide a recipe to reproduce this bug, 

 Just build a photo library like mine with 203 subfolders containing 5,500+ photo/video(a few) files in /photos/mypictures, and do 
    gwenview /photos/mypictures !


> which may download some files from image/video sharing sites.

  The photo library is housed in a separate partition (/photos) on the hard drive, so should work without a network connection!

N.B. I did attach in https://bugs.kde.org/show_bug.cgi?id=341594 a log of a terminal session in which the above call of gwenview was done.

(In reply to Maurice Batey from comment #13)
> > It would be useful if you can provide a recipe to reproduce this bug, 
> 
>  Just build a photo library like mine with 203 subfolders containing 5,500+
> photo/video(a few) files in /photos/mypictures, and do 
>     gwenview /photos/mypictures !
> 
hmm don't think it is that the problem.
[anaselli@gandalf Foto]$ find . -name "*.jpg" | wc -l
4592
[anaselli@gandalf Foto]$ find . -name "*.JPG" | wc -l
14836
[anaselli@gandalf Foto]$ tree -d | wc -l
1590
[anaselli@gandalf Foto]$ find . -name "*.AVI" | wc -l
670
[anaselli@gandalf Foto]$ find . -name "*.avi" | wc -l
7
[anaselli@gandalf Foto]$ find . -name "*.mpg" | wc -l
1
[anaselli@gandalf Foto]$ du -hs .
92G     .


By any chance do you have the "Delete thumbnail cache folder on exit" checked on your settings?

you could also run kdebugdialog and enable more debug messages on kde and gwenview

> By any chance do you have the "Delete thumbnail cache folder on exit" 
> checked on your settings?

  Not on Mageia-4 (Didn't know of its existence!) 
Will give it a try on Mageia-5.

> you could also run kdebugdialog and enable more debug messages on 
> kde and gwenview

  Happy to help, but rather than splatter around all kinds of things that I think might help, I will leave it to the magicians to say what it is that they want.

On Mageia-5 I have now tried with the Gwenview 'delete thumbnails on exit' option selected. 
  Made no difference. 
After doing gwenview /photos/mypictures, gwenview displayed all 203 subfolders, but no thumbnails visible, and the app was totally unresponsive. Had to force exit. 
  Checked ~/.thumbnails several times during freeze: Always empty.

> Checked ~/.thumbnails several times during freeze: Always empty.

  Before Gwenview emptied it (after I set the option), there were 5,424 'normal' thumbnails in there, presumably from the last successful execution.
  (That's about the number of files in /photos/mypictures.)

I have run an strace of the call on gwenview that freezes. 
Can be seen here:

 https://dl.dropboxusercontent.com/u/10969499/gwenview-strace.txt 

(Too big to Attach, I think)

(In reply to Angelo Naselli from comment #14)
> (In reply to Maurice Batey from comment #13)
> > > It would be useful if you can provide a recipe to reproduce this bug, 
> > 
> >  Just build a photo library like mine with 203 subfolders containing 5,500+
> > photo/video(a few) files in /photos/mypictures, and do 
> >     gwenview /photos/mypictures !
> > 
> hmm don't think it is that the problem.
> [anaselli@gandalf Foto]$ find . -name "*.jpg" | wc -l
> 4592
> [anaselli@gandalf Foto]$ find . -name "*.JPG" | wc -l
> 14836
> [anaselli@gandalf Foto]$ tree -d | wc -l
> 1590
> [anaselli@gandalf Foto]$ find . -name "*.AVI" | wc -l
> 670
> [anaselli@gandalf Foto]$ find . -name "*.avi" | wc -l
> 7
> [anaselli@gandalf Foto]$ find . -name "*.mpg" | wc -l
> 1
> [anaselli@gandalf Foto]$ du -hs .
> 92G     .
> 
> 

I cannot reproduce it either - 19,730 .jpg files in 300 directories with an .avi and a .wmv in each , under /photos/mypictures and gwenview is working fine and being completely responsive.

> By any chance do you have the "Delete thumbnail cache folder on exit"
> checked on your settings?

Created attachment 6774 [details]
Maurice's gwenview-strace after being compressed with xz.

For posterity , here is Maurice's gwenview-strace after being compressed with xz so it's no longer too large.

I'm just guessing.
/photos/mypictures/needles.jpg
and 
/photos/mypictures/SSCA000560th BIRTHDAY.JPG

But I could be wrong, just run it using strace and if errors are on different
files then my assumption is not correct.

Silly question, your uid and gid are the same of the /photos/mypictures directory?

This is not just happening with large directories. Earlier today I attempted to open an image directory with 6 or 7 images with Gwenview by using the "Open with" function of the Dolphin context menu. Gwenview froze, had to be terminated. However, if I opened that same directory with Dolphin and clicked on a specific image, the way I usually use it, Gwenview came up and worked perfectly.

CC: (none) => andrewsfarm

As expected indeed :) So we should/could try to understand what is the cause.
A kind of file maybe or some not utf8 character in names (directory included)...
That could help the developers, and we could send the information upstream

I do believe you've hit upon it, Angelo. The directory I chose in my limited test contained mixed files directly from an old Vivitar camera, some labeled with .JPG extensions and two labeled with .AVI extensions. All capital letters on the extensions, as provided by the camera.

I just went back to my Pictures directory and attempted to load some directories with just photos, from various cameras, and they worked fine. Then I tried a directory with some photos from the Vivitar camera, other photos and .mp4 videos from an Android tablet, and copies of those .mp4 videos that had been run through Handbrake to reduce them in size for uploading, but still with.mp4 extensions. Gwenview started to load the thumbnails, but when it got to the raw videos at the end, it froze. It did not freeze on the processed videos. But, if I told Dolphin to use Gwenview to open specific raw videos it had no problem with them.

Maurice has written that his directories also contain some videos. Perhaps it is those that are triggering the problem.

> Maurice has written that his directories also contain some videos. Perhaps it > is those that are triggering the problem.

  But they work with Mageia-4's Gwenview...

Hi Thomas,

(In reply to Thomas Andrews from comment #23)
> This is not just happening with large directories. Earlier today I attempted
> to open an image directory with 6 or 7 images with Gwenview by using the
> "Open with" function of the Dolphin context menu. Gwenview froze, had to be
> terminated. However, if I opened that same directory with Dolphin and
> clicked on a specific image, the way I usually use it, Gwenview came up and
> worked perfectly.

can you provide a test case (as minimal as possible preferably) for that? I am still unable to reproduce it.

> I'm just guessing.
>  /photos/mypictures/needles.jpg
> and 
>  /photos/mypictures/SSCA000560th BIRTHDAY.JPG

I *removed* those two from  '/photos/mypictures' and ran Mageia-5 Gwenview again.

  Result: Worse than before: Not only did gwenview freeze after showing all the directories in /mypictures, but it locked the whole PC and I had to Ctl-Sysrec-B out and reboot!  That gwenview seems very sick.
  Perhaps there needs to be an examination of the changes since 4.12.2....

> Silly question, your uid and gid are the same of the /photos/mypictures 
> directory?

 Indeed.

Created attachment 6779 [details]
Vivitar video that freezes Gwenview's directory function

This video file is one of two that I have that are short enough to be under the upload limit. I have no video files from the Android tablet less than 6.7 MB, and that tablet is no longer operable.

If there is some other way for me to get a 6.7MB mp4 file to you, please let me know.

I have tried renaming the mp4 video file, and it makes no difference. My guess would be that perhaps Gwenview is running into trouble while generating the thumbnail because of the format of the file. Why it should do that when it is able to play the file is a mystery to me.

I just ran Gwenview from the KDE menu. I was able to navigate at will through my Pictures directory, until I attempted to open my "tests" directory containing several .jpg files and at the end one of the video files that has been causing the problem. Gwenview generated thumbnails normally until it reached that video file, and there it stuck.

I failed to mention that I'm using the 32-bit version of Mageia 5. I no longer have a Mageia 4 to try.

Hi Thomas,

(In reply to Thomas Andrews from comment #30)
> If there is some other way for me to get a 6.7MB mp4 file to you, please let
> me know.

You can email it as an attachment to shlomif@gmail.com and I'll upload it somewhere under http://www.shlomifish.org/ . It would be better if it were a complete tarball that can create the offending data structure (if that is possible) instead of just bits and pieces of the contents.

Regards,

-- Shlomi Fish

> I *removed* those two from  '/photos/mypictures' and ran 
> Mageia-5 Gwenview again.

>  Result: Worse than before: Not only did gwenview freeze after showing 
> all the directories in /mypictures, but it locked the whole PC and 
> I had to Ctl-Sysrec-B out and reboot! 

Have just run strace again. This time it froze without showing any if the subfolders in /mypictures, but Mageia-5 gave me the option of exiting gwenview.  

The strace can be seem here:

 https://dl.dropboxusercontent.com/u/10969499/gwenview-strace-2.txt

> I attempted to open my "tests" directory containing several .jpg files 
> and at the end one of the video files that has been causing the problem.

Well, I've just got Mageia-5 gwenview to open one of the sub-directories, containing mostly .jpg files but also several .MOV files.
  No problem!  In a slideshow, it played the .MOV files perfectly...

What it fails to do is properly open a directory containing directories.
  It freezes either before or after showing the contained directories - something the Mageia-4 version has no problem with.

well there are several reasons why a behavior is changed, a bug in the new code.
A bug in the libraries used (maybe hidden before), a changed behavior of a library used, data read from a file that before return nothing or that now are
different for any reasons... etc.

I recall here we are packagers not developers, for the most. So we are trying
to find how to reproduce the problem to push upstream as much info as possible.
And maybe if lucky, to find some workarounds...
 
By any chance do you both are on i586 arch?

> By any chance do you both are on i586 arch?

I have 64-bit Mageia-5 on two desktops, and 32-bit on laptop.

   Same Gwenview problem on both.

N.B. On laptop, Gwenview actually worked perfectly the 1st time, but has always failed since then.  (Weird)

Gthumb
======
On a recommendation I installed Gthumb (which - like Mageia-5 Gwenview - does not handle nested directories) on both Mageia-4 and Mageia-5, with different results w.r.t. .MOV video clips when given a directory (containing mainly jpg but some .MOV files) to open.

Mageia-4: Gthumb happily ran the video clip files.
Mageia-5: Gthumb showed the video files 'greyed out' and would not run them.

  Which says to me that something w.r.t. video files has changed between Mageia-4 and Mageia-5, apparently affecting both Gwenview and Gthumb.
   Mmm. What a coincidence...

or a missed dependency... in that case it our fault (mageia side I mean)

SOLVED! (sort of)

> I'm just guessing.
>     /photos/mypictures/needles.jpg
> and 
>     /photos/mypictures/SSCA000560th BIRTHDAY.JPG

Angelo, you were not far off!
  I've located the 1 file that was screwing Mageia-5 gwenview here:

     "TaleofTwoBrains.wmv"  (4.6MiB)

N.B. When the file is given directly to gwenview, it runs it normally.
     When it is in a directory and given to Gwenview, the latter freezes. 

I will attach a trace of that.

N.B. Also: With only that file removed from the photo library, Mageia-5 gwenview works fine - despite nested directories and other video files!
  So - that's my workaround for Mageia-5.

The question remaining is: Why does gwenview freeze if that file is in a folder, but work normally when passed direct?

> I will attach a trace of that.

  Too big for that; can be seen here:

     https://dl.dropboxusercontent.com/u/10969499/gwenview-strace-3.txt

I could also make available a copy of "TaleofTwoBrains.wmv" (4.6MiB), 
though I suspect any .vmw file would do it.

It's the thumbnail generator, Maurice. It looks to me like it can handle image files, but not some video files. And it isn't the container format (indicated by the file extension), but the coding format used in the file. That would indicate one or more codecs perhaps unavailable to the thumbnail generator but available to the viewer itself. Perhaps Gthumb uses the same libraries to generate thumbs that Gwenview does, so it doesn't work any better.

Or, I could not know a thing that I'm writing about.

I wonder, could Maurice and I both be missing a library we need from the tainted repository?

(In reply to Maurice Batey from comment #40)
> > I will attach a trace of that.
> 
>   Too big for that; can be seen here:
> 
>      https://dl.dropboxusercontent.com/u/10969499/gwenview-strace-3.txt
> 
> I could also make available a copy of "TaleofTwoBrains.wmv" (4.6MiB), 
> though I suspect any .vmw file would do it.

The .wmvs that I tried worked fine, so please make it available. Please see if it happens when gwenview is invoked twice on a directory that only contains it, and tar the offending directory structure.

(In reply to Maurice Batey from comment #40)
> > I will attach a trace of that.
> 
>   Too big for that; can be seen here:
> 
>      https://dl.dropboxusercontent.com/u/10969499/gwenview-strace-3.txt
> 
> I could also make available a copy of "TaleofTwoBrains.wmv" (4.6MiB), 
> though I suspect any .vmw file would do it.

Maybe not. I have some mp4 files that work fine, and others that make it freeze.

> The .wmvs that I tried worked fine, so please make it available.

  Here it is (quite amusing...):

  https://dl.dropboxusercontent.com/u/10969499/TaleofTwoBrains.wmv


> tar the offending directory structure.

   The file is on its own in:   /mga4-home/mab/gwenview-hide

What precisely is it you would like tarred? (Not familiar with tar)

that file works here

(In reply to Angelo Naselli from comment #45)
> that file works here

Yes, I cannot reproduce any offending behaviour. Tried starting gwenview from that folder several times. I'll also try in a Mageia 5 VM.

Regards,

-- Shlomi Fish

Maybe a dependency issue? (just a note passing by)

(In reply to Shlomi Fish from comment #46)
> (In reply to Angelo Naselli from comment #45)
> > that file works here
> 
> Yes, I cannot reproduce any offending behaviour. Tried starting gwenview
> from that folder several times. I'll also try in a Mageia 5 VM.
> 
> Regards,
> 
> -- Shlomi Fish

OK, in a Mageia 5 x86-64 VM , I'm getting a freeze on icewm after I did:

urpmi --auto task-x11 icewm gwenview dolphin

However, I am able to fix it after I do "urpmi task-pulseaudio" and then reboot and after that the folder with that file opens fine.

Regards,

-- Shlomi Fish

> [Angelo said] "that file works here"

When in a directory handed over to gwenview?

(Works here when passed direct to gwenview.)

Yes i opened gw into directory e.g. gwenview dir_path, and after i clicked on that file

Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer 
maintained, which means that it will not receive any further security or bug 
fix updates.

Package Maintainer: If you wish for this bug to remain open because you plan to 
fix it in a currently maintained version, simply change the 'version' to a later 
Mageia version.

Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't 
able to fix it before Mageia 4's end of life. If you are able to reproduce it 
against a later version of Mageia, you are encouraged to click on "Version" and 
change it against that version of Mageia. If it's valid in several versions, 
select the highest and add MGAxTOO in whiteboard for each other valid release.
Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO.

Although we aim to fix as many bugs as possible during every release's lifetime, 
sometimes those efforts are overtaken by events. Often a more recent Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

If you would like to help fixing bugs in the future, don't hesitate to join the
packager team via our mentoring program [1] or join the teams that fit you 
most [2].

[1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
[2] http://www.mageia.org/contribute/

As announced over a month ago, Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates.

This issue may have been fixed in a later Mageia release, so, if you still see it and didn't already do so: please upgrade to Mageia 5 (or, if you read this much later than this is written: make sure you run a currently maintained Mageia version)

If you are able to reproduce it against a maintained version of Mageia, you are encouraged to 
1. reopen this bug report, by changing the "Status" from "RESOLVED - OLD" to "REOPENED"
2. click on "Version" and change it against that version of Mageia. If you know it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release.
Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO.
3. give as much relevant information as possible. If you're not an experienced bug reporter and have some time: please read this page:
https://wiki.mageia.org/en/How_to_report_a_bug_properly

If you see a similar issue, but are _not_sure_ it is the same, with the same cause, then please file a new bug report and mention this one in it (please include the bug number, too). 


If you would like to help fixing bugs in the future, don't hesitate to join the
packager team via our mentoring program [1] or join the teams that fit you 
most [2].
[1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
[2] http://www.mageia.org/contribute/

Status: REOPENED => RESOLVED
Resolution: (none) => OLD