[neon] [Bug 480856] Fresh Neon install can't boot if encryption is used (20240201-0717 iso)
https://bugs.kde.org/show_bug.cgi?id=480856 --- Comment #4 from Metal450 --- More reports of this here: https://discuss.kde.org/t/disk-encryption-not-working-on-recent-neon-isos-but-is-working-on-older-images/9505 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 297922] THUMBDB : different database locations for thumbnails
https://bugs.kde.org/show_bug.cgi?id=297922 --- Comment #24 from Metal450 --- > This bug report is about having the thumbnail database as a local SQLite > database if the connection to a MySQL database is slow Ah I see. I interpreted the title "different database locations for thumbnails" to just mean different locations, not limited only to when using that specific combination of db types. > With SQLite it makes no sense to have the thumbnail database in a different > location. ...I'm not really sure how it "makes no sense." The main database is essential and is small, the thumbnail database is transient and extremely large. Most software (including Lightroom) separates cache-like data from the essential data that should be i.e. synced or backed up. I'd assume that most people want their main database backed up, but don't need to backup a big multi-gig set of thumbnails each time the software is used & the file is touched. Requiring them all to be in the same folder means any backup software will need an explicit filename exception just for this one application - rather than simply placing thumbs/cache in a separate thumb/cache location. > If they really want that, they could try a symbolic link. Doesn't work - just as Digikam will follow a symlink, so too would backup software. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 297922] THUMBDB : different database locations for thumbnails
https://bugs.kde.org/show_bug.cgi?id=297922 --- Comment #22 from Metal450 --- I'm using sqlite. Is there no way to do this with sqlite - to separate the thumbnails db file from the other 3? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 297922] THUMBDB : different database locations for thumbnails
https://bugs.kde.org/show_bug.cgi?id=297922 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #20 from Metal450 --- Can you tell us where to find the option to configure a separate location for the thumbnails-digikam.db file (to separate it from the other 3 db files)? I saw that this was marked as "completed"...but looked through all the settings dialog & couldn't find the option anywhere. Thanks in advace -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 480856] Fresh Neon install can't boot if encryption is used (20240201-0717 iso)
https://bugs.kde.org/show_bug.cgi?id=480856 --- Comment #1 from Metal450 --- Addendum: it looks like others are experiencing the same - multiple posts about this on Reddit in the past 5 days: https://www.reddit.com/r/kdeneon/comments/1aenouy/kde_neon_wont_boot_after_fresh_install_cryptsetup/ -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 480856] New: Fresh Neon install can't boot if encryption is used (20240201-0717 iso)
https://bugs.kde.org/show_bug.cgi?id=480856 Bug ID: 480856 Summary: Fresh Neon install can't boot if encryption is used (20240201-0717 iso) Classification: KDE Neon Product: neon Version: unspecified Platform: Neon OS: Linux Status: REPORTED Severity: major Priority: NOR Component: Live/Install images Assignee: neon-b...@kde.org Reporter: metal...@gmail.com CC: j...@jriddell.org, neon-b...@kde.org, sit...@kde.org Target Milestone: --- I'm trying to do a fresh install of KDE Neon, but the current installer appears to be broken. I've been running a previous version of Neon for several years, & its installer works without issue. The previous working ISO was 20220324-0945; the current failing one is 20240201-0717. Rero: 1) Download the ISO, copy to USB & boot live 2) Once booted, connect to wifi & launch the installer 3) On the Partitions step, choose "Manual Partitioning": * Select free space->Create. File System=btrfs, Encrypt=checked, Mount Point=/ * As it's a multi-boot system, I have an existing fat32 efi partition. Select that partition->Edit. Set its mount point to /boot/efi. 4) Proceed with the install 5) Reboot. Result: It prompts for the password, accepts the password, shows the Grub menu, I select Neon, then it fails to boot. The screen shows `cryptsetup: ERROR luks-(uuid): maximum number of tries exceeded`. If I hit a key to show the text, it reveals: ``` /bin/cat: /crypto_keyfile.bin: No such file or directory Nothing to read on input. cryptsetup: ERROR: luks-(uuid): cryptsetup failed, bad password or options? (...repeating over and over until it gives up & drops to shell) ``` * This was the exact install process that worked properly with the previous version of Neon. Just to sanity check my steps, I went back & fully reinstalled the previous 20220324-0945 ISO. It worked without issue. So this definitely seems to be a regression. * I read online that the crrent installer is only broken with encryption & btrfs, so I tried to repeat the process using ext4 rather than btrfs. The same error occurred. * Rather than doing Manual partitioning, I also tried choosing "Replace a partition", and just giving it the partition I intended to use as "/" (aka I didn't explicitly give it /boot/efi). It did not work. Same issue. * I tried doing the same, but *not* selecting encryption (definitely not an option for real-world use, but just out of curiosity). That worked. So it seems to be unable to install with encryption. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463197] UI frequently locks up / unresponsive with large collection
https://bugs.kde.org/show_bug.cgi?id=463197 --- Comment #18 from Metal450 --- (In reply to Metal450 from comment #15) > (In reply to caulier.gilles from comment #14) > > @Metal450, > > > > This problem still reproducible with the new digiKam 8.2.0 pre-release > > Windows > > installer available at usual place: > > > > https://files.kde.org/digikam/ > > > > This new bundle is based on last Qt framework 5.15.11 and KDE framework > > 5.110. > > > > Thanks in advance > > > > Gilles Caulier > > Just installed it & gave it a try; the behavior is identical. The UI still > locks up & becomes unresponsive the moment you try to use either of those > tabs. > > Any thoughts on my responses from 10 months ago, & follow-up 6 months ago? Any thoughts on my responses from 13 months ago, & follow-up 9 months ago? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463197] UI frequently locks up / unresponsive with large collection
https://bugs.kde.org/show_bug.cgi?id=463197 --- Comment #17 from Metal450 --- (In reply to Peter from comment #16) > A search interrupt button would be nice. A button wouldn't do anything if the UI thread is already locked up & not processing user inputs. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463197] UI frequently locks up / unresponsive with large collection
https://bugs.kde.org/show_bug.cgi?id=463197 --- Comment #15 from Metal450 --- (In reply to caulier.gilles from comment #14) > @Metal450, > > This problem still reproducible with the new digiKam 8.2.0 pre-release > Windows > installer available at usual place: > > https://files.kde.org/digikam/ > > This new bundle is based on last Qt framework 5.15.11 and KDE framework > 5.110. > > Thanks in advance > > Gilles Caulier Just installed it & gave it a try; the behavior is identical. The UI still locks up & becomes unresponsive the moment you try to use either of those tabs. Any thoughts on my responses from 10 months ago, & follow-up 6 months ago? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 416087] Optionally find hidden files using Dolphin's standard search
https://bugs.kde.org/show_bug.cgi?id=416087 --- Comment #15 from Metal450 --- (In reply to ttrovo from comment #14) > Additional link to a popular reddit topic where people discuss search in > Dolphin and consider it to be "broken". > https://www.reddit.com/r/kde/comments/smlevb/ > dolphin_search_doesnt_work_well_any_way_to_make/ > > Maybe the the issue should be marked as a bug, as a lot of people really > consider it a bug. Almost nobody will say that it is not a bug not to find > files when they exist. Agreed. Clearly this is not desired or even remotely intuitive behavior - not really sure why it's being ignored... -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463197] UI frequently locks up / unresponsive with large collection
https://bugs.kde.org/show_bug.cgi?id=463197 --- Comment #13 from Metal450 --- Just saw that 8.0.0 was officially released (congrats). Unfortunately, search still remains unusable (locks up the entire UI for several minutes just attempting to enter that tab). Any comment on my message from 4 months ago? I thought I provided some pretty valid suggestions there. In any event, even if properly threading/batching it is a bigger project, at the very least it seems like by default it could avoid trying to show every item in the library when entering that tab, so you can at least get into that UI without it completely locking the application. Then if you do a search that returns i.e. 500 results, it only needs to populate 500. Rather than the current situation, where it first populates the entire library before you can even attempt the search you intended to do (and then waiting again while it locks up the UI to populate the result of the search). Cutting out that first step seems like it would at least partially alleviate how this is implemented (just leave the pane empty until an explicit search is performed). As it stands, that pane is really truly not usable. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463577] Exiv2 alters unrelated DJI Exif metadata when editing tags.
https://bugs.kde.org/show_bug.cgi?id=463577 --- Comment #3 from Metal450 --- (In reply to caulier.gilles from comment #1) > It's probably a bug in Exiv2 metadata engine which do not deal with DJI Exif > section from images. > > What's happen if you use ExifTool instead Exiv2 as metadata engine in > digiKam Setup/Metadata page ? Can you reproduce the dysfunction ? > > https://docs.digikam.org/en/setup_application/metadata_settings. > html#behavior-settings > > Gilles Caulier If you're referring to checking the option "Delegate to ExifTool backend all operations to write metadata to files", then yeah, I can confirm that it's still destructive to those metadata values. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463577] New: digiKam alters unrelated metadata when editing tags
https://bugs.kde.org/show_bug.cgi?id=463577 Bug ID: 463577 Summary: digiKam alters unrelated metadata when editing tags Classification: Applications Product: digikam Version: 8.0.0 Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: Metadata-Exif Assignee: digikam-bugs-n...@kde.org Reporter: metal...@gmail.com Target Milestone: --- Created attachment 154874 --> https://bugs.kde.org/attachment.cgi?id=154874=edit test image SUMMARY Upon using digiKam to remove a tag from a jpeg, I found that a large number of other metadata tags were altered. This includesIn particular, vendor-specific "DJI" exif tags (containing flight data from the DJI drone). STEPS TO REPRODUCE 1. Grab the attached jpeg, and use exiftool to dump all of its metadata to a text file 2. Import the jpeg into digiKam 3. Uncheck one of its tags, i.e. "0.0.1" 4. Apply (aka write changes into the jpeg) 5. Use exiftool to again dump all of its metadata to a text file 6. Diff the results. A bunch of metadata unrelated to tags/keywords has changed - i.e. "DJI 0x000c", "DJI 0x000d", "DJI 0x0013", etc have all had their values changed. The issue only seems to allow me to attach one file, so here's a second screenshot showing the diff: https://jiij.cc/snaps/2022-12-28_20.57.34.png OBSERVED RESULT Vendor-specific metadata has been altered EXPECTED RESULT Only metadata related to the tags should be altered; other data should not be modified/lost. SOFTWARE/OS VERSIONS Windows: 10 ADDITIONAL INFORMATION Tested on the latest weekly 8.0.0-beta1 build -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463197] UI frequently locks up / unresponsive with large collection
https://bugs.kde.org/show_bug.cgi?id=463197
--- Comment #12 from Metal450 ---
(In reply to caulier.gilles from comment #11)
> For the rest, especially the GUI operations, X11 under Linux is not
> re-entrant, and threading cannot be used.
1) I see. So I'm assuming that in this case, it has already been determined
that the operation which locks up the software is purely the UI calls
themselves - in other words, there isn't anything else that could be pushed to
another thread?
2) For what it's worth, in C#/WinForms, you also cannot directly perform any UI
updates from background threads - however, in effect you can accomplish the
same with something like the following. Not sure if something similar exists in
qt:
// This function runs in a background worker thread
private void backgroundWorker_DoWork(object sender, DoWorkEventArgs e){
// If you need to update the UI, you cannot do it directly from
here - this would not be threadsafe/could crash:
//uiElement.Text = "whatever"
// However, you can safely accomplish the same by using a
MethodInvoker to dispatch it back to the UI thread:
MethodInvoker invoker1 = new MethodInvoker(delegate ()
{
// Can manipulate any UI elements here. So effectively the
operation was "originated" from the background worker, but the actual update
// gets queued to safely occur on the main UI thread
uiElement.Text = "whatever";
});
this.BeginInvoke(invoker1);
}
3) Even if there's no way to put it on another thread, it really seems like
there should be creative solutions that would prevent it from locking up,
regardless of the number of images. For example, break up the images into
batches, and only add at most "maxN" items to the UI per invocation, before
returning control to the message loop so that user interaction can still take
place. I'm not directly familiar with how qt's message loop is implemented,
but:
* Does that just mean inserting a brief sleep() or similar in the code that
adds all the image thumbnails to the UI, so any user interaction messages could
be processed before continuing?
* Or perhaps using a custom "SET_UI_IMAGES" message, which gets processed by
adding maxN images to the UI, and re-queuing the same message type until all
images have been added? (and when the user scrolls to a particular part of the
scrollable container, on the next iteration of SET_UI_IMAGES, it would
prioritize adding load the corresponding subset of maxN to the UI)
Basically, just some way to hand control back to the main message loop often
enough that this long process doesn't have to run all in one go - and thus
regardless of the total number of images, it need not block everything else
until it's done.
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #18 from Metal450 --- Aha, perfect, thanks! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463197] UI frequently locks up / unresponsive with large collection
https://bugs.kde.org/show_bug.cgi?id=463197 --- Comment #10 from Metal450 --- Addendum: It seems like the Labels tab isn't really usable either - similar to search, it locks the whole application up as soon as I enter :/ Does the above make sense? Ie. Shouldn't anything that scales linearly with the number of photos be offloaded to a different thread? Then the main application message loop couldn't get blocked regardless of the # of photos - just like it doesn't in LR, for other O(n) operation in digiKam (ie reading metadata etc). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #16 from Metal450 --- (In reply to caulier.gilles from comment #15) > Hi Maik and Merry Christmas, > > Yes, i'm busy bu i advance well > > https://docs.digikam.org/en/index.html > > I hope to finalize online doc in few days... > > I will rebuild the Windows bundle tomorrow morning, no problem. > > Gilles No rush, take your time! I was just curious where to find them, more generally - sounds like I did have the right spot :) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #14 from Metal450 --- (In reply to Maik Qualmann from comment #13) > Normally, Gilles creates weekly snapshots. However, he is very busy at the > moment, restructuring and porting the digiKam documentation. I don't think > he'll be anywhere near the build machines over the holidays either. A bit > patience... > > Maik Ah OK, so I guess they'll appear at that same place when available then? Just wasn't sure if there was somewhere else for 8.x snapshots. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #12 from Metal450 --- (In reply to Maik Qualmann from comment #11) > The metadata viewer only displays the entry of a single selected image. In > the case of a multi-selection or maintenance tool process, we would have to > examine the images for this beforehand. Ohh I see - so that's literally directly viewing the metadata in the file, not in the catalog (and the catalog only stores a more generalized subset of meta - not knowing that "tags" came from XP specifically). > Writing an empty tags list now correctly removes XPKeywords. If you don't > have write with ExifTool enabled, XPKeywords will be removed in all cases. If > you have enabled writing with ExifTool, XPKeywords will be written correctly. Gotcha, great! So no settings changes needed. > My research resulted in a bug report for a Windows photo program, either they > also use Exiv2 in the background, since XPKeywords is also always deleted. > Also the author of ExifTool writes that one should avoid the XP* metadata. Yeah, I mean I wouldn't use it myself. But since one doesn't have control over what others might have done to photos before they were received, I just wanted to make sure it was possible to reliably work with tags, more generally, even if someone else has already used XP tags. Sounds like this fix now does it :) Sorry, quick semi-related question: I'm using v8.0.0 (per our other discussion related to sharing the db between win+linux), but it looks like the weekly builds are for 7.10, not 8.0 (https://files.kde.org/digikam/). Is there somewhere with weekly builds for 8.0, that contain all the latest patches? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #10 from Metal450 --- (In reply to Maik Qualmann from comment #7) > Giving a warning every time isn't really practical. So currently the software has that toast UI, i.e. "Updating database - process is done." I was thinking a similar pop-up when applying from database to file, i.e. "Writing files from database - xxx items may not have been successful." Something like that. > On the one hand we don't get an error message from Exiv2 in this case. But the digiKam catalog already knows the files have that particular metadata tag: https://jiij.cc/snaps/2022-12-25_09.17.56.png. So it shouldn't need an explicit error for Exiv2, right? Just knowing that "we're writing tags to a file" and "that file has the XP* tag" is enough to infer that "this file may not be written correctly." > On the other hand, we would have to read all the metadata of the images to > determine which ones contain the XP* tags, which would lead to a severe loss > of performance, especially on network drives. Why would it need to read all the metadata from files again? The catalog clearly already knows the metadata is there (that's how it knew that tag existed in the first place, and made it available to be unchecked in the "Captions" pane). So no need to re-read from disk again...? > We can actually write the XP* tags with ExifTool in the same step as the > modified metadata container. In a first patch we will generally remove the > XP* tags when writing new tags. > add write support for XP* metadata when Exiftool writing is enabled > By default, the legacy XP* metadata is disabled in a new config. So to clarify, to avoid the issue, I need to explicitly enable "Settings->Metadata->Delegate to ExifTool all backend operations to write metadata to files"? If so, any other ramification/side effect, besides this bug not occurring? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #6 from Metal450 --- Those options all work as a one-off fix for a particular images/images (or for users who somehow become aware of the issue), but more broadly, the software should really provide some warning. Ie just a simple check to see if that tag is there, and if so, the confirmation toast should let the user know that their changes may have not been applied. Otherwise, anytime someone copies a bunch of photos from a friend/relative/etc, and attempts to just work with tags normally, it's not at all obvious that half the actions taken were actually ignored. If or until there's a true fix, why not just show: "Warning: 12 of the images written contained XP metadata, so your changes may not have applied. Please see (link to this issue, or to the most relevant)." -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #4 from Metal450 --- Is the output of exiftool enough? Let me know if not & I'll send the picture itself, but exiftool's output is below. I do see mention of "XP Keywords." However, if there's a known issue that a particular type of keyword will not be properly written, shouldn't the software raise an error/warning, rather than appearing to succeed but just silently failing? I spent quite some time going through & cleaning up tags before (much later) uncovering that all that time had actually been wasted, and nothing was actually being updated. I found it completely by chance when I diffed an image for other reasons, then re-read from metadata and suddenly every single tag I'd just removed was back. So apparently I hadn't actually done anything. ``` ExifTool Version Number : 12.51 File Name : Mich visit 10-2010 003-2.JPG Directory : . File Size : 969 kB File Modification Date/Time : 2022:12:22 22:57:20-08:00 File Access Date/Time : 2022:12:23 08:38:53-08:00 File Creation Date/Time : 2022:12:17 19:44:13-08:00 File Permissions: -rw-rw-rw- File Type : JPEG File Type Extension : jpg MIME Type : image/jpeg Exif Byte Order : Big-endian (Motorola, MM) Make: SONY Camera Model Name : DSC-W70 Orientation : Horizontal (normal) X Resolution: 72 Y Resolution: 72 Resolution Unit : inches Software: Adobe Photoshop CS5 Windows Modify Date : 2010:10:27 09:21:26 Y Cb Cr Positioning : Co-sited XP Keywords : Mich visit 10-2010 PrintIM Version : 0300 Exposure Time : 1/50 F Number: 5.2 Exposure Program: Program AE ISO : 160 Exif Version: 0221 Date/Time Original : 2010:09:23 17:56:36 Create Date : 2010:09:23 17:56:36 Components Configuration: Y, Cb, Cr, - Compressed Bits Per Pixel : 8 Exposure Compensation : +1.7 Max Aperture Value : 2.8 Metering Mode : Multi-segment Light Source: Unknown Flash : On, Return detected Focal Length: 18.9 mm Flashpix Version: 0100 Color Space : sRGB Exif Image Width: 2304 Exif Image Height : 3072 Interoperability Version: 0100 File Source : Digital Camera Scene Type : Directly photographed Custom Rendered : Normal Exposure Mode : Manual White Balance : Auto Scene Capture Type : Standard Contrast: High Saturation : High Sharpness : Normal Padding : (Binary data 2060 bytes, use -b option to extract) Offset Schema : 4200 Compression : JPEG (old-style) Thumbnail Offset: 5030 Thumbnail Length: 6889 XMP Toolkit : XMP Core 4.4.0-Exiv2 Creator Tool: Microsoft Windows Photo Gallery 6.0.6001.18000 Metadata Date : 2010:10:27 09:21:26-07:00 Format : image/jpeg Color Mode : RGB ICC Profile Name: sRGB IEC61966-2.1 Instance ID : xmp.iid:0B6D863FE6E1DF11964DF8DAF7BB095B Document ID : xmp.did:0B6D863FE6E1DF11964DF8DAF7BB095B Original Document ID: xmp.did:0B6D863FE6E1DF11964DF8DAF7BB095B Description : History Action : saved History Instance ID : xmp.iid:0B6D863FE6E1DF11964DF8DAF7BB095B History When: 2010:10:27 09:21:26-07:00 History Software Agent : Adobe Photoshop CS5 Windows History Changed : / Profile CMM Type: Linotronic Profile Version : 2.1.0 Profile Class : Display Device Profile Color Space Data: RGB Profile Connection Space: XYZ Profile Date Time : 1998:02:09 06:49:00 Profile File Signature : acsp Primary Platform: Microsoft Corporation CMM Flags : Not Embedded, Independent Device Manufacturer : Hewlett-Packard Device Model: sRGB Device Attributes : Reflective, Glossy, Positive, Color Rendering Intent: Perceptual Connection Space Illuminant : 0.9642 1 0.82491 Profile Creator
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #2 from Metal450 --- > Whether the modification date changes depends on the metadata settings. Yeah, that was desired - was just mentioning it to illustrate that digiKam had actually done something to the file (even though no binary changes took place). > You enabled it to update back to the previous one. Not sure what you mean by this...? > We need a DebugView log [11176] digikam.metaengine: Loading metadata with "Exiv2" backend from "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.general: Writing tags [11176] digikam.general: Delete all keywords [11176] digikam.metaengine: "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" ==> New Iptc Keywords: () [11176] digikam.metaengine: MetaEngine::metadataWritingMode 0 [11176] digikam.metaengine: Will write Metadata to file "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.metaengine: wroteComment: true [11176] digikam.metaengine: wroteEXIF: true [11176] digikam.metaengine: wroteIPTC: true [11176] digikam.metaengine: wroteXMP: true [11176] digikam.metaengine: Metadata for file "Mich visit 10-2010 003-2.JPG" written to file. [11176] digikam.metaengine: Loading metadata with "Exiv2" backend from "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.dimg: "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" : "JPEG" file identified [11176] digikam.database: Scanning took 6 ms [11176] digikam.database: Finishing took 7 ms [11176] digikam.metaengine: Loading metadata with "Exiv2" backend from "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.general: Trying to get thumbnail from "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" ( "image" ) [11176] digikam.general: Trying to get thumbnail with Exiv2 for "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.metaengine: Loading metadata with "Exiv2" backend from "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.general: Trying to get thumbnail from "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" ( "image" ) [11176] digikam.general: Trying to get thumbnail with Exiv2 for "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.general: Trying to get thumbnail with DImg preview for "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.general: Trying to get thumbnail with DImg preview for "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.dimg: "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" : "JPEG" file identified [11176] digikam.dimg: "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" : "JPEG" file identified [11176] digikam.general: Using 8 CPU core to run threads [11176] digikam.general: Using 8 CPU core to run threads [11176] digikam.general: Action Thread run 1 new jobs [11176] digikam.general: Action Thread run 1 new jobs [11176] digikam.general: One job is done [11176] digikam.general: Cancel Main Thread [11176] digikam.general: One job is done [11176] digikam.general: Cancel Main Thread -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] New: Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 Bug ID: 463378 Summary: Applied Tags Don't Get Written To File? Classification: Applications Product: digikam Version: 8.0.0 Platform: Other OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Tags-Keywords Assignee: digikam-bugs-n...@kde.org Reporter: metal...@gmail.com Target Milestone: --- SUMMARY Sometimes when I remove tags from a given file, they don't actually seem to get updated. I uncheck the tag, click Apply, and the file modification date does get updated (showing that digiKam actually did "touch" the file). However, if I diff the file against a backup, no binary changes have taken place, and if I "Reread Metadata From File", digiKam reveals that the tag was actually never removed from the file. Easiest to illustrate with a screencast: https://jiij.cc/snaps/2022-12-22_21.50.36.mp4 STEPS TO REPRODUCE 1. Settings->Configure digiKam->Metadata->Behavior->Check all the checkboxes under "Write This Information to the Metadata" (all other settings on that dialog are as default). 2. Navigate to a photo that has a tag. Note its modification date. 3. Make a backup copy of that photo somewhere 4. On the right of digiKam, go to Captions->Tags 5. Untick the tag, then click "Apply" at the bottom 6. Note that the file modification date has been updated, as expected. 7. Binary diff the photo against its backup. They are identical - the tag was not actually removed. 8. Item->Reread Metadata From File. The tag now reappears in the digiKam UI. SOFTWARE/OS VERSIONS Windows: 7 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463197] UI frequently locks up / unresponsive with large collection
https://bugs.kde.org/show_bug.cgi?id=463197 --- Comment #9 from Metal450 --- It seems like the more generalized solution would be i.e.: 1) Set the total height of the scrollable container to the correct final height; 2) Start *asynchronously* loading/filling out the thumbnails (i.e. not on the same thread as is used for processing user interaction) 3) As the user scrolls, reprioritize loading so that the images near the currently-visible view are loaded first ...Until done. By pre-setting the correct scroll height right from the bat, the user will be able to drag directly to any vertical offset (i.e. no need to scroll to the bottom & wait for the current batch to load before they can scroll farther). And by loading not on the thread used for user interaction, it should never lockup the UI, no matter how many there are to load. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463180] Reread Metadata From File doesn't cleanup Tags
https://bugs.kde.org/show_bug.cgi?id=463180 Metal450 changed: What|Removed |Added Resolution|--- |NOT A BUG Status|REPORTED|RESOLVED --- Comment #2 from Metal450 --- (In reply to Maik Qualmann from comment #1) > No, the tag definitely disappears after reading in the metadata again. If > writing is activated e.g. for tags, the corresponding database entries are > previously cleaned in digiKam-8.0.0. Since I know that you are using 2 > digiKam instances, I suspect that you have not enabled tag writing in the > reading digiKam instance. > digiKam-8.0.0 only cleans up the database when reading again if writing the > relevant metadata is also activated. > > Maik This test was done in just one instance, so that's not the issue - but hmm, you're right, it seems like I now am *not* able to repro the issue with just the above steps. When I observed the behavior, I had done a number of tag adds, and then reverted one file from backup, but couldn't seem to get digiKam to reflect that that the tags had been removed. It was admittedly a longer series of steps that led to that though, which I simplifed to the above. Was sure I'd reproduced it just like that, but in this moment I no longer can, so perhaps it was one of the prior actions that ultimately led to the situation. Anyway, since it seems my steps aren't the proper repro, will close this now. Can always re-report in the event that I see it again & can provide better repro steps. Thanks for the quick replies! :) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463197] UI frequently locks up / unresponsive with large collection
https://bugs.kde.org/show_bug.cgi?id=463197 --- Comment #4 from Metal450 --- (In reply to Maik Qualmann from comment #2) > See also this Bug 411099. I see in your video that the search only shows > about 3000 items. There should be no freezing. Which database type do you > use MySQL or SQLite? Local or server? I'm using sqlite, local. If you're referring to the number 3,364 in the section header, that's just that "section" of the results (i.e. that "leaf" in the album tree). It seems to group results by albums, so if you scroll down, there are other groups with other portions of the results. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463197] UI frequently locks up / unresponsive with large collection
https://bugs.kde.org/show_bug.cgi?id=463197 --- Comment #3 from Metal450 --- (In reply to Maik Qualmann from comment #1) > Showing items in sub-albums is of course problematic when you select the top > level album. In the worst case, 250k items are then loaded into the view, > which just takes time. Hmm, that's how I've always used Lightroom though, & never seen any lag at all - certainly no lockups of the entire UI. (In reply to Maik Qualmann from comment #1) > I've already experimented with loading items > dynamically and only as many as fit in the view. The downside is you can't > even quickly scroll to the bottom. As with some websites, only the next > section is then loaded. Looks like what LR does is it immediately reserves the "spots" for the thumbnails, but if you scroll very quickly, they appear as either grey empty boxes or ultra low-res thumbnails. Then it fills out the actual thumbnails after a moment or two. So essentially it loads on-demand, but you *can* scroll immediately to the very bottom (i.e. you don't have to wait for any next section to load before you can scroll farther). Here's a video: https://jiij.cc/snaps/2022-12-18_09.42.06.mp4 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463197] New: UI frequently locks up / unresponsive with large collection
https://bugs.kde.org/show_bug.cgi?id=463197 Bug ID: 463197 Summary: UI frequently locks up / unresponsive with large collection Classification: Applications Product: digikam Version: 8.0.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Albums-IconView Assignee: digikam-bugs-n...@kde.org Reporter: metal...@gmail.com Target Milestone: --- SUMMARY I'm a new digiKam user, migrating over from Lightroom. Upon importing my full collection (~250k photos & videos; majority are jpegs), I immediately notice that the application seems to "lock up" very frequently. This is something I never experienced previously with Lightroom. The severity of these UI lockups seem to correspond directly to the number of images involved; it's as if the software is doing O(n) operations on the photos directly in the UI thread. It's consistently reproducible, i.e.: STEPS TO REPRODUCE, 1 1. Add a large collection (~250k items), wait for it to complete 2. Press Control+F to initiate a search 3. UI locks up & becomes unresponsive for nearly 60 seconds. Here's a video showing this behavior: https://jiij.cc/snaps/2022-12-18_08.33.03.mp4 . This seems to make "search" nearly unusable. STEPS TO REPRODUCE, 2 1. Add a large collection (~250k items), wait for it to complete 2. View->Include Album Sub-Tree=On 3. Highlight the top-level album 4. UI locks up & becomes unresponsive for nearly 60 seconds. Here's a video showing this behavior: https://jiij.cc/snaps/2022-12-18_08.45.30.mp4 5. Any other operations - i.e. changing the sort order, etc - will again lockup the UI. OBSERVED RESULT DigiKam constantly locks up & becomes unusable. EXPECTED RESULT Long operations to be performed on a background thread, so that the UI can remain responsive irrespective of the number of items being shown. With the same collection of items, I never observed such lockup in LR - UI operation was always smooth. SOFTWARE/OS VERSIONS Windows: 7 ADDITIONAL INFORMATION Reproduced on both 7.9.0 and 8.0.0-beta1 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463180] New: Reread Metadata From File doesn't cleanup Tags
https://bugs.kde.org/show_bug.cgi?id=463180 Bug ID: 463180 Summary: Reread Metadata From File doesn't cleanup Tags Classification: Applications Product: digikam Version: 8.0.0 Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: Tags-Keywords Assignee: digikam-bugs-n...@kde.org Reporter: metal...@gmail.com Target Milestone: --- SUMMARY If I add a tag in digiKam, then revert the file, then Reread Metadata from File, digiKam still shows the added tag, even though it is no longer present in the file on disk. Expectation is that this would bring digiKam's database back in sync with the on-disk data. STEPS TO REPRODUCE 1) View a jpeg in digikam 2) Make a backup copy of the file somewhere on disk (i.e. from outside of digiKam) 3) In digiKam, add a tag, i.e. "Test". Apply, with metadata writing to file enabled. 4) On disk, replace the file that was tagged by digiKam with the backup (aka "revert the change from backup") 5) In digiKam, select the file & "Reread Metadata from File" 6) digiKam still shows that the photo has the "Test" tag, even though it does not. It is shown in the tags panel on the left, as well as in Captions->Tags panel on the right. Conclusion: It appears as though "Reread metadata from Files" is not rereading the tags? OBSERVED RESULT digiKam still shows the tag, despite it having been reverted on-disk & then having done "reread metadata from files" EXPECTED RESULT digiKam should no longer show the tag, as it is no longer present int he jpeg SOFTWARE/OS VERSIONS Windows: 7 ADDITIONAL INFORMATION Tested in digiKam 8.0.0-beta1 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 267131] SETUP : digiKam config and data cannot be moved, absolute paths embedded in database and digikamrc
https://bugs.kde.org/show_bug.cgi?id=267131 --- Comment #27 from Metal450 --- Sorry, nevermind, I found it. I thought the "refresh" icon was for refresh (it's the same icon as when you right-click an album & select "Refresh" - turns out that on this dialog, the icon means "switch location." Got it & done, thanks! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 267131] SETUP : digiKam config and data cannot be moved, absolute paths embedded in database and digikamrc
https://bugs.kde.org/show_bug.cgi?id=267131 --- Comment #26 from Metal450 --- Apologies - I'm giving 8.0.0 a try, and I can't seem to find the option to move the existing collection from Local to Network. When adding a new Network collection from scratch, I do see the new "+" button, "Append a path to the collection." But I'm not sure how to "switch" my current Local connection to Network. If I remove Local & re-add the same path as Network, it does start a full re-scan (I backed up my previous db before trying). I tried i.e. dragging that entry from "Local" to "Network" - just a guess - but that doesn't work. Could you specify where is the UI to switch a Local collection to Network? Thanks again for all the replies -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 267131] SETUP : digiKam config and data cannot be moved, absolute paths embedded in database and digikamrc
https://bugs.kde.org/show_bug.cgi?id=267131 --- Comment #24 from Metal450 --- Cool - I didn't see that in v7 stable, perhaps it's a new option in v8. I just found your other comment here https://bugs.kde.org/show_bug.cgi?id=456749#c4 - just curious, is the 8.0 feature simply a UI for appending a 2nd mountpoint query arg in the sqlite db? So I could effectively accomplish the exact same, while still using the v7 stable version? Or does v8 actually have other related fixes, so it's better to use v8 pre-release, even if it might be less stable? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 267131] SETUP : digiKam config and data cannot be moved, absolute paths embedded in database and digikamrc
https://bugs.kde.org/show_bug.cgi?id=267131 --- Comment #22 from Metal450 --- Ah, very cool! So even if the images are technically stored in a shared partition of the internal local ssd, I should add it as "Collections on Network Shares"? (Meaning that if I have an existing Local Collection, I should remove that, & reestablish the same data as Collections on Network Shares?) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 190933] Wish to force selection of root directory in CLI without changing database
https://bugs.kde.org/show_bug.cgi?id=190933 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #5 from Metal450 --- Did this ever get addressed? I'm in the same situation: dual boot Windows+Linux machine, wishing to use Digikam on both (they share an ntfs partition), but without needing to keep two duplicate/redundant databases+thumbnails for what is ultimately the same image collection. Typical solution is to have data (in this case albums) be specified relative to a customizeable base path, or relative to the db location. Is there any solution for this, or must one have 2 duplicate copies of all of Digikam's data? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 267131] SETUP : digiKam config and data cannot be moved, absolute paths embedded in database and digikamrc
https://bugs.kde.org/show_bug.cgi?id=267131 --- Comment #20 from Metal450 --- Edit: another common solution is to specify paths relative to the database location, i.e. ../../photos, which would also allow for the same. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 267131] SETUP : digiKam config and data cannot be moved, absolute paths embedded in database and digikamrc
https://bugs.kde.org/show_bug.cgi?id=267131 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #19 from Metal450 --- (In reply to Simon from comment #16) > Yes this is still the same. There is no way to move a collection. The > location of a collection is stored in the database, so it has to be manually > adjusted in the database. Currently digikam sees that all files vanished, so > deletes them in database and the only thing you can do is creating a new > collection at the new location, obviously losing all information stored in > the database. A solution within the current framework would be a function > within digikam to move a collection. > In my opinion much better would be to take a different approach at storing > collection locations: Keep them separate from the database either in the > existing or a new configuration file. That means all the paths in the > database should be relative to root and the path to root is stored in this > configuration file. This allows for easily changing the location of a > collection and even for two digikam instances to share a database (not > simultaneously, of course, but if that is a worry, that should be solved by > locking). A use case would be if data and database were shared over a > network and both could be accessed on different computers. Has this been addressed yet? In particular, I'm interested in: "all the paths in the database should be relative to root and the path to root is stored in this configuration file" - for the purpose of sharing one database on a WIn+Linux dual boot machine, rather than needing to maintain double databases & double thumbnails for what is really the same photo collection. For other software, this is how it has always worked: I specify a base path, and as all other paths are relative, the same database can be used by both. -- You are receiving this mail because: You are watching all bug changes.
[kiofuse] [Bug 75324] Integrate KIO Slaves into file system using FUSE gateway
https://bugs.kde.org/show_bug.cgi?id=75324 --- Comment #149 from Metal450 --- (In reply to Patrick Silva from comment #147) > see bug 436553 about VLC player Thanks for the reply. Will start following that bug instead. -- You are receiving this mail because: You are watching all bug changes.
[kiofuse] [Bug 75324] Integrate KIO Slaves into file system using FUSE gateway
https://bugs.kde.org/show_bug.cgi?id=75324 --- Comment #145 from Metal450 --- Very coincidental timing, I just installed KDE Neon 5.24 literally this weekend for this exact reason. Oddly, I wasn't even able to get VLC to work - it just shows the same error as it did in Kubuntu 20.04. That's actually the software I most want to use from smb shares - did you need to install anything extra to get it to work? kio-fuse was installed already by default. Also, looks like this bug report is closed, even though it doesn't actually work in many cases. Is there an updated/current one to follow...? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 441384] Dolphin's UI responsiveness becomes slow while counting items inside subfolders in an NTFS partition
https://bugs.kde.org/show_bug.cgi?id=441384 --- Comment #7 from Metal450 --- Addendum (this bug tracker won't let me won't let me edit my past comments...?) Tried it with kernel 5.17.2, per a previous commentor, but the issue remains. I'd also note that it's not just that Dolphin lags while it's populating the item counts, but that populating the counts itself is significantly slower. On Kubuntu, all subfolder item counts are populated nearly instantaneously. On KDE, in a long directory, they populate very slowly, one after the other. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 441384] Dolphin's UI responsiveness becomes slow while counting items inside subfolders in an NTFS partition
https://bugs.kde.org/show_bug.cgi?id=441384 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #6 from Metal450 --- Been using Kubuntu 20.04 for some time, and this issue does not exist - Dolphin is lightning fast. Just switched over to KDE Neon, & it's orders of magnitude slower on my ntfs volume - almost unusable. This definitely seems to be a regression of some sort. Kubuntu 20.04 info (doesn't exhibit this issue): KDE Plasma 5.18.7 KDE Frameworks: 5.68.0 QT: 5.12.8 Kernel: 5.4.42-050442-generic Dolphin: 19.12.3 KDE neon 5.24 (has the issue): KDE Plasma: 5.24.4 KDE Frameworks: 5.92.0 Qt: 5.15.3 Kernel: 5.13.0-39-generic -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 436806] Screen locked looping notification sound
https://bugs.kde.org/show_bug.cgi?id=436806 --- Comment #2 from Metal450 --- Here's a video showing the behavior: https://www.dropbox.com/s/xya4e5mdhw4wvcb/KDE%20Sleep%20Notification%20Bug.mp4?dl=0 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 436806] New: Screen locked looping notification sound
https://bugs.kde.org/show_bug.cgi?id=436806 Bug ID: 436806 Summary: Screen locked looping notification sound Product: frameworks-knotifications Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: metal...@gmail.com CC: kdelibs-b...@kde.org Target Milestone: --- SUMMARY If I configure a notification sound for the Screen Saver's "Screen locked" event, putting the system to sleep sometimes behaves as expected: it plays the sound once, followed by the system going to sleep. Other times, it starts looping/repeating the sound continuously until the system goes to sleep. When this looping/repeating sound is 'stuck' it can be very loud, with no way to stop it, until the system finishes going to sleep. STEPS TO REPRODUCE 1. System Settings->Notifications->Configure->Screen Saver->Configure Events->Screen locked->Play a sound. I chose /usr/share/sounds/Oxygen-Im-Highlight-Msg.ogg, but I assume any short/loud sound would suffice. 2. Put the system to sleep 3. If the behavior is as expected (sound plays once), try waking up the system & trying again. The bug is sporadic (it may happen i.e. 1 out of 4 times when putting the system to sleep). OBSERVED RESULT Sometimes the sound plays once, as expected. Other times, the sound gets stuck in a buggy-sounding loop, that continues repeating until the system finishes going to sleep (usually a second or two, but can be as long as 10 seconds). EXPECTED RESULT The sound should only play once, not get stuck in a repeating loop. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 406506] Wish - Show metadata of files stored on locations non-indexed by baloo in details view mode
https://bugs.kde.org/show_bug.cgi?id=406506 --- Comment #17 from Metal450 --- (In reply to tagwerk19 from comment #16) > (In reply to Metal450 from comment #11) > > > ... those shouldn't be indexed. > > You could possibly imagine a future where an index is built and held on the > remote/removeable filesystem and is queried when that filesystem is online? > Remote/removeable systems have their own wastebaskets, could they not have > their own indexes? > > Not seriously suggesting that this is on anyone's workplan. But, wouldn't > that future be nice? That wouldn't be my preference. Far better if metadata just worked without needing to store indexes everywhere (as it does on Windows). It does take a second or two for large directories to populate all the meta fields, but I'd much rather wait ~2 seconds than have indexes all over the place. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 419887] Thumbnails do not work in Dolphin with Android connection
https://bugs.kde.org/show_bug.cgi?id=419887 --- Comment #7 from Metal450 --- (In reply to Andrey Kozlovskiy from comment #6) > I thought I had this problem too with Android 8 phone, but for me the > problem was that in Dolphin's settings, 'General' -> 'Previews' -> 'Skip > previews for remote files above' value (located in the bottom) was set to > 'No previews'. Set it to some sane value depending on your workflow, for > example 10MiB. > > If 'No previews' is still the default in latest Dolphin, it definitely > should be changed to some better value. > > In Nautilus, checking 'Preferences' -> 'Search and Preview' -> 'Thumbnails' > -> 'All files' works for me. But like in Dolphin, also check 'Smaller than' > value, just in case. You're right, that fixed it Thanks so much, I was using a Windows VM every single time I had to manage photos on my phone. Having this off by default is definitely extremely unintuitive/unexpected, but so glad there's at least a way to make it work properly :) -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 419887] Thumbnails do not work in Dolphin with Android connection
https://bugs.kde.org/show_bug.cgi?id=419887 --- Comment #4 from Metal450 --- (In reply to Nate Graham from comment #1) > Works for me with git master version. I just tried this on the newly released Kubuntu 20.10 (which uses Dolphin 20.08), & it still doesn't work properly. Can you confirm which version of Dolphin you're using where it works? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 416087] Optionally find hidden files using Dolphin's standard search
https://bugs.kde.org/show_bug.cgi?id=416087 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #11 from Metal450 --- Just spent half an hour pulling my hair out trying to figure out why search didn't work properly. Turns out the files I was looking for were within a hidden folder. I have Baloo disabled, as no need to expend system resources, storage, & ssd wear to make searches slightly faster. If it's difficult to integrate i.e kfind or an alternative better-working search implementation directly into the Dolphin UI, is it at least possible to remap the Ctrl+F hotkey in Dolphin to launch kfind (in a separate window), rather than showing the Baloo search bar? Remapping the ctrl+f key is obvious (Settings->Configure Keyboard Shortcuts), but I don't see an option to map it to launching an external application (kfind). And mapping Ctrl+F globally doesn't work, as it would get in the way of the search hotkey in other applications. -- You are receiving this mail because: You are watching all bug changes.
[kiofuse] [Bug 75324] Integrate KIO Slaves into file system using FUSE gateway
https://bugs.kde.org/show_bug.cgi?id=75324 --- Comment #123 from Metal450 --- (In reply to Christoph Feck from comment #122) > the best place for new users to ask questions > is in forums instead of a bug tracker. Be sure to better describe your issue > by providing exact steps that others can follow. "Fighting" is not a good > way describe what you were doing. Hi, thanks for the reply - I actually did indeed reference a few other places (i.e. StackOverflow, Reddit), & it was suggested that the behaviors I was seeing were due to kio-fuse & that they had been fixed in 20.04. The specific issue is that although I can browse smb, the vast majority of programs fail to be able to work with them. i.e. opening a file from smb in VLC fails; opening a photo in XnViewMP works but then cannot scroll to any others; opening a PDF in MasterPDF has to copy the entire file over the network before it can view, and so on and so forth. Since all of these do work properly in other file managers (i.e. none of these issues exist in Nemo, Nautilus, Caja, etc), it was indicated that the problem is unique to Dolphin, and after some more searching, I was led here. And I believe that the behavior has been fixed, & thus things should now work properly in Dolphin as well. If I can figure out a way to get 20.04 installed ;) Just a follow-up, I don't think Flatpak works - I was able to install Dolphin 20.04 that way, but in that case, I couldn't access smb at all. Presumably because of its packaging / it doesn't interact with the other necessary parts of the system to take advantage of this fix. -- You are receiving this mail because: You are watching all bug changes.
[kiofuse] [Bug 75324] Integrate KIO Slaves into file system using FUSE gateway
https://bugs.kde.org/show_bug.cgi?id=75324 --- Comment #121 from Metal450 --- Gotcha, thanks. I did some searching & found the Kubuntu Backports PPA here (https://community.kde.org/Kubuntu/PPAs#Kubuntu_Backports), but adding it didn't make the Dolphin update available. I also since found this: https://askubuntu.com/questions/1260704/how-to-install-latest-stable-dolphin-file-manager-on-kubuntu-via-xdg-opendiscov So, I guess the options are Flatpak, or wait until Kubuntu 20.10 ships in October (or hope that it gets added to Kubuntu PPA sometime in the interim). Thanks for your reply :) -- You are receiving this mail because: You are watching all bug changes.
[kiofuse] [Bug 75324] Integrate KIO Slaves into file system using FUSE gateway
https://bugs.kde.org/show_bug.cgi?id=75324 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #119 from Metal450 --- Apologize if this is a dumb question, but is there any way to get Dolphin 20.04 installed on (and thus this issue fixed in) Kubuntu 20.04? it's not in the default repos yet (still Dolphin 19), but i.e. some "testing" repo, PPA, or other approach? Or is the only way to just wait? I'm a new Linux user coming over from Windows & always "fighting" with being able to reliably access network shares on various networks (it's a portable laptop) has been *the* biggest struggle for me as a new user. Any way I could get this installed now would be greatly appreciated (i.e. I see this was reported fixed in January, aka 6 months go - no idea how long it would take if I "just wait" for it to appear in the Canonical repos ;)) -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 419887] Thumbnails do not work in Dolphin with Android connection
https://bugs.kde.org/show_bug.cgi?id=419887 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #3 from Metal450 --- I can confirm thumbnails/previews are not working properly over MTP in Dolphin 19.12.3 (in my case on Kubuntu 20.04). -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 424316] New: Cannot Move Or Cut Files From Search Results
https://bugs.kde.org/show_bug.cgi?id=424316 Bug ID: 424316 Summary: Cannot Move Or Cut Files From Search Results Product: dolphin Version: 19.12.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: search Assignee: dolphin-bugs-n...@kde.org Reporter: metal...@gmail.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY After searching for files in Dolphin, you cannot cut or move any files from the search results. STEPS TO REPRODUCE 1. Open a Dolphin window 2. Ctrl+F, type a search term 3. Try to cut & paste any of the resulting files to another window (or equivalently, shift-drag them) OBSERVED RESULT Files cannot be cut/moved, only copied/duplicated. EXPECTED RESULT Files can be cut/moved. SOFTWARE/OS VERSIONS Linux: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 415523] Please, add option to disable "filename extesions are always visible"
https://bugs.kde.org/show_bug.cgi?id=415523 --- Comment #10 from Metal450 --- That would be a great solution, if it's also possible to hide the extension? (Confusingly, that's actually the title of this issue - "Please, add option to disable "filename extesions are always visible?"). If the extension is always visible though, it's unfortunately just as problematic, because it would still cause the extension's 4 characters of "not configurable text" to hide 4 characters of "useful/configurable" text. Just like the previous solution. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 415523] Please, add option to disable "filename extesions are always visible"
https://bugs.kde.org/show_bug.cgi?id=415523 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #8 from Metal450 --- Vote for having it be configurable. Radiobuttons for "Elide At: Middle vs End." I use a similar naming convention to Matteo M (in the other thread), & this behavior makes it impossible to get consistent behavior across systems. aka if I name my files such that the important information is visible on Windows & elsewhere, Dolphin hides the important part. If I name it for Dolphin, the important part is hidden everywhere else. Having an option is a simple solution that satisfies everyone: those who want it & those who don't. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 404955] Add an option to always show the file extension
https://bugs.kde.org/show_bug.cgi?id=404955 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #15 from Metal450 --- This is awful. Does anyone know the very last build of Dolphin before this was changed, and how to revert to it? I have a similar naming convention to Matteo M, & this new behavior - which is dissimilar to Windows & every other file manager I've ever worked with - makes it impossible to get consistent behavior across systems. There's therefore no longer a way to name my files that behave "well" on different systems. -- You are receiving this mail because: You are watching all bug changes.
[kwallet-pam] [Bug 416461] [5.18] KDE wallet not unlocked on login
https://bugs.kde.org/show_bug.cgi?id=416461 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #29 from Metal450 --- I'm on KDE Plasma 5.18.5, KDE Frameworks 5.68.0, and I experience this only intermittently. The behavior is identical to what's described here, but it only happens maybe 1 out of 5 reboots. 4 out of 5 times it unlocks properly. There doesn't seem to be any rhyme or reason to why/when. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 392531] Add option to have "Move" as default DND action instead of the pop-up menu
https://bugs.kde.org/show_bug.cgi?id=392531 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #17 from Metal450 --- New user here, coming from Windows - I also find it unnecessarily cumbersome to have to use modifier keys just to move a file. This seems to be an extremely prevalent issue throughout the web - it took me a while to land on this thread, but I've found many going back nearly a decade. i.e. here's discussion about this from early 2011: https://forum.kde.org/viewtopic.php?f=224=92785 Although there's some argument to be made for the "explicit" nature of having a menu or using a modifier, I see absolutely no downside to allowing a system option so that those who are coming over from other systems, or who prefer unified behavior across their systems, to achieve that behavior. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 327370] CalDAV / ownCloud reminders not showing on login if the machine was off at the start time.
https://bugs.kde.org/show_bug.cgi?id=327370 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #7 from Metal450 --- The machine doesn't even need to be off - it just needs to be offline. Example: you're on a flight, another user adds a CalDAV event with a reminder set 1hr in the future. You land 2hrs later, connect to the internet, the event is synced. But you never see a reminder because by the time it synced, it was 1hour in the past. Actually missed an important event as a result of this. Considering it was reported more than six and a half years ago, is it safe to assume it won't be fixed? It does seem like a pretty big issue - as if you can't trust reminders to be accurate unless your machine is online & connected 24x7, how can you rely on them for scheduling? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 420951] "Recent Locations" item
https://bugs.kde.org/show_bug.cgi?id=420951 --- Comment #4 from Metal450 --- The following seems to be working: sqlite3 ~/.local/share/kactivitymanagerd/resources/database "DELETE FROM ResourceScoreCache WHERE initiatingAgent = 'dolphin';" ; pkill -f kactivitymanagerd ; /usr/lib/x86_64-linux-gnu/libexec/kactivitymanagerd & Not sure if this really safe or recommended, but at least it does seem to clear out all the clutter & make the menu behave properly if or until an official solution exists... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 420951] "Recent Locations" item
https://bugs.kde.org/show_bug.cgi?id=420951 --- Comment #3 from Metal450 --- Question: is there any way to manually clean out all the locations from 'Recent Documents?' Then I could at least 'fix' it with a cronjob or a hotkey. I tried deleting ~/.local/share/user-places.xbel, but that didn't do it. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 420951] "Recent Locations" item
https://bugs.kde.org/show_bug.cgi?id=420951 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #1 from Metal450 --- Agreed - for clarity, I'd hoped to get a "Recent Documents" menu that actually represents "recent documents" - similarly to on Windows. As Plasma 5's "Recent Documents" menu is cluttered with a mix of actual "recent documents" AND "recent locations" together, very few actual documents are shown. They're rapidly pushed out of the menu by virtue of simply browsing around the filesystem. -- You are receiving this mail because: You are watching all bug changes.
[kcontrol] [Bug 59027] Shortcuts cannot be only Alt+Shift or Ctrl+Alt or similar
https://bugs.kde.org/show_bug.cgi?id=59027 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #7 from Metal450 --- I guess it's clear enough from all rejections of people wishing to do this that it won't ever be supported, but just to add my 2c: I've used RAlt+RCtrl as a shortcut for "Mute" on my keyboard for years - it works fine on Cinnamon, Windows (via AHK), etc. In all the years, I've never had any issue or conflict. I was a bit baffled when I couldn't get it to work on Plasma, having moved over from Cinnamon specifically because it's supposedly the most flexible & customizable. Even if this is not an "ideal" shortcut, Plasma really shines in its customizability and the fact that it doesn't purport to be one-size-fits-all. I really don't understand the perspective of saying "...but THIS particular customization, which clearly some people desire, we refuse to allow." What's the harm in letting people customize it how they see fit? -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 324596] Date Picking to create an event list is restricted to a one month period
https://bugs.kde.org/show_bug.cgi?id=324596 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #11 from Metal450 --- I came here looking for something similar: trying to move from Windows to Linux, & replace Outlook's calendar, which I use an EventList, showing all events in "detail view." In KOrganizer, however, it only shows items in the very limited current 30-day period, which IMHO makes it not really any benefit over the standard Month view. it seems like an event list should list all of the events, uness you explicitly want to filter it to just 30 days. At least, that's how it works in Outlook, eM Client, Thunderbird/lightning, & other list-based calendars I've used. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 406506] Wish - Show metadata of files stored on locations non-indexed by baloo in details view mode
https://bugs.kde.org/show_bug.cgi?id=406506 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #11 from Metal450 --- (In reply to Nate Graham from comment #1) > Probably it should just index NTFS disks... I'm facing the same issue as the OP, & am definitely not after a solution of indexing NTFS disks. Being able to view media columns on removable USB drives, SD cards, network drives, etc is also important - & those shouldn't be indexed. In my case, I actually have indexing disabled entirely, as I don't use search & thus don't need the overhead. But losing those columns when moving over from Nemo (which supports them via extension) definitely felt like a bit of a regression. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 417170] Option in Baloo to index file metadata (tags, ratings, comments, etc) without enabling full text indexing
https://bugs.kde.org/show_bug.cgi?id=417170 --- Comment #10 from Metal450 --- Gotcha. #406506 is definitely what I'm after - having the columns function without the need for Baloo. Bummer it hasn't gotten any love in over a year, but at least I've got something to keep my eye on :) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 417170] Option in Baloo to index file metadata (tags, ratings, comments, etc) without enabling full text indexing
https://bugs.kde.org/show_bug.cgi?id=417170 --- Comment #8 from Metal450 --- Perfect, thanks for the quick reply :) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 417170] Option in Baloo to index file metadata (tags, ratings, comments, etc) without enabling full text indexing
https://bugs.kde.org/show_bug.cgi?id=417170 Metal450 changed: What|Removed |Added CC||metal...@gmail.com --- Comment #6 from Metal450 --- I found my way to this bug while trying to figure out why all the metadata columns in Dolphin were blank. I (deliberately) have my search index disabled, but even if it were enabled, that wouldn't solve the issue as viewing media on external hard drives or networked drives - which shouldn't be part of the index either way - would never work. Should that be a separate issue from this one? As mentioned in the OP, Dolphin is definitely able to extract the metadata without Baloo (as can be seen via the file properties dialog), so it seems like a bug that it would leave all the columns blank. I'm not clear, though, if this issue is only asking for metadata to be indexed, or for the columns to be fixed regardless of the index, as it seems to sort of address both. -- You are receiving this mail because: You are watching all bug changes.
