[digikam] [Bug 374591] Deleting image only removes the file and sets the status to hidden but does not delete the image from DB [patch]
https://bugs.kde.org/show_bug.cgi?id=374591 Kusi <k...@forum.titlis.org> changed: What|Removed |Added CC||k...@forum.titlis.org --- Comment #9 from Kusi <k...@forum.titlis.org> --- do you have by any chance a branch on a git repo to check out from? I use an external mysql server and could test it with that configuration When you delete a tagged photo and restart digikam, the tags are gone forever, right? It wouldn't be possible to restore the photo including tags from the trash. What about a retention period (e.g 30 days), or if the deletion date is not saved, just clean up once every month instead of every launch of digikam(just as an idea) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375569] New: Wrong tags in tooltips
https://bugs.kde.org/show_bug.cgi?id=375569 Bug ID: 375569 Summary: Wrong tags in tooltips Product: digikam Version: 5.4.0 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Database-Mysql Assignee: digikam-de...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- Created attachment 103649 --> https://bugs.kde.org/attachment.cgi?id=103649=edit tooltip when I hover over an image with many tags (including stacked tags), strange & incomplete tag names are indicated on the tooltip. Please see attached screenshot On the screenshot, I see - Leute/Flavia - Leute/Kusi - Flavia - Kusi - Maman - Leute/Timea The corresponding sql query select Tags.name, Tags.id as TagId, pid as TagParentId from Images join ImageTags on Images.id = ImageTags.imageid join Tags on ImageTags.tagid = Tags.id where Images.name = "20161224T184451-D610-DSC_9616.JPG" AND Images.album is not NULL; returns namenameTagId TagParentId 20161224T184451-D610-DSC_9616.JPG Kusi12 32 20161224T184451-D610-DSC_9616.JPG Celine Brun 101 401 20161224T184451-D610-DSC_9616.JPG Maman 103 102 20161224T184451-D610-DSC_9616.JPG Alessia 159 401 20161224T184451-D610-DSC_9616.JPG Color Label None435 428 20161224T184451-D610-DSC_9616.JPG Pick Label None 445 428 20161224T184451-D610-DSC_9616.JPG Flavia 1'064 32 20161224T184451-D610-DSC_9616.JPG Timea 1'210 32 and select * from Tags where id in (32,401,102, 100) returns id pid nameiconiconkde lft rgt 32 0 Leute [NULL] [NULL] 1'030 1'631 100 32 Nathalie Famille[NULL] [NULL] 1'469 1'576 102 100 Papa[NULL] [NULL] 1'570 1'571 401 100 Stephane[NULL] [NULL] 1'528 1'531 It looks like the tooltip query doesn't handle multilevel (stacked) tags correctly. The behavior in digikam is not consistent, this bug does not happen with all stacked tags. For the example above, my db looks correct, though. PS: for this query, are the lgt rgt columns needed? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376463] Improve keyboard assignment and useage of tags
https://bugs.kde.org/show_bug.cgi?id=376463 Kusi <k...@forum.titlis.org> changed: What|Removed |Added CC||k...@forum.titlis.org --- Comment #1 from Kusi <k...@forum.titlis.org> --- 1) pressing enter after having selected a tag will keep the the focus on the tag edit box. Pressing enter a second time moves the focus back to the main window and advances to the next image. See the commit message in https://cgit.kde.org/digikam.git/commit/?id=d13f94a8c5cf18a7c3c19c522fa484e5b7fb1bd9 Unfortunately, the sorting-by-history is broken since the DK5 port. 2) up/down is needed for navigation in the main view in my opinion 3) you can assign a single key shortcut to a tag via detour: you add a Ctrl+ shortcut via tag properties. The tag then appears in settings->shortcuts, where you can add a custom single letter shortcut. This is indeed more complicated than it should be -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372312] New: database upgrade v7 to v8 failed
https://bugs.kde.org/show_bug.cgi?id=372312 Bug ID: 372312 Summary: database upgrade v7 to v8 failed Product: digikam Version: 5.2.0 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Severity: critical Priority: NOR Component: Database-Mysql Assignee: digikam-de...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- I cannot update the database version v7 (DK 4.14) to v8 (DK 5.2). I'm using Opensuse Leap 42.2 with mariadb 10.0.27 $ digikam digikam.general: AlbumWatch use QFileSystemWatcher QFileSystemWatcher::removePaths: list is empty digikam.general: Database Parameters: Type: "QMYSQL" DB Core Name: "digikamdb" DB Thumbs Name: "digikamthumbs" DB Face Name: "digikamfaces" Connect Options: "" Host Name:"localhost" Host port:3306 Internal Server: false Internal Server Path: "" Internal Server Serv Cmd: "" Internal Server Init Cmd: "" Username: "digikamuser" Password: "X" digikam.dbengine: Loading SQL code from config file "/usr/share/digikam/database/dbconfig.xml" digikam.dbengine: Checking XML version ID => expected: 3 found: 3 digikam.coredb: Core database: running schema update digikam.coredb: Core database: have a structure version 7 digikam.coredb: Core database: makeUpdates 7 to 8 digikam.dbengine: Failure executing query: "" Error messages: "QMYSQL: Unable to execute query" "Specified key was too long; max key length is 767 bytes" 1071 2 Bound values: () digikam.dbengine: Error while executing DBAction [ "UpdateSchemaFromV7ToV8" ] Statement [ "ALTER TABLE Albums\nADD CONSTRAINT Albums_AlbumRoots FOREIGN KEY (albumRoot) REFERENCES AlbumRoots (id) ON DELETE CASCADE ON UPDATE CASCADE,\n ADD UNIQUE (albumRoot, relativePath(255)),\n ENGINE InnoDB;" ] digikam.coredb: Core database: schema update to V 8 failed! digikam.coredb: Core database: cannot process schema initialization -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372540] fileSize field in Images table limited to 4GB
https://bugs.kde.org/show_bug.cgi?id=372540 Kusi <k...@forum.titlis.org> changed: What|Removed |Added CC||k...@forum.titlis.org --- Comment #1 from Kusi <k...@forum.titlis.org> --- I can confirm that ALTER TABLE Images MODIFY COLUMN fileSize BIGINT NULL; does the trick. Nowadays, it's common to have movies larger than 2G -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372312] database upgrade v7 to v8 failed
https://bugs.kde.org/show_bug.cgi?id=372312 --- Comment #15 from Kusi <k...@forum.titlis.org> --- update procedure looks now more robust, thanks! It doesn't address yet the issue about having a too long key as reported initially and confirmed here: https://mail.kde.org/pipermail/digikam-users/2016-August/022581.html Does it make sense to have datatype LONGTEXT for column Albums.relativePath when you crop it anyways with UNIQUE (albumRoot, relativePath(255))? If your path is indeed longer than 255 (which is anyways not supported by many fs), you could miss the unique constraint. datatype varchar(255) would prevent that (and solves the initially reported issue for me) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 373003] New: wrongly calculated uniqueHash
https://bugs.kde.org/show_bug.cgi?id=373003 Bug ID: 373003 Summary: wrongly calculated uniqueHash Product: digikam Version: 5.2.0 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: Database-Mysql Assignee: digikam-de...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- A new uniqueHash algorithm was implemented a few years ago. See https://bugs.kde.org/show_bug.cgi?id=210353. The new algorithm in uniqueHashV2 was only made available for newly created databases. An already existing database was (and is till today) still using the old uniqueHash algorithm. My 10 years old digikam db still uses the old uniqueHash algo. The old algo worked fine till digikam 4.14. During the porting to DK 5, a bug was introduced for the old algo: In dimgloaded.cpp, the KDE4 command for the old v1 uniqueHash algo KMD5 md5; ... hash = md5.hexDigest(); was replaced in the KDE5 porting with ( still uniqueHash v1) QCryptographicHash md5(QCryptographicHash::Md5); ... hash = md5.result(); which is wrong. Instead, it should have been replaced by QCryptographicHash md5(QCryptographicHash::Md5); ... hash = md5.result().toHex(); See the migration document https://api.kde.org/frameworks/kdelibs4support/html/classKMD5.html#a49b31c3e5eb180fa8be8c8f576266221 As a consequence, a database created before 2010 calculates different uniqueHash values in DK5 compared to DK4. Furthermore, UTF8 cannot be used since some of the now calculated uniqueHash values are not valid UTF8 characters, the SQL server erorrs with "REPLACE INTO Images ( album, name, status, category, modificationDate, fileSize, uniqueHash ) VALUES (?,?,?,?,?,?,?);" Error messages: "QMYSQL3: Unable to execute statement" "Incorrect string value: '\\xF1\\x9E\\xA6\\x87' for column 'uniqueHash' at row 1" 1366 2 Bound values: (QVariant(int, 118053), QVariant(QString, "P4240656.JPG"), QVariant(int, 1), QVariant(int, 1), QVariant(QString, "2016-10-30T19:16:42"), QVariant(qlonglong, 6951936), QVariant(QString, "m�7�\U0005E987")) There is uniqueHashVersion in the System table, but the value "2" in DK4 and DK5 return different hash values. The fix would be easy, just add the missing ".toHex()". However, all images added in DK5 already contain the invalid hash values. They need legacy treatment. The most clean solution is to get rid of hashValue version 1 and recalculate all hash values in the next DK release As as sidenote: hashValueV2 is not affected by this bug. This means a db created after 2010 is not affected -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 373003] wrongly calculated uniqueHash
https://bugs.kde.org/show_bug.cgi?id=373003 --- Comment #4 from Kusi <k...@forum.titlis.org> --- Maik, where exactly can I update to v2? I don't see any option in the settings of DK5.2 Kusi PS: thanks for the fast fix! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372540] fileSize field in Images table limited to 4GB
https://bugs.kde.org/show_bug.cgi?id=372540 --- Comment #3 from Kusi <k...@forum.titlis.org> --- what about those who already have updated to schema v8? They're not getting this fix, do they? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 373003] wrongly calculated uniqueHash
https://bugs.kde.org/show_bug.cgi?id=373003 Kusi <k...@forum.titlis.org> changed: What|Removed |Added CC||k...@forum.titlis.org -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 373003] wrongly calculated uniqueHash
https://bugs.kde.org/show_bug.cgi?id=373003 --- Comment #6 from Kusi <k...@forum.titlis.org> --- thanks, that solved my problem! Just for reference, before your fix, the "update hash" GUI did not work. For me, the issue is solved, but I'm sure there are thousands of installations out there with invalid uniqueHash values. I strongly recommend to force a uniqueHash update to v2 in DK 5.4. Furthermore, most of the SQL errors are not sent to the GUI, they are only visible on the command line. The user just don't see images or other weird behavior and has no clue why. It would be really helpful to be more strict and let the user know in case of errors. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372312] database upgrade v7 to v8 failed
https://bugs.kde.org/show_bug.cgi?id=372312 --- Comment #2 from Kusi <k...@forum.titlis.org> --- The sql command in question ALTER TABLE Albums ADD CONSTRAINT Albums_AlbumRoots FOREIGN KEY (albumRoot) REFERENCES AlbumRoots (id) ON DELETE CASCADE ON UPDATE CASCADE, ADD UNIQUE (albumRoot, relativePath(250)), ENGINE InnoDB; runs fine without specifying the engine, that is without "ENGINE InnoDB". On my db, according to SHOW TABLE STATUS FROM digikamdb; the "Albums" table is of engine type MyISAM, not InnoDB. Is that new db engine format wanted? Is it ok to change the engine of an existing table? It looks like I have inconsistent engine types over all my tables (mixture between MyISAM and InnoDB). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372312] database upgrade v7 to v8 failed
https://bugs.kde.org/show_bug.cgi?id=372312 --- Comment #3 from Kusi <k...@forum.titlis.org> --- I deleted all but one row from the Albums table and tried to convert the engine. Whats going on here? MariaDB [digikamdb]> select * from Albums; +--+---+--++-++--+ | id | albumRoot | relativePath | date | caption | collection | icon | +--+---+--++-++--+ | 7847 | 7 | /2012| 2012-01-22 | NULL| NULL | NULL | +--+---+--++-++--+ 1 row in set (0.00 sec) MariaDB [digikamdb]> ALTER TABLE Albums ENGINE = InnoDB; ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372312] database upgrade v7 to v8 failed
https://bugs.kde.org/show_bug.cgi?id=372312 Kusi <k...@forum.titlis.org> changed: What|Removed |Added CC||k...@forum.titlis.org -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372312] database upgrade v7 to v8 failed
https://bugs.kde.org/show_bug.cgi?id=372312 --- Comment #10 from Kusi <k...@forum.titlis.org> --- Created attachment 102342 --> https://bugs.kde.org/attachment.cgi?id=102342=edit my dbconfig.xml -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372312] database upgrade v7 to v8 failed
https://bugs.kde.org/show_bug.cgi?id=372312 --- Comment #12 from Kusi <k...@forum.titlis.org> --- I've added my dbconfig.xml with which I was successful. In addition to the modified dbconfig.xml, the following changes to the db were needed - Since I have many Umlaute, accents etc in my db, I first had to fix the encoding. You have the utf encoding in your dbconfig.xml, but for unknown reasons I had to do that explicitly first before running DK. I assume it comes with the ENGINE change. ALTER TABLE digikamdb.Albums DEFAULT CHARSET=utf8; ALTER TABLE digikamdb.Images DEFAULT CHARSET=utf8; - During creation of the Albums_AlbumRoots constraint, you limit the column "relativePath" to 255 chars, but that didn't do the trick (neither did it for other users on digikam-user mailing list, as you remember). I don't know why (again I assume its because of the ENGINE change to InnoDB), though. I had to change the datatype from LONGTEXT to VARCHAR(255) in the ALTER command of the v7 to v8 upgrade statement For me, the issue is resolved, but I don't think the solution to my issues is applicable for everybody. If needed, you can have my db to experiment (in an anonymized form), let me know. Am I the only one with plenty of FK constraint violations? If needed by someone, I have a (risky) script which resolves them. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372312] database upgrade v7 to v8 failed
https://bugs.kde.org/show_bug.cgi?id=372312 --- Comment #8 from Kusi <k...@forum.titlis.org> --- the new dbconfig.xml brings me quite a bit further, but no success yet. Unfortunately, I've got a 10 years old sql db which probably degenerated a bit. I need to resolve all foreign key violations (from which I have a bunch) myself. Hopefully that doesn't happen anymore with the added constraints. Thanks for that, btw! As for your new xml: The following sequence cannot work, can it? ALTER TABLE Albums DROP FOREIGN KEY Albums_Images; ALTER TABLE Albums ADD CONSTRAINT Albums_Images FOREIGN KEY (icon) REFERENCES Images (id) ON DELETE SET NULL ON UPDATE CASCADE; You drop Albums_Images which didn't exist on a DK 4.14, right? At least for me, I need DROP FOREIGN KEY IF EXISTS Albums_Images; -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372312] database upgrade v7 to v8 failed
https://bugs.kde.org/show_bug.cgi?id=372312 --- Comment #1 from Kusi <k...@forum.titlis.org> --- As mentioned on digikam-users mailing list on 2016-08-29, I tried the alternative dbconfig.xml provided by Maik. No success. I've also tried innodb-large-prefix=true in my global my.cfg. No success either. How can I help to fix the issue? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 373247] No chronological ordering of tags anymroe
https://bugs.kde.org/show_bug.cgi?id=373247 --- Comment #2 from Kusi <k...@forum.titlis.org> --- yes, still broken in the current AppImage The functionality was removed during the port from KCompletion to QCompleter in commit 658d26af. I guess this happened just by accident? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 373247] New: No chronological ordering of tags anymroe
https://bugs.kde.org/show_bug.cgi?id=373247 Bug ID: 373247 Summary: No chronological ordering of tags anymroe Product: digikam Version: 5.2.0 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Tags Assignee: digikam-de...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- Tags in the drop down menu (AddTagsLineEdit) to assign a new tag aren't chronologically ordered anymore as described here https://git.reviewboard.kde.org/r/108382/ and committed here: d13f94a8c5cf18a7c3c19c522fa484e5b7fb1bd9 Seems like the chronological ordering was lost during the DK5 port -- You are receiving this mail because: You are watching all bug changes.
[kipiplugins] [Bug 374242] exported photos to Gphoto are rotated
https://bugs.kde.org/show_bug.cgi?id=374242 Kusi <k...@forum.titlis.org> changed: What|Removed |Added CC||k...@forum.titlis.org --- Comment #3 from Kusi <k...@forum.titlis.org> --- I can confirm the issue: The "Export to Google Photos" do not respect the orientation field of the photo. Digikam correctly interprets the EXIF orientation flag, while the export plugin doesn't. This used to work in digikam 4.xx -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 296580] Allow to choose photo date-time stamp from digiKam main window
https://bugs.kde.org/show_bug.cgi?id=296580 Kusi <k...@forum.titlis.org> changed: What|Removed |Added CC||k...@forum.titlis.org --- Comment #14 from Kusi <k...@forum.titlis.org> --- When you're in the batch queue manager, please allow to drag & drop from the "Queues" window to the "determine difference from clock photo" button. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 296580] Allow to choose photo date-time stamp from digiKam main window
https://bugs.kde.org/show_bug.cgi?id=296580 --- Comment #17 from Kusi <k...@forum.titlis.org> --- Issue fixed with commit https://cgit.kde.org/digikam.git/commit/?id=72c97cef18b260d2143261b72373e7ba53ba3dfb You can drag a photo onto the "determine difference" button from anywhere -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 296580] Allow to choose photo date-time stamp from digiKam main window
https://bugs.kde.org/show_bug.cgi?id=296580 Kusi <k...@forum.titlis.org> changed: What|Removed |Added Latest Commit||72c97cef18b260d2143261b7237 ||3e7ba53ba3dfb Version Fixed In||5.4.0 Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #16 from Kusi <k...@forum.titlis.org> --- Issue fixed with commit https://cgit.kde.org/digikam.git/commit/?id=72c97cef18b260d2143261b72373e7ba53ba3dfb You can drag a photo onto the "determine difference" button from anywhere -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 296580] Allow to choose photo date-time stamp from digiKam main window
https://bugs.kde.org/show_bug.cgi?id=296580 --- Comment #15 from Kusi <k...@forum.titlis.org> --- Patch under review https://git.reviewboard.kde.org/r/129755/ -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374560] New: Lens Model and Make are not displayed anymore
https://bugs.kde.org/show_bug.cgi?id=374560 Bug ID: 374560 Summary: Lens Model and Make are not displayed anymore Product: digikam Version: 5.2.0 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Metadata Assignee: digikam-de...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- Created attachment 103199 --> https://bugs.kde.org/attachment.cgi?id=103199=edit digikam-no-make-and-model Camera model and make are not displayed anymore, see attached picture the command line tool exiv2 for this picture returns Camera make : Panasonic Camera model: DMC-GH4 it looks like digikam parses the wrong tags since commandline exiv2 returns the correct values -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374560] Lens Model and Make are not displayed anymore
https://bugs.kde.org/show_bug.cgi?id=374560 --- Comment #1 from Kusi <k...@forum.titlis.org> --- same behavior for 3 different cameras -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372164] Camera related photograph properties are unavailable (erroneously)
https://bugs.kde.org/show_bug.cgi?id=372164 Kusi <k...@forum.titlis.org> changed: What|Removed |Added CC||k...@forum.titlis.org --- Comment #11 from Kusi <k...@forum.titlis.org> --- *** Bug 374560 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374560] Lens Model and Make are not displayed anymore
https://bugs.kde.org/show_bug.cgi?id=374560 Kusi <k...@forum.titlis.org> changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Kusi <k...@forum.titlis.org> --- *** This bug has been marked as a duplicate of bug 372164 *** -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374560] Lens Model and Make are not displayed anymore
https://bugs.kde.org/show_bug.cgi?id=374560 --- Comment #4 from Kusi <k...@forum.titlis.org> --- indeed, works in current master. somehow I didn't find the bug in bko. thanks for the hint! -- You are receiving this mail because: You are watching all bug changes.
[kipiplugins] [Bug 374753] no refresh during google photos import
https://bugs.kde.org/show_bug.cgi?id=374753 Kusi <k...@forum.titlis.org> changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Kusi <k...@forum.titlis.org> --- fixed in 374293 *** This bug has been marked as a duplicate of bug 374293 *** -- You are receiving this mail because: You are watching all bug changes.
[kipiplugins] [Bug 374293] Google albums reload button still display albums which have been removed from google photos
https://bugs.kde.org/show_bug.cgi?id=374293 Kusi <k...@forum.titlis.org> changed: What|Removed |Added CC||k...@forum.titlis.org --- Comment #2 from Kusi <k...@forum.titlis.org> --- *** Bug 374753 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kipiplugins] [Bug 374753] no refresh during google photos import
https://bugs.kde.org/show_bug.cgi?id=374753 Kusi <k...@forum.titlis.org> changed: What|Removed |Added Version|5.5.0 |5.2.0 --- Comment #2 from Kusi <k...@forum.titlis.org> --- I tried digikam master and wrongly assumed I was also using kipi master. But no, I was using kipi-plugins 5.2 provided with current Opensuse Leap. I'll correct it. -- You are receiving this mail because: You are watching all bug changes.
[kipiplugins] [Bug 374753] New: no refresh during google photos import
https://bugs.kde.org/show_bug.cgi?id=374753 Bug ID: 374753 Summary: no refresh during google photos import Product: kipiplugins Version: 5.5.0 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: GoogleServices Assignee: kde-imag...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- After opening the Google Photos import dialog in Digikam, there's no way to reread again new albums from Google Photos. Neither the refresh button nor closing/reopening the import dialog will update the albums. If you create a new album on photos.google.com while digikam is open, you need to restart digikam in order to make the album visible -- You are receiving this mail because: You are watching all bug changes.
[kipiplugins] [Bug 374753] no refresh during google photos import
https://bugs.kde.org/show_bug.cgi?id=374753 Kusi <k...@forum.titlis.org> changed: What|Removed |Added CC||k...@forum.titlis.org -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 373605] Failed to update database schema from version 7 to version 8
https://bugs.kde.org/show_bug.cgi?id=373605 --- Comment #5 from Kusi <k...@forum.titlis.org> --- Created attachment 102868 --> https://bugs.kde.org/attachment.cgi?id=102868=edit sql script to detect FK violations -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375569] Wrong tags in tooltips
https://bugs.kde.org/show_bug.cgi?id=375569 --- Comment #5 from Kusi <k...@forum.titlis.org> --- Maik, thanks for fixing this issue! I've written a tool to recreate the lft/rgt columns. https://github.com/githubkusi/digikam_rebuild_mptt Updating the lft/rgt columns is not too difficult, you can use my python reference implementation as a template. Your idea to copy the tags table to a temp table and back one by one to the tags table works I guess, but I don't think it's easier compared to update only lft/rgt in the main tags table. best, Kusi -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 386606] New: tags search is broken after moving tags (invalid lft/rgt columns)
https://bugs.kde.org/show_bug.cgi?id=386606 Bug ID: 386606 Summary: tags search is broken after moving tags (invalid lft/rgt columns) Product: digikam Version: 5.6.0 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Database-Mysql Assignee: digikam-bugs-n...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- The modified preorder tree traversal fields Tags.lft & Tags.rgt become invalid when you move a tag in the tags hierarchy. Example: assume the 4 tags Monkey, Lifesaver, blue, red with the following hierarchy - Monkey - Lifesaver -> blue - Lifesaver -> red When you select the tag "Lifesaver", all pictures with the tags blue and red show up. Now you move tag "blue" to the tag root, such that you have the following hierarchy - Monkey - blue - Lifesaver -> red When you select the tag "Lifesaver", also the picture with tag "blue" is selected, which is a bug The example above is used in the script digikam_with_sample_db from https://github.com/githubkusi/digikam_controlled_environment. The repo contains some handy tools for database investigations in a controlled, repeatable environment The reason for the bug are invalid columns Tags.lft/rgt. These columns are not set correctly when moving tags (maybe there are other problematic situations). looking at current master, I see that there is a move_tagstree for sqlite, but not for mysql in the file dbconfig.xml.cmake.in. This is probably the issue. Anyways, adding mysql support for moving tags wouldn't heal an already broken mysql db. I assume that basically everybody using a mysql backend for a few years has a broken tags search functionality by now, which can only be solved by recalculating the lft/rgt fields from scratch. I've written a script which recalculates proper traversal tree columns and works with the example above https://github.com/githubkusi/digikam_rebuild_mptt The code is not yet bullet-proof (no db locking during the fix, no sanity checks), but something like this should go into the db maintenance tools. The issue was already reported here: https://bugs.kde.org/show_bug.cgi?id=338050 which was fixed in 5.1. However, the issue is still present in 5.6 for me. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 386606] tags search is broken after moving tags (invalid lft/rgt columns)
https://bugs.kde.org/show_bug.cgi?id=386606 Kusi <k...@forum.titlis.org> changed: What|Removed |Added CC||k...@forum.titlis.org -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 386606] tags search is broken after moving tags (invalid lft/rgt columns)
https://bugs.kde.org/show_bug.cgi?id=386606 --- Comment #1 from Kusi <k...@forum.titlis.org> --- related with https://bugs.kde.org/show_bug.cgi?id=383326 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 394291] New: cannot upgrade mysql db from v7 to v9
https://bugs.kde.org/show_bug.cgi?id=394291 Bug ID: 394291 Summary: cannot upgrade mysql db from v7 to v9 Product: digikam Version: 5.9.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: Database-Mysql Assignee: digikam-bugs-n...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- When I run Digikam 5.9 the first time, the mysql db is upgraded to v9. The upgrade failed with the error message: Error messages: "QMYSQL: Unable to execute query" "BLOB/TEXT column 'name' used in key specification without a key length" 1170 2 Bound values: () digikam.dbengine: Error while executing DBAction [ "UpdateSchemaFromV7ToV9" ] Statement [ "ALTER TABLE Images MODIFY COLUMN name LONGTEXT CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;" ] digikam.coredb: Core database: schema update to V 9 failed! Deleting the guilty index solved the issue for me ALTER TABLE Images DROP INDEX image_name_index; Is that a problem in general or where does my index coming from? Do I need to recreate it manually? PS: I still cannot convert to v9, but these are other issues, to be investigated -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 394291] cannot upgrade mysql db from v7 to v9
https://bugs.kde.org/show_bug.cgi?id=394291 --- Comment #2 from Kusi <k...@forum.titlis.org> --- my db is over 12 years old I guess. Looking at the mysql dump, there's indeed alot of garbage (many unneeded constraints and indexes) compared to how a new db looks like. Digikam with db v9 is now running, but I'll probably do the migration to a new db anyways. Just one question: do the ids for the images change during migration? I've added another table (for another project) whos foreign key is images.id. Therefore I currently rely on Images.id not being changed -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 108873] digiKam web interface
https://bugs.kde.org/show_bug.cgi?id=108873 Kusi <k...@forum.titlis.org> changed: What|Removed |Added CC||k...@forum.titlis.org --- Comment #2 from Kusi <k...@forum.titlis.org> --- This feature is wanted more than ever! It is for sure too much work to start from scratch, but a (upload only) synchronization to a popular platform such as Flickr/Google/SmugMug etc... should be feasable in a reasonable amount of time. What's missing from the current KIPI Web Export plugins - Automatization: upload in the background on image/metadata changes - Automatically mirror the folder structure of Digikam online - Ability to choose which files are automatically synchronized (e.g introduce a Publish flag as proposed 13 years ago, or having a minimal amount of stars) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 394291] cannot upgrade mysql db from v7 to v9
https://bugs.kde.org/show_bug.cgi?id=394291 Kusi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Kusi --- workaround in comment #1 is good enough -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 394291] cannot upgrade mysql db from v7 to v9
https://bugs.kde.org/show_bug.cgi?id=394291 --- Comment #5 from Kusi --- I solved the issue by export/import of the database. That is probably good enough also for other users with this issue. I'm closing this bugreport -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 396679] New: Open Album in Terminal
https://bugs.kde.org/show_bug.cgi?id=396679 Bug ID: 396679 Summary: Open Album in Terminal Product: digikam Version: 5.9.0 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: Albums-MainView Assignee: digikam-bugs-n...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- A right-click on an album should offer the option to open the album in a terminal, the same way as it offers to open the album in a file manager. Some old discussions in https://bugs.kde.org/show_bug.cgi?id=158507 According to https://bugs.kde.org/show_bug.cgi?id=322117, this was once available? Was this functionality removed? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 396679] Open Album in Terminal
https://bugs.kde.org/show_bug.cgi?id=396679 Kusi changed: What|Removed |Added CC||k...@forum.titlis.org -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 396679] Open Album in Terminal
https://bugs.kde.org/show_bug.cgi?id=396679 --- Comment #2 from Kusi --- Is is a pity that the functionality of digikam has to suffer due to portability. would you accept a patch with conditional compiler directives such that KIO code is only compiled if the target is KDE? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 396679] Open Album in Terminal
https://bugs.kde.org/show_bug.cgi?id=396679
--- Comment #4 from Kusi ---
I investigated a bit the problem of launching a terminal cross platform
The following code snippet allows to handle the case of KDE, but it should be
easy to extend it for various desktop environments. I just guessed the values
for GNOME, I didn't test for GNOME
QByteArray env = qgetenv("XDG_CURRENT_DESKTOP");
QString desktopEnvironment = QString::fromLocal8Bit(env.data());
QMap terminals;
terminals["KDE"] = "konsole";
terminals["GNOME"] = "gnome-shell";
terminals["WINDOWS"] = "cmd.exe";
if (terminals.contains(desktopEnvironment))
{
QProcess *process = new QProcess(this);
QString terminal = terminals[desktopEnvironment];
QString folder = "/share/pictures";
process->setWorkingDirectory(folder);
process->start(terminal);
}
While getting the current platform (linux/win/osx) seems straight forward with
either QSysInfo or https://wiki.qt.io/Get_OS_name, it is tricky to get the
desktop environment, but it is still feasible w/o too much hassle:
https://stackoverflow.com/questions/47022134/how-can-i-find-out-at-runtime-which-desktop-environment-that-a-qt-application
Remember, if the terminal is not available, the option is just disabled. It
doesn't have to exist for every exotic desktop environment
what do you think?
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 382582] Video stutters when played
https://bugs.kde.org/show_bug.cgi?id=382582 Kusi changed: What|Removed |Added CC||k...@forum.titlis.org --- Comment #2 from Kusi --- since the move from gstreamer to QtAV, all videos (iPhone mov, mp4, Panasonic GH4) stutter. The internal viewer is unusable for me. Using the external player works without issues. DK 6.1 / Linux -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 409038] erroneous extraction of date metadata for videos
https://bugs.kde.org/show_bug.cgi?id=409038 --- Comment #4 from Kusi --- (In reply to caulier.gilles from comment #1) > if Iphone photo and video do not use the same date zone on the same device, > it's clearly an Apple bug (:=)))... > > And of course, you cannot report this problem to the big Apple. > > > Gilles Caulier yeah, thanks Apple! :/ -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 409038] erroneous extraction of date metadata for videos
https://bugs.kde.org/show_bug.cgi?id=409038 --- Comment #3 from Kusi --- (In reply to Maik Qualmann from comment #2) > Exiftool also finds 09:09:41 as the creation date. There is an additional > entry in the video called "com.apple.quicktime.creationdate", which has the > timezone addition. We can add this as a special case. > > Maik That would be great! How did you check the special tag "comcreationdate"? For reference: Create Date in UTC, Creation Date in local time zone $ exiftool IMG_9360-iPhone.MOV | grep Creat Create Date : 2019:06:22 09:09:41 Creation Date : 2019:06:22 11:09:41+02:00 Create Date and Creation Date in local time zone $ exiftool -api QuickTimeUTC IMG_9360-iPhone.MOV | grep Creat Create Date : 2019:06:22 11:09:41+02:00 Creation Date : 2019:06:22 11:09:41+02:00 Source: https://askubuntu.com/questions/989646/exif-tool-and-video-files-which-are-saved-with-utc-timestamps -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 409038] erroneous extraction of date metadata for videos
https://bugs.kde.org/show_bug.cgi?id=409038 --- Comment #6 from Kusi --- Fixing the issue 1h42 after reporting, that's a fantastic job! Thanks alot Maik! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 382582] Video stutters when played
https://bugs.kde.org/show_bug.cgi?id=382582 --- Comment #4 from Kusi --- I use the non-free ffmpeg from OpenSuse (http://packman.links2linux.de/package/ffmpeg-3) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 382582] Video stutters when played
https://bugs.kde.org/show_bug.cgi?id=382582 --- Comment #7 from Kusi --- Maik: do you use the package ffmpeg-3 or ffmpeg-4? Maik, Gilles: I have an Intel Core i7 6700 with Intel HD Graphics 530. What GPU do you have? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 409038] New: erroneous extraction of date metadata for videos
https://bugs.kde.org/show_bug.cgi?id=409038 Bug ID: 409038 Summary: erroneous extraction of date metadata for videos Product: digikam Version: 6.1.0 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: major Priority: NOR Component: Metadata-Date Assignee: digikam-bugs-n...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- Extracting the video date does not work correctly for an iPhone. The problem is the interpretation of the timezone: exif tag:| "Create Date" | "Creation Date" -|-|- Panasonic Lumix GH4: | local timezone | N/A iPhone5 SE | UTC | local timezone Apparently, Digikam interpretes the exif "Create Date", which is correct for Panasonic, but not for my iPhone, see image digikam-rename.png. My local timezone is UTC+2. Images are available here: https://drive.google.com/drive/folders/1yHVOhvZMNWn2hGXgVPwoU0_841izpkPu Unfortunately, there is no good solution to the problem since often the timezone is not reflected in the metadata. With DK 6.1, it is still not possible to use the correct video timestamp from within DK, but only via exiftool. Maybe a user-configurable database which maps the correct exif field to the date used in DK based on the used video hardware? How do other tools handle the problem? Literature: https://sno.phy.queensu.ca/~phil/exiftool/TagNames/QuickTime.html PS: for photos taken with iPhone, the "Create Date" or "Date/Time Original" seems to be the local time zone. This issue only appears with videos -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 382582] Video stutters when played
https://bugs.kde.org/show_bug.cgi?id=382582 --- Comment #10 from Kusi --- maybe I need to buy a 10 years old Athlon too :) None of you guys use the Intel GPU. I checked QMLPlayer from the QtAV-players package, and it stutters the same way as in DK. So it's not a DK issue. vlc/mpv play without issues on my machine -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 410912] New: Improve "Move to album" for keyboard use
https://bugs.kde.org/show_bug.cgi?id=410912 Bug ID: 410912 Summary: Improve "Move to album" for keyboard use Product: digikam Version: 6.2.0 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Usability-Ergonomy Assignee: digikam-bugs-n...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- SUMMARY When the "Move to album" dialog is used by keyboard, there are some smaller usability issues When launching the dialog, the ok button is focused, and the most recently chosen album is (passively) selected. When hitting the enter key, the move to the passively selected folder is performed. However, the focused ok button does not accept any other keyboard inputs. A better solution is to initially focus on the search edit box. Apparently, when the dialog is launched, the search box is empty and enter is pressed, the move is still executed to the passively selected folder, which is good. When the search edit box is selected, and you search a target folder, and you select a folder by move down arrow, and launch the move by pressing enter, the previously chosen folder is ignored, since apparently the selection of the album tree view has precedence. This is not what the user wanted: If the folder selection happens via search edit box, this selection has to be respected Ideally, when you type half of the album name and the desired album appears on the first place on the drop down, you can press enter and the photo is moved the the first album on the drop down. But I believe that's not possible anymore since the move from KCompleter to QCompleter. Furthermore, if the empty search edit box is focused (what should be the initial state) and the up/down key is hit, the album tree view should be focused and accept the up/down movement. This rule only applies if the search edit box is empty. STEPS TO REPRODUCE (This only applies if "Move to album" is indeed only available via keyboard shortcut, I didn't find a menu entry for this action?) 1. Settings->Configure Shortcuts 2. Move to Album... -> Shortcut M -> ok 3. Select a photo 4. press M OBSERVED RESULT "ok" is focused EXPECTED RESULT - search edit box is focused - respect folder chosen via typed text in the search edit box -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 410912] Improve "Move to album" for keyboard use
https://bugs.kde.org/show_bug.cgi?id=410912 --- Comment #2 from Kusi --- Thanks Maik for the super fast fix! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 412343] New: Allow to apply the previously assigned tag to a new image
https://bugs.kde.org/show_bug.cgi?id=412343 Bug ID: 412343 Summary: Allow to apply the previously assigned tag to a new image Product: digikam Version: 6.3.0 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Tags-Keywords Assignee: digikam-bugs-n...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- Please add a keyboard shortcut "Assign previously assigned tag" (or just "Assign previous tag") Usecase: You want to assign the tag to the images 1,2 and 4 with the keyboard - Assign to image 1 and proceed to the next image. is now saved as - Press shortcut to apply to image 2 and automatically proceed to next image 3 - Proceed to the next image 4 - Press shortcut to apply to image 3 and automatically proceed to next image Assume you assigned the following keyboard shortcuts Assign tag: "T" Next image: "J" (inspired by vim) Assign last assigned tag: "." (inspired by vim) For the described usecase above, you simply press <.><.> and you're done When I tag images, I always have the Preview-View, which doesn't allow me to select a group of images with a mouse click, therefore the keyboard is the only way to efficiently assign the same tag to several pictures. I could select them in the Thumbnail view, but this is often too small for me to decide which tags to assign. About the wish to automatically proceed to the next image after assigning the last tag: if the user wants to do further tagging of the same image, he is most likely not interested anymore in the last used tag for the next image. The main purpose of is to apply one (and only one) particular tag to many images, hence automatically proceeding to the next image makes sense to me. What needs to be done - save the last assigned tag somewhere - add a function AssignLastTagAndProceed() - New KAction for signalAssignLastTagAndProceed() in DigikamApp::setupAccelerators() What do you think about this wish? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 412343] Allow to apply the previously assigned tag to a new image
https://bugs.kde.org/show_bug.cgi?id=412343 Kusi changed: What|Removed |Added CC||k...@forum.titlis.org -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 413289] New: Baloo crashes at startup
https://bugs.kde.org/show_bug.cgi?id=413289 Bug ID: 413289 Summary: Baloo crashes at startup Product: frameworks-baloo Version: 5.55.0 Platform: openSUSE RPMs OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: Baloo File Daemon Assignee: stefan.bru...@rwth-aachen.de Reporter: k...@forum.titlis.org Target Milestone: --- Application: baloo_file (5.55.0) Qt Version: 5.9.7 Frameworks Version: 5.55.0 Operating System: Linux 4.12.14-lp151.28.20-default x86_64 Distribution: "openSUSE Leap 15.1" -- Information about the crash: No user interaction, straight crash after startup. Everytime. The crash can be reproduced every time. -- Backtrace: Application: Baloo File Indexing Daemon (baloo_file), signal: Aborted Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7eff95e50900 (LWP 2458))] Thread 3 (Thread 0x7eff8a73c700 (LWP 2647)): [KCrash Handler] #6 0x7eff937b7160 in raise () from /lib64/libc.so.6 #7 0x7eff937b8741 in abort () from /lib64/libc.so.6 #8 0x7eff9124fa82 in mdb_assert_fail (env=0x55727065a750, expr_txt=expr_txt@entry=0x7eff9125150f "rc == 0", func=func@entry=0x7eff91251e78 <__func__.6935> "mdb_page_dirty", line=line@entry=2071, file=0x7eff912514f0 "mdb.c") at mdb.c:1487 #9 0x7eff91244d85 in mdb_page_dirty (txn=0x55727065bbb0, mp=) at mdb.c:2071 #10 0x7eff91245f6a in mdb_page_alloc (num=num@entry=1, mp=mp@entry=0x7eff8a73b008, mc=) at mdb.c:2252 #11 0x7eff912461d9 in mdb_page_touch (mc=mc@entry=0x7eff8a73b540) at mdb.c:2370 #12 0x7eff91247cd4 in mdb_cursor_touch (mc=mc@entry=0x7eff8a73b540) at mdb.c:6304 #13 0x7eff9124ae6e in mdb_cursor_put (mc=0x7eff8a73b540, key=0x7eff8a73b910, data=0x7eff8a73b920, flags=) at mdb.c:6438 #14 0x7eff9124dafb in mdb_put (txn=0x55727065bbb0, dbi=3, key=key@entry=0x7eff8a73b910, data=data@entry=0x7eff8a73b920, flags=flags@entry=0) at mdb.c:8796 #15 0x7eff94e54bbc in Baloo::PositionDB::put (this=this@entry=0x7eff8a73ba10, term=..., list=...) at /usr/src/debug/baloo5-5.55.0-lp151.2.2.x86_64/src/engine/positiondb.cpp:79 #16 0x7eff94e628d9 in Baloo::WriteTransaction::commit (this=0x557270892040) at /usr/src/debug/baloo5-5.55.0-lp151.2.2.x86_64/src/engine/writetransaction.cpp:312 #17 0x7eff94e5bbd2 in Baloo::Transaction::commit (this=this@entry=0x7eff8a73bb20) at /usr/src/debug/baloo5-5.55.0-lp151.2.2.x86_64/src/engine/transaction.cpp:269 #18 0x55726fae3fc7 in Baloo::UnindexedFileIndexer::run (this=0x5572709349a0) at /usr/src/debug/baloo5-5.55.0-lp151.2.2.x86_64/src/file/unindexedfileindexer.cpp:76 #19 0x7eff942b1e22 in QThreadPoolThread::run (this=0x557270893f10) at thread/qthreadpool.cpp:99 #20 0x7eff942b4ced in QThreadPrivate::start (arg=0x557270893f10) at thread/qthread_unix.cpp:368 #21 0x7eff916ae569 in start_thread () from /lib64/libpthread.so.0 #22 0x7eff938799ef in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7eff8b24f700 (LWP 2469)): #0 0x7eff9386f19b in poll () from /lib64/libc.so.6 #1 0x7eff8fc2a1a9 in ?? () from /usr/lib64/libglib-2.0.so.0 #2 0x7eff8fc2a2bc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #3 0x7eff944ec96b in QEventDispatcherGlib::processEvents (this=0x7eff84000b10, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #4 0x7eff9449190a in QEventLoop::exec (this=this@entry=0x7eff8b24ec80, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #5 0x7eff942afdaa in QThread::exec (this=) at thread/qthread.cpp:515 #6 0x7eff950829e5 in ?? () from /usr/lib64/libQt5DBus.so.5 #7 0x7eff942b4ced in QThreadPrivate::start (arg=0x7eff952f5d60) at thread/qthread_unix.cpp:368 #8 0x7eff916ae569 in start_thread () from /lib64/libpthread.so.0 #9 0x7eff938799ef in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7eff95e50900 (LWP 2458)): #0 0x7eff916b0cda in __pthread_mutex_lock_full () from /lib64/libpthread.so.0 #1 0x7eff9124432f in mdb_txn_renew0 (txn=txn@entry=0x55727065bbb0) at mdb.c:2698 #2 0x7eff912455d4 in mdb_txn_begin (env=0x55727065a750, parent=parent@entry=0x0, flags=flags@entry=0, ret=ret@entry=0x7ffd7e84c838) at mdb.c:2856 #3 0x7eff94e5b48b in Baloo::Transaction::Transaction (this=0x7ffd7e84c830, db=..., type=Baloo::Transaction::ReadWrite) at /usr/src/debug/baloo5-5.55.0-lp151.2.2.x86_64/src/engine/transaction.cpp:53 #4 0x55726faf2305 in Baloo::MetadataMover::moveFileMetadata (this=0x55727064a5b0, from=..., to=...) at /usr/src/debug/baloo5-5.55.0-lp151.2.2.x86_64/src/file/metadatamover.cpp:75 #5 0x55726faed77f in Baloo::FileWatch::slotFileMoved (this=0x7ffd7e84d0d0, urlFrom=..., urlTo=...) at /usr/src/debug/baloo5-5.55.0-lp151.2.2.x86_64/src/file/filewatch.cpp:110 #6 0x7eff944c264f in QtPrivate::QSlotObjectBase::call (a=0x7ffd7e84cb00, r=0x7ffd7e84d0d0,
[krusader] [Bug 414332] New: Krusader crashes while moving files
https://bugs.kde.org/show_bug.cgi?id=414332 Bug ID: 414332 Summary: Krusader crashes while moving files Product: krusader Version: unspecified Platform: openSUSE RPMs OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: krusader-bugs-n...@kde.org Reporter: k...@forum.titlis.org CC: krusader-bugs-n...@kde.org Target Milestone: --- Application: krusader (2.7.2 "Peace of Mind") Qt Version: 5.9.7 Frameworks Version: 5.55.0 Operating System: Linux 4.12.14-lp151.28.20-default x86_64 Distribution: "openSUSE Leap 15.1" -- Information about the crash: - What I was doing when the application crashed: Krusader crashes while selecting many (~20) files, and move them by means of F6. Also crashes by selecting many files and deleting them The crash can be reproduced every time. -- Backtrace: Application: Krusader (krusader), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7efdb14ddd80 (LWP 7510))] Thread 4 (Thread 0x7efd92176700 (LWP 7513)): #0 0x7efdaaa6d19b in poll () from /lib64/libc.so.6 #1 0x7efda5a041a9 in ?? () from /usr/lib64/libglib-2.0.so.0 #2 0x7efda5a042bc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #3 0x7efdab6ea96b in QEventDispatcherGlib::processEvents (this=0x7efd84000b10, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #4 0x7efdab68f90a in QEventLoop::exec (this=this@entry=0x7efd92175c80, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #5 0x7efdab4addaa in QThread::exec (this=) at thread/qthread.cpp:515 #6 0x7efdad0b39e5 in ?? () from /usr/lib64/libQt5DBus.so.5 #7 0x7efdab4b2ced in QThreadPrivate::start (arg=0x7efdad326d60) at thread/qthread_unix.cpp:368 #8 0x7efda9297569 in start_thread () from /lib64/libpthread.so.0 #9 0x7efdaaa779ef in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7efd941c0700 (LWP 7512)): #0 0x7efda929d8ad in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7efd94e6692b in ?? () from /usr/lib64/dri/i965_dri.so #2 0x7efd94e66637 in ?? () from /usr/lib64/dri/i965_dri.so #3 0x7efda9297569 in start_thread () from /lib64/libpthread.so.0 #4 0x7efdaaa779ef in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7efd9d9fa700 (LWP 7511)): #0 0x7efdaaa6d19b in poll () from /lib64/libc.so.6 #1 0x7efda88db307 in ?? () from /usr/lib64/libxcb.so.1 #2 0x7efda88dcf3a in xcb_wait_for_event () from /usr/lib64/libxcb.so.1 #3 0x7efda07b2939 in ?? () from /usr/lib64/libQt5XcbQpa.so.5 #4 0x7efdab4b2ced in QThreadPrivate::start (arg=0x55bc34f23af0) at thread/qthread_unix.cpp:368 #5 0x7efda9297569 in start_thread () from /lib64/libpthread.so.0 #6 0x7efdaaa779ef in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7efdb14ddd80 (LWP 7510)): [KCrash Handler] #6 0x55bc339df06e in KrViewItem::itemRect (this=) at /usr/src/debug/krusader-2.7.2-lp151.46.2.x86_64/krusader/Panel/PanelView/krviewitem.cpp:140 #7 0x55bc339d126d in KrPreviewJob::sort (this=this@entry=0x55bc366affd0) at /usr/src/debug/krusader-2.7.2-lp151.46.2.x86_64/krusader/Panel/krpreviewjob.cpp:142 #8 0x55bc339d139e in KrPreviewJob::slotStartJob (this=0x55bc366affd0) at /usr/src/debug/krusader-2.7.2-lp151.46.2.x86_64/krusader/Panel/krpreviewjob.cpp:101 #9 0x7efdab6c0535 in QMetaObject::activate (sender=sender@entry=0x55bc366b, signalOffset=, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7ffe8e44ab50) at kernel/qobject.cpp:3767 #10 0x7efdab6c0c07 in QMetaObject::activate (sender=sender@entry=0x55bc366b, m=m@entry=0x7efdabb4ce80 , local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7ffe8e44ab50) at kernel/qobject.cpp:3629 #11 0x7efdab6cd087 in QTimer::timeout (this=this@entry=0x55bc366b, _t1=...) at .moc/moc_qtimer.cpp:200 #12 0x7efdab6cd3e8 in QTimer::timerEvent (this=0x55bc366b, e=) at kernel/qtimer.cpp:255 #13 0x7efdab6c105b in QObject::event (this=0x55bc366b, e=) at kernel/qobject.cpp:1269 #14 0x7efdac6563dc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5 #15 0x7efdac65dca4 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5 #16 0x7efdab6918d8 in QCoreApplication::notifyInternal2 (receiver=0x55bc366b, event=event@entry=0x7ffe8e44ae50) at kernel/qcoreapplication.cpp:1024 #17 0x7efdab6e9dee in QCoreApplication::sendEvent (event=0x7ffe8e44ae50, receiver=) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:233 #18 QTimerInfoList::activateTimers (this=0x55bc34f64930) at kernel/qtimerinfo_unix.cpp:643 #19 0x7efdab6ea5b1 in timerSourceDispatch (source=) at kernel/qeventdispatcher_glib.cpp:182 #20
[digikam] [Bug 412574] New images are not recognized when externally added to a DK folder
https://bugs.kde.org/show_bug.cgi?id=412574 --- Comment #6 from Kusi --- It turns out that a cloud sync service I've installed has automatically set fs.inotify.max_user_watches=1048576 in /etc/sysctrl.conf. This is enough to also include my Digikam setup. Apart from using more memory, I didn't experience any issues so far (no increased startup time on Linux) -- You are receiving this mail because: You are watching all bug changes.
[kdelibs] [Bug 193474] no longer possible to set emacs-keybindings on widgets
https://bugs.kde.org/show_bug.cgi?id=193474 Kusi changed: What|Removed |Added CC||k...@forum.titlis.org -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 412574] New images are not recognized when externally added to a DK folder
https://bugs.kde.org/show_bug.cgi?id=412574 --- Comment #2 from Kusi --- Thanks Maik, missed this option. What are the disadvantages? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 412574] New: New images are not recognized when externally added to a DK folder
https://bugs.kde.org/show_bug.cgi?id=412574 Bug ID: 412574 Summary: New images are not recognized when externally added to a DK folder Product: digikam Version: 6.3.0 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Database-Scan Assignee: digikam-bugs-n...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- SUMMARY DK's watchdog (I guess through the inotify API) for folders does not work anymore. A file added to a folder known to DK is not recognized by a running DK session anymore, as it was the case for DK 5.x STEPS TO REPRODUCE 1. Start DK 2. Copy a file (e.g via Dolphin) to an Album which is known to Digikam 3. DK does not immediately recognize the newly added file, but only on restart or on launching the maintenance tool SOFTWARE/OS VERSIONS Digikam: 6.3 Opensuse: 15.1 KDE Frameworks Version: 5.55.0 Qt Version: 5.9.7 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 412574] New images are not recognized when externally added to a DK folder
https://bugs.kde.org/show_bug.cgi?id=412574 Kusi changed: What|Removed |Added CC||k...@forum.titlis.org -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 412574] New images are not recognized when externally added to a DK folder
https://bugs.kde.org/show_bug.cgi?id=412574 --- Comment #4 from Kusi --- Interesting. In this case, it would be great to make the directories to be watched configurable. For example, I only need the folder 2019 to be watched for new files. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 412567] New: Baloo crashes on startup
https://bugs.kde.org/show_bug.cgi?id=412567 Bug ID: 412567 Summary: Baloo crashes on startup Product: frameworks-baloo Version: 5.55.0 Platform: openSUSE RPMs OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: Baloo File Daemon Assignee: stefan.bru...@rwth-aachen.de Reporter: k...@forum.titlis.org Target Milestone: --- Application: baloo_file (5.55.0) Qt Version: 5.9.7 Frameworks Version: 5.55.0 Operating System: Linux 4.12.14-lp151.28.16-default x86_64 Distribution: "openSUSE Leap 15.1" -- Information about the crash: - What I was doing when the application crashed: Start computer & autologin to KDE There are other similar reports such as 389848, but this crash has a different callstack, I believe -- Backtrace: Application: Baloo File Indexing Daemon (baloo_file), signal: Aborted Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7f5e46709900 (LWP 2418))] Thread 3 (Thread 0x7f5e3aff5700 (LWP 2588)): [KCrash Handler] #6 0x7f5e44070160 in raise () from /lib64/libc.so.6 #7 0x7f5e44071741 in abort () from /lib64/libc.so.6 #8 0x7f5e41b08a82 in mdb_assert_fail (env=0x55f476242c60, expr_txt=expr_txt@entry=0x7f5e41b0a50f "rc == 0", func=func@entry=0x7f5e41b0ae78 <__func__.6935> "mdb_page_dirty", line=line@entry=2071, file=0x7f5e41b0a4f0 "mdb.c") at mdb.c:1487 #9 0x7f5e41afdd85 in mdb_page_dirty (txn=0x55f476244080, mp=) at mdb.c:2071 #10 0x7f5e41afef6a in mdb_page_alloc (num=num@entry=1, mp=mp@entry=0x7f5e3aff4008, mc=) at mdb.c:2252 #11 0x7f5e41aff1d9 in mdb_page_touch (mc=mc@entry=0x7f5e3aff4540) at mdb.c:2370 #12 0x7f5e41b00cd4 in mdb_cursor_touch (mc=mc@entry=0x7f5e3aff4540) at mdb.c:6304 #13 0x7f5e41b03e6e in mdb_cursor_put (mc=0x7f5e3aff4540, key=0x7f5e3aff4910, data=0x7f5e3aff4920, flags=) at mdb.c:6438 #14 0x7f5e41b06afb in mdb_put (txn=0x55f476244080, dbi=2, key=key@entry=0x7f5e3aff4910, data=data@entry=0x7f5e3aff4920, flags=flags@entry=0) at mdb.c:8796 #15 0x7f5e4570f56c in Baloo::PostingDB::put (this=this@entry=0x7f5e3aff4a00, term=..., list=...) at /usr/src/debug/baloo5-5.55.0-lp151.2.2.x86_64/src/engine/postingdb.cpp:78 #16 0x7f5e4571b8b0 in Baloo::WriteTransaction::commit (this=0x55f47649e180) at /usr/src/debug/baloo5-5.55.0-lp151.2.2.x86_64/src/engine/writetransaction.cpp:305 #17 0x7f5e45714bd2 in Baloo::Transaction::commit (this=this@entry=0x7f5e3aff4b20) at /usr/src/debug/baloo5-5.55.0-lp151.2.2.x86_64/src/engine/transaction.cpp:269 #18 0x55f47571afc7 in Baloo::UnindexedFileIndexer::run (this=0x55f476431d10) at /usr/src/debug/baloo5-5.55.0-lp151.2.2.x86_64/src/file/unindexedfileindexer.cpp:76 #19 0x7f5e44b6ae22 in QThreadPoolThread::run (this=0x55f476495a80) at thread/qthreadpool.cpp:99 #20 0x7f5e44b6dced in QThreadPrivate::start (arg=0x55f476495a80) at thread/qthread_unix.cpp:368 #21 0x7f5e41f67569 in start_thread () from /lib64/libpthread.so.0 #22 0x7f5e441329ef in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f5e3bb08700 (LWP 2431)): #0 0x7f5e4412819b in poll () from /lib64/libc.so.6 #1 0x7f5e404e31a9 in ?? () from /usr/lib64/libglib-2.0.so.0 #2 0x7f5e404e32bc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #3 0x7f5e44da596b in QEventDispatcherGlib::processEvents (this=0x7f5e34000b10, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #4 0x7f5e44d4a90a in QEventLoop::exec (this=this@entry=0x7f5e3bb07c80, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #5 0x7f5e44b68daa in QThread::exec (this=) at thread/qthread.cpp:515 #6 0x7f5e4593b9e5 in ?? () from /usr/lib64/libQt5DBus.so.5 #7 0x7f5e44b6dced in QThreadPrivate::start (arg=0x7f5e45baed60) at thread/qthread_unix.cpp:368 #8 0x7f5e41f67569 in start_thread () from /lib64/libpthread.so.0 #9 0x7f5e441329ef in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f5e46709900 (LWP 2418)): #0 0x7f5e4412819b in poll () from /lib64/libc.so.6 #1 0x7f5e404e31a9 in ?? () from /usr/lib64/libglib-2.0.so.0 #2 0x7f5e404e32bc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #3 0x7f5e44da596b in QEventDispatcherGlib::processEvents (this=0x55f47622e680, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #4 0x7f5e44d4a90a in QEventLoop::exec (this=this@entry=0x7fff1ed5b090, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #5 0x7f5e44d539b4 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1297 #6 0x55f47571013c in main (argc=, argv=) at /usr/src/debug/baloo5-5.55.0-lp151.2.2.x86_64/src/file/main.cpp:104 [Inferior 1 (process 2418) detached] Possible duplicates by query: bug 411806, bug 411706, bug 411660, bug 411192, bug 411139. Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 133011] SCHEMA : add album tags property
https://bugs.kde.org/show_bug.cgi?id=133011 Kusi changed: What|Removed |Added CC||k...@forum.titlis.org --- Comment #8 from Kusi --- This feature wish now exists since 14 years :) Still, this feature would be very helpful even more in 2020. Please consider adding tags to albums. Smugmug, for example, allows to set keywords on galleries or folders -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 445948] New: dk only shows one file if two files only differ in lower/upper case extension
https://bugs.kde.org/show_bug.cgi?id=445948 Bug ID: 445948 Summary: dk only shows one file if two files only differ in lower/upper case extension Product: digikam Version: 7.3.0 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Database Assignee: digikam-bugs-n...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- SUMMARY Digikam doesn't handle two identical files, one with upper case extension, the other one with lower case extension. In an alternating order, only the images with lower case ext are shown or the images with upper case are shown. This is an improbable case, however happens when you copy over files from a Windows machine who handles lower/uppercase only halfway. I had around 50 of such files on in my collection. STEPS TO REPRODUCE 1. add two identical files with the name IMG_001.JPG and IMG_001.jpg 2. Restart digikam: only IMG_001.jpg is visible 3. Restart digikam: only IMG_001.JPG is visible OBSERVED RESULT only one of the two images is shown at a time EXPECTED RESULT treat both files as different images. Gwenview, for example, shows both IMG_001.jpg and IMG_001.JPG ADDITIONAL INFORMATION using external mariadb (mysql) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 445948] dk only shows one file if two files only differ in lower/upper case extension
https://bugs.kde.org/show_bug.cgi?id=445948 --- Comment #3 from Kusi --- I see. However, the problem here is that digikam "swallows" the error without notifying the user. You can set a tag to an image, and when you restart digikam, the tags are gone. If you restart again, the tags are here again. The alternating images/hiding of images is not obvious to the user. A warning like: "Digikam cannot handle upper/lower case differences. Please rename the images outside of Digikam" would already be good enough -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 382582] Video stutters when played with MP3 audio track
https://bugs.kde.org/show_bug.cgi?id=382582 --- Comment #61 from Kusi --- (In reply to caulier.gilles from comment #60) > This problem will be closed when we use Qt6 instead Qt5 with digiKam What changes with Qt6? Is the plan to go back from QtAV to QtMultimedia? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 458094] New: Add support for imagga
https://bugs.kde.org/show_bug.cgi?id=458094 Bug ID: 458094 Summary: Add support for imagga Product: digikam Version: 7.8.0 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Tags-Engine Assignee: digikam-bugs-n...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- Please add support for an automatic tagging mechanism based on AI, such as imagga.com. Imagga allows up to 1000 free API calls/month. Usage: Select album or a selection of images and choose "Set tags with Imagga" or "Set tags automatically". Preferrably, the automatic tags have a different color/style such that you can easily recognize if a tag was set manually or automatically (as Flickr does) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 458094] Add support for imagga
https://bugs.kde.org/show_bug.cgi?id=458094 Kusi changed: What|Removed |Added CC||k...@forum.titlis.org -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 272451] FACTORING : allow to synchronize local albums with remote web service albums and vis-versa
https://bugs.kde.org/show_bug.cgi?id=272451 Kusi changed: What|Removed |Added CC||k...@forum.titlis.org --- Comment #8 from Kusi --- one-way sync of your local database to Smugmug: https://github.com/githubkusi/digikam2smugmug (this is a workaround rather than a solution) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 470145] New: shourtcut for assigning ratings (stars) is not persistent
https://bugs.kde.org/show_bug.cgi?id=470145 Bug ID: 470145 Summary: shourtcut for assigning ratings (stars) is not persistent Classification: Applications Product: digikam Version: 8.0.0 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Usability-Keyboard Assignee: digikam-bugs-n...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- SUMMARY When you assign a new shortcut for assigning stars to a photo, the shortcut only works for the current session but is reset to default after restarting DK. Other assigned shortcuts (e.g "About Digikam") work fine even after restarting DK. Only the rating shortcuts are affected. This used to work in DK 7.10 STEPS TO REPRODUCE 1. Open "Configure Keyboard Shortcuts" 2. Assign "1" to "Assign Rating 1 Star". Doesn't matter if you choose shortcut or alternate. 3. Close dialog and restart DK 4. Open "Configure Keyboard Shortcuts" and observe that the shortcut is reset to the default "CTRL+1" (or the alternate is gone if you have chosen alternate in step 2) OBSERVED RESULT After restarting DK, the assigned shortcut is gone EXPECTED RESULT Make shortcut assignment persistent ADDITIONAL INFORMATION This used to work in DK 7.10 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 470145] shourtcut for assigning ratings (stars) is not persistent
https://bugs.kde.org/show_bug.cgi?id=470145 Kusi changed: What|Removed |Added CC||k...@forum.titlis.org -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 470146] New: Crash while playing videos (play mode, F9)
https://bugs.kde.org/show_bug.cgi?id=470146 Bug ID: 470146 Summary: Crash while playing videos (play mode, F9) Classification: Applications Product: digikam Version: 8.0.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: DImg-Plugins Assignee: digikam-bugs-n...@kde.org Reporter: k...@forum.titlis.org Target Milestone: --- SUMMARY Play an album (shortcut "F9") containing images and videos. On some videos, DK crashes. It is not always reproducible but if you load a video in "play" mode (F9) multiple time, DK will crash after ~5 successful video display. Looks like a race condition to me. Regression since DK 7.10. Crash is reproducible with any kind of video formats. Relevant part of the call stack #6 set_number (...) at libavutil/opt.c:612 #7 QtAV::AVDecoder::open (...) at /usr/src/debug/digikam-8.0.0/core/libs/video/qtav/codec/AVDecoder.cpp:196 FULL CALLSTACK Application: digiKam (digikam), signal: Segmentation fault [KCrash Handler] #4 0x7fcd57275f72 in av_opt_next (obj=obj@entry=0x55c0311c6dc0, last=last@entry=0x0) at libavutil/opt.c:52 #5 0x7fcd572760bb in av_opt_find2 (obj=obj@entry=0x55c0311c6dc0, name=0x7fcd5cd706d4 "refcounted_frames", unit=unit@entry=0x0, opt_flags=opt_flags@entry=0, search_flags=0, target_obj=target_obj@entry=0x7ffc15bc6390) at libavutil/opt.c:1806 #6 0x7fcd5727b4e4 in set_number (obj=0x55c0311c6dc0, name=, num=1, den=1, intnum=1, search_flags=) at libavutil/opt.c:612 #7 0x7fcd5cb5a326 in QtAV::AVDecoder::open (this=0x55c031573990) at /usr/src/debug/digikam-8.0.0/core/libs/video/qtav/codec/AVDecoder.cpp:196 #8 0x7fcd5cb0fa2b in QtAV::AVPlayerCore::Private::setupAudioThread (this=0x55c030cd8710, player=0x55c0313c3a80) at /usr/src/debug/digikam-8.0.0/core/libs/video/qtav/ffmpeg/AVPlayerCore_p.cpp:629 #9 0x7fcd5cafc727 in QtAV::AVPlayerCore::playInternal (this=0x55c0313c3a80) at /usr/include/qt5/QtCore/qscopedpointer.h:116 #10 0x7fcd5af251d3 in ?? () from /lib64/libQt5Core.so.5 #11 0x7fcd5af251d3 in ?? () from /lib64/libQt5Core.so.5 #12 0x7fcd5bc96a22 in QAbstractButton::toggled(bool) () from /lib64/libQt5Widgets.so.5 #13 0x7fcd5bc96ed1 in ?? () from /lib64/libQt5Widgets.so.5 #14 0x7fcd5bc98185 in QAbstractButton::setChecked(bool) () from /lib64/libQt5Widgets.so.5 #15 0x7fcd388239a2 in DigikamGenericSlideShowPlugin::SlideToolBar::pause (val=false, this=0x55c0312fac00) at /usr/src/debug/digikam-8.0.0/core/dplugins/generic/view/slideshow/widgets/slidetoolbar.cpp:213 #16 DigikamGenericSlideShowPlugin::SlideToolBar::pause (val=false, this=0x55c0312fac00) at /usr/src/debug/digikam-8.0.0/core/dplugins/generic/view/slideshow/widgets/slidetoolbar.cpp:206 #17 DigikamGenericSlideShowPlugin::SlideOSD::pause (this=0x55c028cd1b10, b=false) at /usr/src/debug/digikam-8.0.0/core/dplugins/generic/view/slideshow/widgets/slideosd.cpp:373 #18 0x7fcd3881a1a0 in DigikamGenericSlideShowPlugin::SlideShowLoader::setCurrentView (view=DigikamGenericSlideShowPlugin::SlideShowLoader::VideoView, this=0x55c02a13efa0) at /usr/src/debug/digikam-8.0.0/core/dplugins/generic/view/slideshow/common/slideshowloader.cpp:276 #19 DigikamGenericSlideShowPlugin::SlideShowLoader::slotVideoLoaded (loaded=, this=0x55c02a13efa0) at /usr/src/debug/digikam-8.0.0/core/dplugins/generic/view/slideshow/common/slideshowloader.cpp:475 #20 DigikamGenericSlideShowPlugin::SlideShowLoader::qt_static_metacall (_o=0x55c02a13efa0, _id=, _a=, _c=) at /usr/src/debug/digikam-8.0.0/build/core/dplugins/generic/view/slideshow/Generic_SlideShow_Plugin_autogen/P66WHCG54J/moc_slideshowloader.cpp:146 #21 0x7fcd5af251d3 in ?? () from /lib64/libQt5Core.so.5 #22 0x7fcd5cacb5af in Digikam::SlideVideo::signalVideoLoaded (this=, _t1=) at /usr/src/debug/digikam-8.0.0/build/core/libs/video/core_videotools_obj_autogen/NNZHHPJXVP/moc_slidevideo.cpp:238 #23 0x7fcd5af18c50 in QObject::event(QEvent*) () from /lib64/libQt5Core.so.5 #24 0x7fcd5bba51ae in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5 #25 0x7fcd5aeec978 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib64/libQt5Core.so.5 #26 0x7fcd5aeeff71 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib64/libQt5Core.so.5 #27 0x7fcd5af46713 in ?? () from /lib64/libQt5Core.so.5 #28 0x7fcd4db168d8 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #29 0x7fcd4db16ce8 in ?? () from /lib64/libglib-2.0.so.0 #30 0x7fcd4db16d7c in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #31 0x7fcd5af45f26 in QEventDispatcherGlib::processEvents(QFlags) () from /lib64/libQt5Core.so.5 #32 0x7fcd5aeeb40b in QEventLoop::exec(QFlags) () from /lib64/libQt5Core.so.5 #33 0x7fcd5aef38a0 in QCoreApplication::exec() () from /lib64/libQt5Core.so.5 #34
[digikam] [Bug 470146] Crash while playing videos (play mode, F9)
https://bugs.kde.org/show_bug.cgi?id=470146 Kusi changed: What|Removed |Added CC||k...@forum.titlis.org -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 470146] Crash while playing videos (play mode, F9)
https://bugs.kde.org/show_bug.cgi?id=470146 Kusi changed: What|Removed |Added Severity|normal |crash -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 470146] Crash while playing videos (play mode, F9)
https://bugs.kde.org/show_bug.cgi?id=470146 --- Comment #1 from Kusi --- STEPS TO REPRODUCE 1. Album with 1 image and 1 video 2. F9 (play mode) 3. Go back/forth with cursor keys, switch between image and video 4. After ~5 times going back/forth, DK crashes -- You are receiving this mail because: You are watching all bug changes.
