Shotwell will not detect mts moviefiles on memory card

Bug #990725 reported by melenzb on 2012-04-28
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
shotwell (Ubuntu)
Low
Unassigned
Precise
Low
Unassigned

Bug Description

Expected behavior: Shotwell will detect and import pictures als well as movies files. The latter being of type avchd and stored in the folder /PRIVATE/AVCHD/BDMV/STREAM.

Exhibited behavior: Shotwell only lists and downloads the jpg photoś

This has worked all the way through the beta era. Just now after release I notice that it will not see my video's

I have not done a clean install, but updated all the way from alpha release.

melenzb (woodhouser) wrote :

Version shotwell
0.12.2
Version Ubuntu
12.04 64 bit.

Adam Dingle (adam-yorba) wrote :

In 0.12 we changed Shotwell so that if a top-level DCIM directory is present on your camera or card, Shotwell looks only in that directory and no others. We did this to avoid importing lots of useless thumbnails on Android phones (see http://redmine.yorba.org/issues/1903).

Do you have a DCIM directory on your card?

Changed in shotwell (Ubuntu):
importance: Undecided → Low
status: New → Incomplete

Hi Adam,

That is a real pity! A lot of digicams these days carry their movies in
a acvhd bluray disc compatible directory that is not beneath the dcim
directory ( at least the panasonic camera's) I was quite confident that
shotwell would replace digikam on my wife's and my dad's new ubuntu
install. I tested it quite a while and it seemed the ideal solution
until now . It really does need to download video's too, otherwise these
less computer literate people are not going to cope with it.

Could you consider to add a toggle for this in the settings?

Is there any other work around?

On 04/29/2012 02:11 PM, Adam Dingle wrote:
> In 0.12 we changed Shotwell so that if a top-level DCIM directory is
> present on your camera or card, Shotwell looks only in that directory
> and no others. We did this to avoid importing lots of useless
> thumbnails on Android phones (see http://redmine.yorba.org/issues/1903).
>
> Do you have a DCIM directory on your card?
>

Adam Dingle (adam-yorba) wrote :

The workaround for now is simply to open the camera or memory card in Nautilus, and drag the videos from the directory where they live into Shotwell. Obviously that's not ideal, and I'd like to do better for Shotwell 0.13:

http://redmine.yorba.org/issues/5160

In theory we could add a settings toggle, though it would be better if we could just do the right thing automatically. We'll investigate more.

melenzb (woodhouser) wrote :

I tried that, but it will not link my movies to events based on the
creation date that way. I'm quite sure the shotwell version in oneiric
did that correctly.

For me this application seems of no use any more. Such a pity. It was
ideal! I can't see how many many users are not affected by this. Will
see if i can find a source for an old versoin usable for precise, but
this is taking too much time and tinkering. Losing appetite....

melenzb (woodhouser) wrote :

The last remark is a bit harsh I suppose. I admire your effort in making such a great piece of software. In the mean time I have compiled my own version op shotwell, where I changed the bit of code where it looks for dcim/DCIM. I will see how it goes.

Adam Dingle (adam-yorba) wrote :

melenzb: Thanks for your patience. I know it can be frustrating when you like a piece of software but one important bug is blocking you. We'll fix this when we can, hopefully soon. In the meantime, I'm glad you know how to hack the code to work around the problem yourself. :)

Clint Rogers (clinton-yorba) wrote :

melenzb: You'll be pleased to know that we've just checked a small fix into trunk that should help, and it's slated for inclusion into 0.12.3. Along with checking for the presence of (and enumerating image and video files in) /DCIM, we'll now also try /PRIVATE/AVCHD and /AVCHD as well, which should cover most camcorders.

You can find out more about the code for this change here: http://redmine.yorba.org/projects/shotwell/repository/revisions/7b0340f9b6c4fda7bab1c9efc00bd22ccac6672a/diff/src/camera/ImportPage.vala .

Thank you again for your patience, as well as for your interest in Shotwell.

melenzb (woodhouser) wrote :

that is great news! Let's hope the friendly ubuntu people package this quickly so that all people with a panasonic digicam can download their entire card again, including movies

12.3 we await thee!! ;-)

in the mean time i will have to deal with the fact that the shotwell icon is not shown with my own compiled version in unity.. (any ideas why?)

Clint Rogers (clinton-yorba) wrote :

Hi again,

This question is unrelated to the bug report, so it, along with future questions of a similar type might be better directed to our mailing list (<email address hidden>). That said, here's how to enable the Unity sidebar icon:

1) From the command line, navigate to the directory where the Shotwell source tree was cloned.
2) Type './configure --unity-support'.
3) Once this command completes, run 'make' as you normally would.

This should cause Unity support to be compiled into the executable.

Adam Dingle (adam-yorba) wrote :

melenzb: The Shotwell icon also fails to show up for me when I build Shotwell myself. Not sure why - I've been meaning to look into this at some point. For some other developers at Yorba the icon shows up fine in their own build.

Clint: The configure option --unity-support is actually unrelated to this problem. That option enables a progress bar in the Unity sidebar, but has no effect on the icon which is displayed there.

Adam Dingle (adam-yorba) wrote :

Actually it appears that the Unity sidebar displays a generic folder icon whenever Shotwell is run from the build directory but hasn't been installed. I consider this a bug, and just created a ticket upstream:

http://redmine.yorba.org/issues/5176

Changed in shotwell (Ubuntu):
status: Incomplete → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package shotwell - 0.12.3-0ubuntu1

---------------
shotwell (0.12.3-0ubuntu1) quantal; urgency=low

  * New upstream version, fixes:
    - Shotwell deletes tags at random (lp: #999108)
    - shotwell's unity progress bar hangs halfway across (lp: #987046)
    - Shotwell will not detect mts moviefiles on memory card (lp: #990725)
 -- Sebastien Bacher <email address hidden> Wed, 16 May 2012 15:18:16 +0200

Changed in shotwell (Ubuntu):
status: Fix Committed → Fix Released
Changed in shotwell (Ubuntu Precise):
importance: Undecided → Low
status: New → Fix Committed

Hello melenzb, or anyone else affected,

Accepted shotwell into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

tags: added: verification-needed
Sebastien Bacher (seb128) wrote :

That seems to still be buggy there, videos are not listed on a lumix camera with 0.12.3

Clint Rogers (clinton-yorba) wrote :

Hi Sebastien,

Where do the videos normally get written to on a Lumix?

Due to a workaround to some problems between GPhoto and many Android devices (http://redmine.yorba.org/issues/1903), we've had to explicitly whitelist directories we want it to tell us about.

(I admit this is a suboptimal way of solving the issue, but at the time the initial bugfix was applied, it was too late in the development cycle to try to get GPhoto fixed; in order to help current users, we'll whitelist whatever directory you specify, with the understanding that we should try to help GPhoto have the ability to report the existence of .nomedia files (please see http://redmine.yorba.org/issues/4238 for details)).

Sebastien Bacher (seb128) wrote :

@Clint: similar to the bug description, the files are in "/PRIVATE/AVCHD/BDMV/STREAM" ... do you include subdirectories? Do you filter on the formats handled?

Clint Rogers (clinton-yorba) wrote :

Hi Sebastien,

We do traverse all subdirectories inside a 'well-known' directory, so anything saved inside /PRIVATE/AVCHD should have been found. As for filtering, we don't, to my knowledge, leave out any video formats.

Is this happening when you connect the camera directly? Do you see the same behaviour if you mount the card in question as removeable mass storage?

Sebastien Bacher (seb128) wrote :

> Is this happening when you connect the camera directly? Do you see the same behaviour if you mount the card in question as removeable mass storage?

I've been testing by using the sd card since I don't have my camera usb cable around, I will try with it later on to see if that makes a difference, I'm happy to debug the issue with a debugger or with printf statement if you have any hint of where to start

Sebastien Bacher (seb128) wrote :

Not sure what to do with this bug, 0.12.3 will not move to -updates until the bug is either verified to be fixed (since that update was supposed to fix it) or declared as failed verification without regression (i.e issue is not fixed but it's not creating any new problem so the update is still a win)

Lucas Beeler (lucas-yorba) wrote :

Hi Sebastien,

I'm not sure why your MTS videos aren't being enumerated. But they're not, and this bug can't be marked as "fix verified" until they are.

That said, the fix we implemented to correct this bug cannot cause a regression because it only expands the number of directories that Shotwell searches for video files. You can examine the changeset for the fix here: http://redmine.yorba.org/projects/shotwell/repository/revisions/7b0340f9b6c4fda7bab1c9efc00bd22ccac6672a/diff/src/camera/ImportPage.vala and confirm this yourself.

Therefore, it is our strong preference that this bug be marked as "failed verification without regression" so as not to delay the distribution of the 0.12.3 update, particularly because the 0.12.3 update corrects a critical issue that causes data loss (i.e. "Shotwell deletes tags at random, lp: #999108") and the fix for this latter, more serious issue has been verified.

As another data point on the stability of 0.12.3, we ship Shotwell as a source tarball (see http://yorba.org/shotwell/install/) for users on other distros. Traffic on the mailing list confirms that users are building 0.12.3 from source -- on other distros as well as on Ubuntu -- and we've received no reports of any regression in video detection. Since 0.12.3 was released on May 9 and has been running in the wild for over two weeks now, we'd expect to hear about any regression that might've occurred.

Just to re-iterate, from our perspective, the best way to go here is to mark this bug as "failed verification without regression." We'll fix this bug in the 0.13 cycle, but we don't think its verification failure should delay the push of the 0.12.3 update. Of course, you guys have your own perspectives and considerations, so you may want to do something different. We'll help in any way we can.

Take care, Sebastien! All of us at Yorba look forward to linking up with you guys again at GUADEC this summer!

Cheers,
Lucas

Sebastien Bacher (seb128) wrote :

Thanks Lucas, I agree with you that we shouldn't block the update on that, I'm still interested to see the lumix camera case fixed and wanting to provide debug infos (I can apply a patch locally to print informations or use a debugger if you tell me what I should watch for) if you think that can helps to get it resolved for the next update

tags: added: verification-done
removed: verification-needed
Lucas Beeler (lucas-yorba) wrote :

> I'm still interested to see the lumix
> camera case fixed and wanting to
> provide debug infos

We're very interested in fixing this too. We reopened the upstream bug (http://redmine.yorba.org/issues/5160) two days ago. Clinton will be get you a patch with some diagnostic printouts in a few days.

Lucas

Sebastien Bacher (seb128) wrote :

I tried again today with a sdcard and my camera and the videos are correctly list so I wonder if something was wrong with the card I previously tried, closing the bug then

Changed in shotwell (Ubuntu Precise):
status: Fix Committed → Fix Released
status: Fix Released → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package shotwell - 0.12.3-0ubuntu0.1

---------------
shotwell (0.12.3-0ubuntu0.1) precise-proposed; urgency=low

  * New upstream version, fixes:
    - Shotwell deletes tags at random (lp: #999108)
    - shotwell's unity progress bar hangs halfway across (lp: #987046)
    - Shotwell will not detect mts moviefiles on memory card (lp: #990725)
 -- Sebastien Bacher <email address hidden> Wed, 16 May 2012 15:29:40 +0200

Changed in shotwell (Ubuntu Precise):
status: Fix Committed → Fix Released

As an aside, I believe I know what happened when it initially didn't
work; I've identified a repro case for it, although 90% of users
shouldn't have this problem.

When we start enumerating media files on a storage device, we
explicitly check several well-known paths, such as /DCIM, /AVCHD and
so on. Because most cameras seem to 'prefer' MS DOS- or Joliet-safe
filenames, usually, camera-created directories' pathnames are all
uppercase or all lowercase. However, if one were to have something
like '/PRIVATE/avchd/' or /private/AVCHD' on a storage device, while
the camera would probably 'see' it as '/PRIVATE/AVCHD/' work correctly
with it, gPhoto, and by extension, Shotwell wouldn't enumerate images
or video correctly, because there currently doesn't seem to be a way
to tell gPhoto to treat a path as being case-insensitive, and if we do
a case-insensitive directory search on Shotwell's side, we may end up
with a scenario where we think 'yes, /private/avchd exists, tell me
what's in it', when what gPhoto actually sees is a different (by case)
path and (correctly) reports no files (since, as far as it's
concerned, the path we're trying to look in doesn't really exist).

As for how to fix this definitively: the way forward would be to make
gPhoto able to report the existence of .nomedia files, and once this
happened, we could remove the whitelisting mechanism entirely, meaning
a user or imaging device could put photos or videos into any path they
wanted and still have correct results.

On 28/05/2012, Launchpad Bug Tracker <email address hidden> wrote:
> This bug was fixed in the package shotwell - 0.12.3-0ubuntu0.1
>
> ---------------
> shotwell (0.12.3-0ubuntu0.1) precise-proposed; urgency=low
>
> * New upstream version, fixes:
> - Shotwell deletes tags at random (lp: #999108)
> - shotwell's unity progress bar hangs halfway across (lp: #987046)
> - Shotwell will not detect mts moviefiles on memory card (lp: #990725)
> -- Sebastien Bacher <email address hidden> Wed, 16 May 2012 15:29:40 +0200
>
> ** Changed in: shotwell (Ubuntu Precise)
> Status: Fix Committed => Fix Released
>
> --
> You received this bug notification because you are subscribed to
> shotwell in Ubuntu.
> https://bugs.launchpad.net/bugs/990725
>
> Title:
> Shotwell will not detect mts moviefiles on memory card
>
> Status in “shotwell” package in Ubuntu:
> Fix Released
> Status in “shotwell” source package in Precise:
> Fix Released
>
> Bug description:
> Expected behavior: Shotwell will detect and import pictures als well
> as movies files. The latter being of type avchd and stored in the
> folder /PRIVATE/AVCHD/BDMV/STREAM.
>
> Exhibited behavior: Shotwell only lists and downloads the jpg photoś
>
> This has worked all the way through the beta era. Just now after
> release I notice that it will not see my video's
>
> I have not done a clean install, but updated all the way from alpha
> release.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/990725/+subscriptions
>

--
public struct Box {
    public static const int HAND_GRENADES = 12;
-- from shotwell/src/Box.vala

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

Other bug subscribers