BUG - Crash in digikam while reading metadata from a .MTS movie file
This seems to happen when exiv2 runs into a .MTS movie file that it doesn't understand.
I was referred to here to enter a bug report, but don't see how to do that.
Attachment contains the crash dump.
RE: BUG - Crash in digikam while reading metadata from a .MTS movie file - Added by Abhinav Badola over 7 years ago
Thanks for providing us with the bug report.
I will issue a bug on your behalf in the issues of Exiv2.
But currently , Exiv2 doesn't support .MTS movie format.
So I suppose the option to fetch metadata from it should have been disabled from digiKam.
I will register a bug and we will try our best to provide support for .MTS file in the future release of Exiv2.
It would be really great if you can provide us with some source file as well for testing. Or attach it with this thread and I will add its link to the issue as well.
Reported it in our bug tracking system - http://dev.exiv2.org/issues/956
RE: BUG - Crash in digikam while reading metadata from a .MTS movie file - Added by Jim Shipman over 7 years ago
Attached is an MTS file taken with a Panasonic DMC-ZS20 camera. Hope this helps.
RE: BUG - Crash in digikam while reading metadata from a .MTS movie file - Added by Robin Mills over 7 years ago
I've looked at this and it appears to be an unhandled exception in Digikam. I never like to "pass the buck", however it really doesn't seem to be a fault in Exiv2. You can persuade me otherwise of course. I'll always listen! I've put the evidence for my position in http://dev.exiv2.org/issues/961
RE: BUG - Crash in digikam while reading metadata from a .MTS movie file - Added by Gilles Caulier over 7 years ago
From the backtrace, we can see :
#1 0x00000033e6ee54a6 in Exiv2::ImageFactory::open(std::string const&) ()
#2 0x0000003a3a82956a in KExiv2Iface::KExiv2::load (this=0x7fff58389f20, filePath=...)
#3 0x0000003a3bb15cf9 in Digikam::DMetadata::load (this=0x7fff58389f20, filePath=...)
#1 is call from digiKam core;
#2 is call relevant in libkexiv2
#3 is call into Exiv2.
Look code from libkexiv2, and you will see that Exiv2 call is wrapped in C++ exception handler.