[digikam] [Bug 363697] Album visible even after deletion [patch]

https://bugs.kde.org/show_bug.cgi?id=363697 --- Comment #16 from Johannes Hirte --- (In reply to swatilodha27 from comment #15) > Is it possible to already have a "Fake Album" row when the DB is initially > created? > In the DB schema file, adding a query: > // >

[digikam] [Bug 364797] after editing metadata, rename hangs

https://bugs.kde.org/show_bug.cgi?id=364797 Johannes Hirte changed: What|Removed |Added Platform|Other |Gentoo Packages

[digikam] [Bug 364797] New: after editing metadata, rename hangs

https://bugs.kde.org/show_bug.cgi?id=364797 Bug ID: 364797 Summary: after editing metadata, rename hangs Product: digikam Version: 5.0.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal

[digikam] [Bug 363697] Album visible even after deletion [patch]

https://bugs.kde.org/show_bug.cgi?id=363697 --- Comment #13 from Johannes Hirte --- Patch works for me with MySQL/MariaDB. -- You are receiving this mail because: You are watching all bug changes.

[digikam] [Bug 363697] Album visible even after deletion

https://bugs.kde.org/show_bug.cgi?id=363697 --- Comment #8 from Johannes Hirte --- (In reply to Johannes Hirte from comment #7) > Of course, foreign key checks is part of the problem. Disabling this with: > > d->db->execSql(QString("SET FOREIGN_KEY_CHECKS =

[digikam] [Bug 363697] Album visible even after deletion

https://bugs.kde.org/show_bug.cgi?id=363697 --- Comment #7 from Johannes Hirte --- Of course, foreign key checks is part of the problem. Disabling this with: d->db->execSql(QString("SET FOREIGN_KEY_CHECKS = 0;")); d->db->execSql(QString("UPDATE Albums SET

[digikam] [Bug 363697] Album visible even after deletion

https://bugs.kde.org/show_bug.cgi?id=363697 --- Comment #6 from Johannes Hirte --- some more debugging: void CoreDB::makeStaleAlbum(int albumID) does not work. After this function, albumRoot of the deleted album has to be 0 and relativePath has to be prefixed with

[digikam] [Bug 363697] Album visible even after deletion

https://bugs.kde.org/show_bug.cgi?id=363697 --- Comment #5 from Johannes Hirte --- After some digging into the code, I've seen that deleted images are finally removed from the db. It's just done asynchronously, deferred for some days: bool

[digikam] [Bug 363697] Album visible even after deletion

https://bugs.kde.org/show_bug.cgi?id=363697 --- Comment #3 from Johannes Hirte --- As my report is marked as a duplicate of this, please see my description there: https://bugs.kde.org/show_bug.cgi?id=364614 It't not only the album shouldn't be visible anymore after

[digikam] [Bug 364614] New: images/albums not deleted in database when deleting/moving in digikam

https://bugs.kde.org/show_bug.cgi?id=364614 Bug ID: 364614 Summary: images/albums not deleted in database when deleting/moving in digikam Product: digikam Version: 5.0.0 Platform: Gentoo Packages OS: Linux

[kmix] [Bug 364141] Kmix crashes when trying to change the volume for individual streams with scrollwheel from systray

https://bugs.kde.org/show_bug.cgi?id=364141 Johannes Hirte changed: What|Removed |Added CC|

[frameworks-kded] [Bug 360171] New: orphaned and hanging kf5/plasma-processes after session end

https://bugs.kde.org/show_bug.cgi?id=360171 Bug ID: 360171 Summary: orphaned and hanging kf5/plasma-processes after session end Product: frameworks-kded Version: unspecified Platform: Other OS: other

[Powerdevil] [Bug 358588] New: backlight not restored properly, after it was reduced on inactivity

https://bugs.kde.org/show_bug.cgi?id=358588 Bug ID: 358588 Summary: backlight not restored properly, after it was reduced on inactivity Product: Powerdevil Version: unspecified Platform: Gentoo Packages OS: