desktop-packages team mailing list archive

[Misaki <1444839@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Diagnosing this bug may be complicated by Bug #1443809. I am currently
using a custom thumbnailer for jpeg-2000 files, but before I did so, I
had created a number of jpeg-2000 files. While there were some cases
where they caused a crash, I think the eventual result was that they all
had 'failed thumbnails' created for them. Possibly eog created valid
thumbnails for them. (I can't check to see what happened because I
deleted my old thumbnails folder after upgrading.)

With no custom thumbnailers, nautilus will crash upon encountering a
jpeg-2000 file, with file suffix .jp2. As noted in Bug #1444790, it
doesn't crash if the jpeg-2000 file has a different suffix; it just
produces a 'failed thumbnail' in the thumbnails folder, which for
current Ubuntu versions is ~/.cache/thumbnails/fail. If the file was
created by copying an existing jpeg-2000 file in nautilus, nautilus
still crashes but only after invoking eog to create a thumbnail, so
after this is complete, navigating to that folder won't cause a crash.

If the thumbnail check was performed because the jpeg-2000 file was
renamed from an inappropriate suffix to .jp2, or because it was renamed
by some other method while not looking at the directory containing that
file (such as the command line, or maybe using the 'undo' function in
nautilus though this would require 1) having a normal or failed
thumbnail 2) renaming the file 3) deleting the thumbnail 4) nautilus
would have to stop using the cached thumbnail, and I don't think it
does), nautilus will crash without invoking eog for thumbnail creation,
and so will continue to crash whenever that folder is viewed.

A jpeg-2000 file can be generated using mogrify from imagemagick with
the command 'mogrify -format jp2 image.jpg'.

The advantages and disadvantages of jpeg-2000, compared to jpeg, are
described here: http://x264dev.multimedia.cx/archives/317 The type of
encoding used by jpeg-2000 is better for edges, while that used for jpeg
is better for broad areas of smaller, but nonzero amounts of variation.
There are definitely cases where jpeg-2000 is a better choice than jpeg
for retaining what is viewed as a sufficient level of quality in an
image, but users are unlikely to use it more if their applications don't
support it very well.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: nautilus 1:3.10.1-0ubuntu15.1
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.3
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Apr 15 22:52:39 2015
GsettingsChanges:
 b'org.gnome.nautilus.list-view' b'default-visible-columns' b"['name', 'size', 'date_modified', 'date_accessed', 'type']"
 b'org.gnome.nautilus.list-view' b'default-column-order' b"['name', 'size', 'date_modified', 'date_accessed', 'type', 'group', 'where', 'mime_type', 'owner', 'permissions']"
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: nautilus (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: amd64 apport-bug utopic

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/1444839

Title:
  jpeg-2000 files cause Nautilus to crash

Status in nautilus package in Ubuntu:
  New

Bug description:
  Diagnosing this bug may be complicated by Bug #1443809. I am currently
  using a custom thumbnailer for jpeg-2000 files, but before I did so, I
  had created a number of jpeg-2000 files. While there were some cases
  where they caused a crash, I think the eventual result was that they
  all had 'failed thumbnails' created for them. Possibly eog created
  valid thumbnails for them. (I can't check to see what happened because
  I deleted my old thumbnails folder after upgrading.)

  With no custom thumbnailers, nautilus will crash upon encountering a
  jpeg-2000 file, with file suffix .jp2. As noted in Bug #1444790, it
  doesn't crash if the jpeg-2000 file has a different suffix; it just
  produces a 'failed thumbnail' in the thumbnails folder, which for
  current Ubuntu versions is ~/.cache/thumbnails/fail. If the file was
  created by copying an existing jpeg-2000 file in nautilus, nautilus
  still crashes but only after invoking eog to create a thumbnail, so
  after this is complete, navigating to that folder won't cause a crash.

  If the thumbnail check was performed because the jpeg-2000 file was
  renamed from an inappropriate suffix to .jp2, or because it was
  renamed by some other method while not looking at the directory
  containing that file (such as the command line, or maybe using the
  'undo' function in nautilus though this would require 1) having a
  normal or failed thumbnail 2) renaming the file 3) deleting the
  thumbnail 4) nautilus would have to stop using the cached thumbnail,
  and I don't think it does), nautilus will crash without invoking eog
  for thumbnail creation, and so will continue to crash whenever that
  folder is viewed.

  A jpeg-2000 file can be generated using mogrify from imagemagick with
  the command 'mogrify -format jp2 image.jpg'.

  The advantages and disadvantages of jpeg-2000, compared to jpeg, are
  described here: http://x264dev.multimedia.cx/archives/317 The type of
  encoding used by jpeg-2000 is better for edges, while that used for
  jpeg is better for broad areas of smaller, but nonzero amounts of
  variation. There are definitely cases where jpeg-2000 is a better
  choice than jpeg for retaining what is viewed as a sufficient level of
  quality in an image, but users are unlikely to use it more if their
  applications don't support it very well.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.10
  Package: nautilus 1:3.10.1-0ubuntu15.1
  ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
  Uname: Linux 3.16.0-30-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.14.7-0ubuntu8.3
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Apr 15 22:52:39 2015
  GsettingsChanges:
   b'org.gnome.nautilus.list-view' b'default-visible-columns' b"['name', 'size', 'date_modified', 'date_accessed', 'type']"
   b'org.gnome.nautilus.list-view' b'default-column-order' b"['name', 'size', 'date_modified', 'date_accessed', 'type', 'group', 'where', 'mime_type', 'owner', 'permissions']"
  SourcePackage: nautilus
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1444839/+subscriptions