[digikam] [Bug 437897] Windows timestamp to metadata extraction for TIFFs changes when modifying files
https://bugs.kde.org/show_bug.cgi?id=437897 --- Comment #14 from Quincy --- I was always referring to copying files outside of digiKam, but I will test with digiKam 7.3 on both systems when its out or with a current appimage build. Many thanks so far! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 437897] Windows timestamp to metadata extraction for TIFFs changes when modifying files
https://bugs.kde.org/show_bug.cgi?id=437897 Quincy changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #12 from Quincy --- Further remarks on the Windows situation: - I replaced the test file as the small one did not work as described (Maik found out by himself). Using Linux (with digiKam 7.1 in that case) I see the following behavior: - Copying updates the creation timestamp and leaves modification with its old value (as on Windows) - Rotating the image file does not update creation or modification timestamp at all (in contrast to Windows) So my summary (also answering your earlier question): We should distinguish between database and file properties: - Given the situation that Windows as well as Linux always update creation time when copying files (without changing content) and do not update the modification time IMHO its more useful to prefer modification time over creation time for reading the content of ImageInformation.creationDate (as the content was "created" in the state which is read into dK at modification time). - When rotating the image, content is changed, so an update of file's as well as database modification time makes sense (it's not the very same unmodified file as before), but ImageInformation.creationDate should stay the same (as would an Exiv tag if it existed). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 437897] Windows timestamp to metadata extraction for TIFFs changes when modifying files
https://bugs.kde.org/show_bug.cgi?id=437897 --- Comment #11 from Quincy --- Created attachment 138922 --> https://bugs.kde.org/attachment.cgi?id=138922=edit New test file with sufficient size and zipped -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 437897] Windows timestamp to metadata extraction for TIFFs changes when modifying files
https://bugs.kde.org/show_bug.cgi?id=437897 Quincy changed: What|Removed |Added Attachment #138908|0 |1 is obsolete|| --- Comment #10 from Quincy --- Comment on attachment 138908 --> https://bugs.kde.org/attachment.cgi?id=138908 Test file Obviously my test file was not good also, as I could not force the described behavior with this file (too small?) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 437897] Windows timestamp to metadata extraction for TIFFs changes when modifying files
https://bugs.kde.org/show_bug.cgi?id=437897
--- Comment #3 from Quincy ---
Created attachment 138908
--> https://bugs.kde.org/attachment.cgi?id=138908=edit
Test file
I created a simple TIFF file which has:
Creation: Montag, 31. Mai 2021, 16:04:20
Modification: Montag, 31. Mai 2021, 16:01:47
It's shown in my digiKam ("Date" of file properties and "Created" in mouseover
of thumbnail) with it's modification date (16:01). If I rotate it the file
property changes to 16:10 (current time) the mouseover to 16:04.
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 437897] Windows timestamp to metadata extraction for TIFFs changes when modifying files
https://bugs.kde.org/show_bug.cgi?id=437897 --- Comment #2 from Quincy --- Rotation took place in the main window/thumbnail view (either within the preview with the icons in the upper left corner or via the menu "Item -> Rotate"). This updates the existing image in place. For reproducing the problem it's important to have a file with "creation" newer than "modification" (due to the mentioned copy process). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 437897] New: Windows timestamp to metadata extraction for TIFFs changes when modifying files
https://bugs.kde.org/show_bug.cgi?id=437897 Bug ID: 437897 Summary: Windows timestamp to metadata extraction for TIFFs changes when modifying files Product: digikam Version: 7.2.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Metadata-Date Assignee: digikam-bugs-n...@kde.org Reporter: bbc.qui...@gmx.de Target Milestone: --- I've read some reports about the translation of Exiv tags to dates, but none of them seems to fit, so I open this new one here for some curiosity I found: I have TIFF images generated via an industrial camera - so no Exiv and such. On the original drive Windows has equal timestamps for "creation" and "modification". When copying those to a network drive windows sets "creation" to the time of copy and leaves "modification" unchanged. Copying to the computer running digiKam this happens again. When digiKam reads those files it obviously uses "modification" as the timestamp to store in Images.modificationDate as well as ImageInformation.creationDate columns. This is OK for me (but also somehow arguable regarding the names), as the creation of the image indeed is not in line with the "creation" timestamp that Windows assigns to the file. If the image is rotated using digiKam Images.modificationDate is updated to the current timestamp (which is fine, too), but also ImageInformation.creationDate is updated during that process to the original files "creation" timestamp (which is the one from copying and has been skipped during the first read of the file). So behavior of using file timestamps for filling the database is not consistent during the whole process. I would have expected the ImageInformation.creationDate value not to be changing at all. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 436571] Tooltips for images don't show tags containing "<" correctly
https://bugs.kde.org/show_bug.cgi?id=436571 --- Comment #6 from Quincy --- Thanks Maik for the quick fix! @Gilles: I usually do not taint the image files with anything, so I had to find again how to reactivate that behavior temporarily. BTW on that: The Menu entry to write metadata into files (now) is active but obviously useless if nothing is checked in the settings which metadata should be written to files. If something is checked the use is limited to the case where "lazy synchronization" is activated, too as otherwise this is done on-the-fly anyway. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 436571] Tooltips for images don't show tags containing "<" correctly
https://bugs.kde.org/show_bug.cgi?id=436571 --- Comment #3 from Quincy --- @Gilles: It is not metadata saved within the image, but a tag assigned via digiKam (database only). I think Maik is right, as "Test Test2" completely removes the part between the angle brackets. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 436571] New: Tooltips for images don't show tags containing "<" correctly
https://bugs.kde.org/show_bug.cgi?id=436571 Bug ID: 436571 Summary: Tooltips for images don't show tags containing "<" correctly Product: digikam Version: 7.2.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Thumbs-Image Assignee: digikam-bugs-n...@kde.org Reporter: bbc.qui...@gmx.de Target Milestone: --- SUMMARY Tooltips for images don't show tags containing "<" correctly. In table view display is correct. STEPS TO REPRODUCE 1. Create a tag containing "<" e.g. "good (<=5%)" 2. Assign it to an imgae 3. Hover over image in thumbnail view displaying the tooltip with digiKam properties OBSERVED RESULT Text is cut off at "<" symbol EXPECTED RESULT Text should be completely displayed as also other tags do -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 434275] Row height determined by number of tags even if they are not visible
https://bugs.kde.org/show_bug.cgi?id=434275 --- Comment #4 from Quincy --- With digiKam-7.2.0-20210311T200524-Win64.exe the issue is solved. Very nice and fast work, very much appreciated :-) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 434275] Row height determined by number of tags even if they are not visible
https://bugs.kde.org/show_bug.cgi?id=434275 --- Comment #1 from Quincy --- Just found out because it was a quite long list in my case and further testing: There is some update problem, as I finally could manage to display all entries in a "one-line" row after switching back and forth to different views. Even when removing the column, some entries directly switch to appropriate height, but not all. Additionally those who switched don't enlarge again when re-enabling the display of tags leading to cluttered display in those cases. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 434275] New: Row height determined by number of tags even if they are not visible
https://bugs.kde.org/show_bug.cgi?id=434275 Bug ID: 434275 Summary: Row height determined by number of tags even if they are not visible Product: digikam Version: 7.1.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Albums-TableView Assignee: digikam-bugs-n...@kde.org Reporter: bbc.qui...@gmx.de Target Milestone: --- SUMMARY The height of the rows in the TableView obviously is adjusted always by the number of tags assigned to the image. So rows for images with many tags are big enough to fit all of those at the same time. Height stays the same even if the "Tags" column is removed and not visible anymore. STEPS TO REPRODUCE 1. Open an album with images tagged with several tags in parallel 2. Remove the (default) column "Tags" OBSERVED RESULT Height of table rows stays as before EXPECTED RESULT Row height should be reduced to the actually visible data SOFTWARE/OS VERSIONS Windows: 10 ADDITIONAL INFORMATION Changing the tab/view back and forth does not change anything, so no update problem. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 431788] New: Make option available to not resample images in viewer
https://bugs.kde.org/show_bug.cgi?id=431788 Bug ID: 431788 Summary: Make option available to not resample images in viewer Product: digikam Version: 7.1.0 Platform: unspecified OS: Unspecified Status: REPORTED Severity: wishlist Priority: NOR Component: Preview-Image Assignee: digikam-bugs-n...@kde.org Reporter: bbc.qui...@gmx.de Target Milestone: --- I'm trying to use digikam to manage a collection of scientific images where the information of a single pixel matters (TIFF format). Up to now I browsed them with IrfanView (Windows) or Gwenview (Linux) as both of them are "capable" of displaying single pixels when zoomed in far enough: In IrfanView I can select to not use resampling while zooming (default is on), Gwenview seems not to have an option to use resampling at all. The (unchangeable) default in digiKam seems to always use resampling while zooming as the image will get "blurry" when zooming in very much. So my wish would be an option to not use resampling, but display single (sized up) pixels when zooming in to that level. This may not only be useful for my special application, but also for people wanting to evaluate JPEG compression artifacts, blur of the image or similar things which are difficult to see when the resampling method already blurs the image. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 430147] Search and escaping of database wildcard characters in filenames
https://bugs.kde.org/show_bug.cgi?id=430147 --- Comment #4 from Quincy --- Thanks for the quick fix. So the wildcards "_" and "%" will still be usable and have to be escaped if one needs to use them as literal? Could one please update the documentation accordingly as wildcards may be of nice use, but I think most people will try "*" and "?" otherwise if at all. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 430147] New: Search and escaping of database wildcard characters in filenames
https://bugs.kde.org/show_bug.cgi?id=430147
Bug ID: 430147
Summary: Search and escaping of database wildcard characters in
filenames
Product: digikam
Version: 7.1.0
Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
Severity: normal
Priority: NOR
Component: Searches-Advanced
Assignee: digikam-bugs-n...@kde.org
Reporter: bbc.qui...@gmx.de
Target Milestone: ---
I have filenames with underscores "_" in them separating information encoded in
them e.g. "56_1607099331_270_3.tif" where the information is an id, a
timestamp, a rotation angle and a camera id.
To tag those files properly I wanted to use the (mighty) search tool, but there
are several things working differently than expected:
Using the "keyword search" (not the "advanced search") with "_270_" also yields
results with filenames containing e.g. "12709". Obviously this field does not
use usual wildcards for file managers ("*" and "?") but the database (in my
case SQLite) ones for a "LIKE" query which are "_" and "%". This is not
documented on
https://docs.kde.org/trunk5/en/extragear-graphics/digikam/using-digikam.html#using-mainwindow-searchesview,
instead it is stated that special characters are ignored.
It is not possible (or I did not find how) to escape those characters to search
for a "real" underscore e.g. escaping with "\" (even multiple ones) does not
work.
The same applies for the advanced search with the "File name" field.
Thanks in advance for having a look into that issue and the great work on this
software.
--
You are receiving this mail because:
You are watching all bug changes.
[gwenview] [Bug 372417] Entering fullscreen will switch to other monitor when Gwenview is already maximized
https://bugs.kde.org/show_bug.cgi?id=372417 --- Comment #11 from Quincy --- I was just about to test with the new user, but had to wait for other stuff to get finished before restarting with a different user. It is kind of weird, that Daniel and my behavior fulfilled this rather complicated trigger of moving and maximizing which you luckily now found (and I can reproduce here also). Qt >=5.10 is not yet available for my one and only distro (Gentoo) without bigger hassle, so unfortunately I will have to wait... -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 372417] Entering fullscreen will switch to other monitor when Gwenview is already maximized
https://bugs.kde.org/show_bug.cgi?id=372417 --- Comment #8 from Quincy --- For me it is still valid as described, even given that I now have newer package versions installed than Daniel: Gwenview 17.12.3 / KF 5.46.0 / Qt 5.9.4 / kwin 5.12.5 but on Gentoo Linux -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 379987] UpdateSchemaFromV7ToV8: Unable to execute query (MySQL specific)
https://bugs.kde.org/show_bug.cgi?id=379987 --- Comment #15 from Quincy <bbc.qui...@gmx.de> --- Current AppImage Version (including your fixes) happily upgrade DB Version 8->9. Upgrade of a restored V7 DB to 8 (and then 9) first fails with: digikam.dbengine: Failure executing query: Error messages: "QMYSQL: Unable to execute query" "Cannot add or update a child row: a foreign key constraint fails (`digikam-appimage-core`.`#sql-948_247`, CONSTRAINT `ImageMetadata_Images` FOREIGN KEY (`imageid`) REFERENCES `Images` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)" 1452 2 Bound values: () digikam.dbengine: Error while executing DBAction [ "UpdateSchemaFromV7ToV8" ] Statement [ "ALTER TABLE ImageMetadata ADD CONSTRAINT ImageMetadata_Images FOREIGN KEY (imageid) REFERENCES Images (id) ON DELETE CASCADE ON UPDATE CASCADE, ENGINE InnoDB;" ] digikam.coredb: Core database: schema update to V 8 failed! This is the issue I mentioned earlier with orphaned entries in (my) ImageMetadata which I could solve by hand (just included here for reference of the error message). After removal of these entries, there are some complaints after the update process about thumbnails.ThumbSettings not being present: digikam.dbengine: Loading SQL code from config file "/run/firejail/appimage/.appimage-5447/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 9 digikam.coredb: Core database: success updating to version 8 digikam.coredb: Core database: success updating to version 8 digikam.coredb: Core database: success updating to version 9 digikam.coredb: Core database: success updating to version 9 ..snip.. digikam.dbengine: Prepare failed! digikam.dbengine: Failure executing query: "SELECT value FROM ThumbSettings WHERE keyword=?;" Error messages: "QMYSQL3: Unable to prepare statement" "Table 'digikam-appimage-thumbnails.ThumbSettings' doesn't exist" 1146 2 Bound values: () digikam.dbengine: Failure executing query: "SELECT value FROM ThumbSettings WHERE keyword='DBThumbnailsVersion';" Error messages: "QMYSQL: Unable to execute query" "Table 'digikam-appimage-thumbnails.ThumbSettings' doesn't exist" 1146 2 Bound values: (QVariant(QString, "DBThumbnailsVersion")) digikam.dbengine: Error while executing DBAction [ "SelectThumbnailSetting" ] Statement [ "SELECT value FROM ThumbSettings WHERE keyword=:keyword;" ] digikam.thumbsdb: ThumbDB SelectThumbnailSetting val ret = 1 digikam.dbengine: Prepare failed! digikam.dbengine: Failure executing query: "SELECT value FROM ThumbSettings WHERE keyword=?;" Error messages: "QMYSQL3: Unable to prepare statement" "Table 'digikam-appimage-thumbnails.ThumbSettings' doesn't exist" 1146 2 Bound values: () digikam.dbengine: Failure executing query: "SELECT value FROM ThumbSettings WHERE keyword='DBThumbnailsVersionRequired';" Error messages: "QMYSQL: Unable to execute query" "Table 'digikam-appimage-thumbnails.ThumbSettings' doesn't exist" 1146 2 Bound values: (QVariant(QString, "DBThumbnailsVersionRequired")) digikam.dbengine: Error while executing DBAction [ "SelectThumbnailSetting" ] Statement [ "SELECT value FROM ThumbSettings WHERE keyword=:keyword;" ] digikam.thumbsdb: ThumbDB SelectThumbnailSetting val ret = 1 digikam.thumbsdb: Thumbs database: have a structure version "" digikam.thumbsdb: ThumbDB SelectThumbnailLegacySetting val ret = 0 digikam.thumbsdb: ThumbDB SelectThumbnailLegacySetting val ret = 0 digikam.general: Thumbnails database ready for use This was true in the original ThumbsDB before the update (V2: named "Settings" there), but it is renamed during the update process V2->V3 (visible in the table and dbconfig.xml, but not on console). Therefore these errors do not show up on a second start of digikam, but I was wondering why they show up right after the update run. So just a minor glitch, which I would not even have recognized when not watching console output... Many thanks for your efforts resolving this! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 388351] Use AppImage SDK version 10 instead 6 to be compatible with FireJail
https://bugs.kde.org/show_bug.cgi?id=388351 --- Comment #5 from Quincy <bbc.qui...@gmx.de> --- Works, thanks! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 379987] UpdateSchemaFromV7ToV8: Unable to execute query (MySQL specific)
https://bugs.kde.org/show_bug.cgi?id=379987 --- Comment #11 from Quincy <bbc.qui...@gmx.de> --- I'm using MySQL on the very same computer as digikam. This is "local", but not internal to digikam as the MySQL server is running separately (for web development and other stuff, too). Because it is the same computer this obviously usually works via the socket. With the AppImage this has to go to "local network" likely because the AppImage is somehow complete in itself. This is still on the same computer, but then communicating via TCP/IP. Indeed I would have other options for this setup, but was always (since the beginning with digikam 2.x) planning to move the MySQL server (together with the pictures) away from the digikam computer to end up in some kind of "multi-user" digikam. Network/server wise this would result in the distributed setup I already almost have (seperate MySQL instance). Main problem is/was access to remote collections (which was improved in the meantime) and some kind of "locking" mechanism to avoid multiple DigiKam instances working on the same DB and files which would cause big evil. But I didn't investigate that for quite a long time (other "projects" being more important). So back to topic: No need for an updated AppImage from my side, as I got it running via the TCP/IP approach suggested by Maik. If it could work by finding the local socket (outside of the AppImage) it would be added value/less strange, but on that point personally I could switch to TCP/IP all the time. Does that clarify things? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 388351] New: AppImage is not compatible with firejail
https://bugs.kde.org/show_bug.cgi?id=388351 Bug ID: 388351 Summary: AppImage is not compatible with firejail Product: digikam Version: 5.8.0 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: Bundle-AppImage Assignee: digikam-bugs-n...@kde.org Reporter: bbc.qui...@gmx.de Target Milestone: --- Using the latest version of appimage for linux digikam-5.8.0-20171229T043903-x86-64.appimage it does not work with firejail: firejail --appimage digikam-5.8.0-20171229T043903-x86-64.appimage Reading profile /etc/firejail/default.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-passwdmgr.inc Reading profile /etc/firejail/disable-programs.inc ** Note: you can use --noprofile to disable default.profile ** Parent pid 11784, child pid 11789 Dropping all Linux capabilities and enforcing default seccomp filter Child process initialized in 17.96 ms /bin/bash: /run/firejail/appimage/.appimage-11784/AppRun: cannot execute binary file: Exec format error Parent is shutting down, bye... AppImage unmounted The package itself works without firejail and other appimage packages for x86-64 work with firejail (e.g. FreeCAD). I tried to search for similar cases, but found nothing promising. Debug mode of firejail does not spit out more detailed information. Comparison of AppImage files does not show dramatic differences as well: $file digikam-5.8.0-20171229T043903-x86-64.appimage digikam-5.8.0-20171229T043903-x86-64.appimage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=d629f6099d2344ad82818172add1d38c5e11bc6d, stripped $file FreeCAD-0.17.git201712210014.glibc-x86_64.AppImage FreeCAD-0.17.git201712210014.glibc-x86_64.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, stripped -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 379987] UpdateSchemaFromV7ToV8: Unable to execute query (MySQL specific)
https://bugs.kde.org/show_bug.cgi?id=379987
--- Comment #9 from Quincy <bbc.qui...@gmx.de> ---
I'n not in a hurry given the raised points. A new image with localhost/socket
support does not change things.
@Maik: I already went for a more manual (and cumbersome) step-by-step approach
to migrate V7->8:
- doing the intended things ("IF EXISTS") by hand if suitable and commenting
these things in dbconfig.xml
- delete some entries in the Images table because of foreign key violations
(likely rubbish from older versions/crashes). I identified these via SELECT *
FROM ImageMetadata WHERE imageid in (SELECT imageid FROM `ImageMetadata` LEFT
JOIN Images ON(ImageMetadata.imageid=Images.id) WHERE Images.id IS NULL)
- creating faceDB by hand
But your suggestion sounds way easier for possible future updates and maybe
others still being stuck on V7.
@all: Have a good start into 2018
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 379987] UpdateSchemaFromV7ToV8: Unable to execute query (MySQL specific)
https://bugs.kde.org/show_bug.cgi?id=379987 --- Comment #7 from Quincy <bbc.qui...@gmx.de> --- As Maik said the new version does not solve/change this bug, so I am wondering why Gilles has posted to try the appimage to especially this bug. At least I could test the upgrade from V8 to 9 with my manually "migrated" V7->8 DB using the appimage which works without new complains. Still I am using copies of database and digikamrc, because they will be changed during the test run. I was wondering if "downgrading" afterwards will work at all. If MariaDB is the only way to go you should state that more clearly, because e.g. the documentation tab in the database settings says literally "...to be connected to a remote Mysql database server (or MariaDB)" which implies that MySQL is usable, if not the first choice. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 388345] AppImage MySQL connection issues
https://bugs.kde.org/show_bug.cgi?id=388345 --- Comment #4 from Quincy <bbc.qui...@gmx.de> --- Thanks for the quick response! Using 127.0.0.1 indeed solves the problem, but just because it does not connect using the socket at all. If you have a non-networking server (MySQL: "skip-networking") this does not help either. Therefore to answer Gilles question: digikam 5.7.0 on Qt 5.7.1 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 379987] UpdateSchemaFromV7ToV8: Unable to execute query (MySQL specific)
https://bugs.kde.org/show_bug.cgi?id=379987 --- Comment #5 from Quincy <bbc.qui...@gmx.de> --- Wanted to check the new update capabilities, but was unfortunately stopped by bug #388345. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 388345] New: AppImage MySQL connection issues
https://bugs.kde.org/show_bug.cgi?id=388345
Bug ID: 388345
Summary: AppImage MySQL connection issues
Product: digikam
Version: 5.8.0
Platform: Appimage
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: Bundle-AppImage
Assignee: digikam-bugs-n...@kde.org
Reporter: bbc.qui...@gmx.de
Target Milestone: ---
Usually I'm running digikam with MySQL server backend. For testing purposes I
tried to use digikam-5.8.0-20171229T043903-x86-64.appimage, but I cannot
connect to my database. It works with the very same settings using the
conventionally installed version, but not with the appimage. The latter one
complains:
-- digiKam AppImage Bundle
-- Use 'help' as CLI argument to know all available options
digikam.widgets: Breeze icons ressource file found
digikam.general: AlbumWatch use QFileSystemWatcher
digikam.general: Database Parameters:
Type: "QMYSQL"
DB Core Name: "digikam-appimage"
DB Thumbs Name: ""
DB Face Name: ""
Connect Options: ""
Host Name:"localhost"
Host port:3306
Internal Server: false
Internal Server Path: ""
Internal Server Serv Cmd: ""
Internal Server Init Cmd: ""
Username: "digikam-appimage"
Password: ""
digikam.dbengine: Error while opening the database. Error details [
QSqlError("2002", "QMYSQL: Unable to connect", "Can't connect to local MySQL
server through socket '/var/lib/mysql/mysql.sock' (13)") ]
The installed version goes over this and starts doing it's usual things:
digikam.general: AlbumWatch use QFileSystemWatcher
digikam.general: Database Parameters:
Type: "QMYSQL"
DB Core Name: "digikam-appimage"
DB Thumbs Name: ""
DB Face Name: ""
Connect Options: ""
Host Name:"localhost"
Host port:3306
Internal Server: false
Internal Server Path: ""
Internal Server Serv Cmd: ""
Internal Server Init Cmd: ""
Username: "digikam-appimage"
Password: ""
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 8
digikam.coredb: Core database: makeUpdates 8 to 8
Indeed there is no MySQL socket at /var/lib/mysql/mysql.sock but at
/var/run/mysqld/mysqld.sock (Gentoo standard) which is magically corrected in
the installed version.
--
You are receiving this mail because:
You are watching all bug changes.
[gwenview] [Bug 372417] Entering fullscreen will switch to other monitor when Gwenview is already maximized
https://bugs.kde.org/show_bug.cgi?id=372417 --- Comment #5 from Quincy <bbc.qui...@gmx.de> --- Now I am on Gwenview 17.04.3 / KF 5.37 / Qt 5.7.1 but the problem still persists. I am using Plasma/kwin-5.10.5 and gwenview is opened via double clicking a file in dolphin on the first screen (resolution 1440x900). This opens Gwenview also on the first screen and fullscreen mode is entered there also. Moving the window to the second screen (1600x1200) directly maximizing it by moving it to the top border and then entering fullscreen mode switches fullscreen to the first screen. If the window is moved but not maximized it works as expected. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 342427] Timing issues when large GPX file is loaded and option "Show tracks on Map" is used with GoogleMaps
https://bugs.kde.org/show_bug.cgi?id=342427 --- Comment #8 from Quincy <bbc.qui...@gmx.de> --- Ahh cool, never seen that. Regarding the bug: Behaves the same as with my "old" 5.5.0 version. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 342427] Timing issues when large GPX file is loaded and option "Show tracks on Map" is used
https://bugs.kde.org/show_bug.cgi?id=342427 --- Comment #6 from Quincy <bbc.qui...@gmx.de> --- 5.7.0 is unfortunately not yet available in my distribution. I used standard GPS correlation not the reverse one (which I never used as it seems to work on tags vs. location names). For loading there are no options at all, but the activated map was "Google Maps" at that time. With "Marble" (both "Atlas" and OSM) activated loading of the 185k waypoint file takes about 7s, de- and re-activating the tracks has no delay at all. So the described problem only occurs in conjunction with Google Maps (any map mode). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 342427] Timing issues when large GPX file is loaded and option "Show tracks on Map" is used
https://bugs.kde.org/show_bug.cgi?id=342427 --- Comment #4 from Quincy <bbc.qui...@gmx.de> --- On the very same hardware as of my initial report, but now with DigiKam 5.5.0 it now takes 11s to load a file with 185000 waypoints, and 26s to re-enable. For a smaller file (7 waypoints) it takes 4s to load and 5 to reenable. So I can still see a slowdown for the re-enabling of tracks compared to their initial loading and it is still getting worse the bigger the file is. But as it is now way faster for both actions than before we could consider this bug solved. However I'm still curious why re-enabling is slower than the original load action. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 384306] New: Option to center map on selected track
https://bugs.kde.org/show_bug.cgi?id=384306 Bug ID: 384306 Summary: Option to center map on selected track Product: digikam Version: 5.5.0 Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: Geolocation-Correlator Assignee: digikam-bugs-n...@kde.org Reporter: bbc.qui...@gmx.de Target Milestone: --- Having any actual view of the map (last status?) after opening the geocorrelation window it would be nice to be able to center and zoom the map to any loaded GPS track (e.g. right click menu on track). Otherwise one has to know where some (eventually short) track is located and search by hand (e.g. by zooming out). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 342352] Relocate "Show tracks on map" option on GUI
https://bugs.kde.org/show_bug.cgi?id=342352 Quincy <bbc.qui...@gmx.de> changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Quincy <bbc.qui...@gmx.de> --- Great, exactly as I assumed. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 379987] New: UpdateSchemaFromV7ToV8: Unable to execute query (MySQL specific)
https://bugs.kde.org/show_bug.cgi?id=379987 Bug ID: 379987 Summary: UpdateSchemaFromV7ToV8: Unable to execute query (MySQL specific) Product: digikam Version: 5.5.0 Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Database-Mysql Assignee: digikam-de...@kde.org Reporter: bbc.qui...@gmx.de Target Milestone: --- Starting digikam 5.5.0 for the first time after upgrading from (likely) 4.14 it reports the following error: 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" "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'IF EXISTS identifier' at line 2" 1064 2 Bound values: () digikam.dbengine: Error while executing DBAction [ "UpdateSchemaFromV7ToV8" ] Statement [ "ALTER TABLE AlbumRoots\n DROP INDEX IF EXISTS identifier;" ] digikam.coredb: Core database: schema update to V 8 failed! digikam.coredb: Core database: cannot process schema initialization My database is running on a local MySQL Server version 5.6.35. Obviously this part was introduced as a fix for bug #372312. According to the MySQL documentation this syntax is not supported by my MySQL version or the following one, but by MariaDB (as in the mentioned bug) and others. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 372417] Entering fullscreen will switch to other monitor
https://bugs.kde.org/show_bug.cgi?id=372417 --- Comment #3 from Quincy <bbc.qui...@gmx.de> --- At least I found a workaround: When Gwenview window is not maximized on that screen going to fullscreen mode works. It only jumps to the other screen if it is already maximized. Additionally I am not sure if this is connected to having two screens of different resolutions: First screen always catching window: 1440x900 and second screen 1600x1200 in my case -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 372417] Entering fullscreen will switch to other monitor
https://bugs.kde.org/show_bug.cgi?id=372417 Quincy <bbc.qui...@gmx.de> changed: What|Removed |Added CC||bbc.qui...@gmx.de --- Comment #1 from Quincy <bbc.qui...@gmx.de> --- I encounter the very same problem, fullscreen always jumps to one specific monitor, in my case the first one. It should maximize on the screen the window currently is on... Version 16.04.3 in my case (KDE 5.26, Qt 5.6.1) -- You are receiving this mail because: You are watching all bug changes.
