QLog does not delete all entries

[p14e]

Hi,

when I import an ADIF-log, mark all entries with Ctrl+A, press "Del", press "Ok", sometimes not all entries are removed, the list still shows many entries. It seems this happens only when I import several ADIF-logs into QLog but I think I have seen this also with a single imported logfile.

Also the deletion takes an unexpected long amount of time (> 10 sec for a few hundred entries, I would expect only some milliseconds for these few lines) on a decent PC.

Thanks & Best Regards,
Patrick

[foldynl]

Hi, ctrl+a selects only QSOs currently in view. The view itself optimizes how many QSOs are displayed. If you use CRTL+A and you have many QSOs, it may happen that the view does not have all these QSOs recorded, because it would take a very long time. It's a known issue, but I'm not going to fix it for now because it would have a negative impact on performance.

I tested the delete operation and I cannot confirm your observation. It take less 1sec to delete 500 QSOs.

[foldynl]

OK...It takes 3 secs to delete 1500 QSOs. Maybe it could be optimized, but keep in mind that delete is not just an ordinary deletion from the DB, several actions are performed there. But as I say, it could be optimized.

I forgot about CTRL+A. The workaround for marking all QSOs is to go through the entire view scrollbar and then press CTRL+A. Then the view contains all QSOs that can be selected and deleted.

[p14e]

Hi,

sorry for the late response, I was AFK for some time.

I now noticed that Ctrl+A only selects the first 256 entries, so I need to either use it multiple times or go manually through the list. Hm, that's anyway not what you would expect when using Ctrl+A, because I would expect it to really select all (that is the meaning of Ctrl+A) entries, even if it would take some time for a big number of entries. Maybe you could think about it again.

For the performance issue I do not know what exact actions are performed in the background, but I wonder why it would take so long for selecting entries in a list-view and deleting them from a database (my understanding is that one uses a database for comfort and performance), if I imagine implementing the storage in a simple ordinary linear file based format, it would be pretty fast by modifying a few thousand entries ... but I'm not a database expert.

Anyway, thanks for thinking this through.

Thanks & Best Regards,
Patrick

[foldynl]

I now noticed that Ctrl+A only selects the first 256 entries, so I need to either use it multiple times or go manually through the list. Hm, that's anyway not what you would expect when using Ctrl+A, because I would expect it to really select all (that is the meaning of Ctrl+A) entries, even if it would take some time for a big number of entries. Maybe you could think about it again.

I have to make performance tests. I don't about this issue. This "issue" has been there since the beginning.

For the performance issue I do not know what exact actions are performed in the background, but I wonder why it would take so long for selecting entries in a list-view and deleting them from a database (my understanding is that one uses a database for comfort and performance), if I imagine implementing the storage in a simple ordinary linear file based format, it would be pretty fast by modifying a few thousand entries ... but I'm not a database expert.

You don't need to be a database expert, but you need to look into the code and identify bottlenecks. I already researched something, but it resulted improvements of 10%. it is not a significant change, therefore it will not be included in the release. . That's why I leave this open.

But to be honest. It is not a common use case that the operator deletes a large amount of QSOs. If it is needed to be done, there is something wrong on the operator's side. If you need to delete the DB and create it again, it is better to delete the DB file, delete the config file.

[p14e]

Hi,

I agree that the usecase may be a bit exotic, I'm currently using QLog a bit as an "ADIF-editor" to edit/enhance some logs ... import logfile, edit/add entries, export as ADF and ADX and look at the diffs. That's how I noticed the problem with the removed question marks. But the large delay in deleting entries may possibly give some hint to some other hidden problem with the database-connection ...? I'm now on 712671b and currently see an even longer delay of 28 seconds. It looks like there is some global lock which just stops all threads of the application, because also the time in the Clock-window is not updated while the deletion is performed. Is there maybe a blocking network-call (or similar) running in the background which blocks and then timeouts (or something similar which may explain the delay)?

I hesitate a bit to fiddle in the internals like config files of QLog, so I took the natural "user way" and just deleted all entries in the log pane. :-)

Maybe it is an issue which is a bit specific to my system, when you can't fully reproduce it on your side.
I'm here on Ubuntu 22.04.4 and will update a 2nd machine to 24.04 soon and will then test QLog on this machine again.

Thanks & Best Regards
Patrick