By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 1670

Summary:	[Regression] Kget no longer gets.
Product:	TDE	Reporter:	Martin Hodges <martinhodges479>
Component:	tdenetwork	Assignee:	Timothy Pearson <kb9vqf>
Status:	RESOLVED FIXED
Severity:	major	CC:	albator78, bugwatch, kb9vqf, slavek.banko
Priority:	P5
Version:	R14.0.0 [Trinity]
Hardware:	All
OS:	Linux
Compiler Version:		TDE Version String:
Application Version:		Application Name:
Attachments:	kget : Fix warnings in .xsession-errors

Description Martin Hodges 2013-10-04 11:38:16 CDT

Items to be downloaded get added to the queue but never appear to start or finish.
This is when used as a download manager for konqueror.

Debian wheezy.

Comment 1 Francois Andriot 2013-10-13 09:09:13 CDT

Confirmed on Mageia 3, R14 nightly.
Files are added to Kget but stay at 0% forever, download speed 0.

Comment 2 Francois Andriot 2013-10-20 05:34:10 CDT

Created attachment 1563 [details]
kget : Fix warnings in .xsession-errors

This patch does not solve the problem, but it fixes a small "warning" issue.

Comment 3 Timothy Pearson 2013-11-02 15:49:50 CDT

This is unfortunately far more complex than it might first appear.  KGet uses a very strange threading model that relies on shared execution of a TDEIOSlave from more than one thread (!).  As you can imagine this is not the correct way to use threads, and indeed after disabling the TQt3 thread manager for the KGet application (i.e. reverting to Qt 3.3 behaviour), while KGet works again, I am noticing sporadic crashes related to threading as expected.

I don't know what the developer was thinking when he designed the threaded transfer slave.  TDEIOSlaves can only safely execute in the main thread, and it looks like (by accident, not design) KGet executes the TDEIOSlave *mostly* in the main thread, but enough of the TDEIOSlave executes in the slave thread that KGet is unstable.  I don't see a way to fix this short of rewriting portions of the Transfer and/or Slave classes.

So, do I push the thread manager reversion patches to GIT, thus resolving this Regression bug report, even though the resultant KGet will be unstable on some systems?  I am leaning toward not doing this; thoughts are welcome.

Comment 4 Timothy Pearson 2013-11-02 23:09:21 CDT

I have restored KGet to full functionality in GIT hash 7dc822e by removing much of the botched threading code.  While KGet now functions as intended in my tests, I don't know if any functionality was damaged by removing the ill-conceived threading system.

Ideally the Slave class would be cleaned up further to remove the posted event handler as it is no longer used, however, as KGet is functional at this point, this would be purely cosmetic.

Comment 5 Timothy Pearson 2013-11-02 23:12:18 CDT

Comment on attachment 1563 [details]
kget : Fix warnings in .xsession-errors

Pushed to GIT in hash 67e7287.

Comment 6 Francois Andriot 2013-11-04 15:27:29 CST

Looks like the problem is fixed for me.
BTW, kget was already a bit crashy in 3.5.13.x so I do not think it is worse now.

Comment 7 Slávek Banko 2013-11-04 15:58:59 CST

Yes, it looks very good.

Although I had a problem with downloading which was in the queue from previous attempts, but stop / repeat this downloading solve the problem and is not repeated again.

As for me - this bug message can be closed.