Summary: | save partial files as file.part (like Konqueror) | ||
---|---|---|---|
Product: | [Applications] ktorrent | Reporter: | Maciej Pilichowski <bluedzins> |
Component: | general | Assignee: | Joris Guisson <joris.guisson> |
Status: | CONFIRMED --- | ||
Severity: | wishlist | CC: | ashl1future, Brando56894, lumks, plusfabi, wcasanova, zorael |
Priority: | NOR | ||
Version First Reported In: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Maciej Pilichowski
2007-07-06 09:41:12 UTC
*** Bug 157491 has been marked as a duplicate of this bug. *** *** Bug 218241 has been marked as a duplicate of this bug. *** *** Bug 292833 has been marked as a duplicate of this bug. *** First - sorry vor duplicate of this bugreport. havent found this one. secound i want to ad my bugreport to this, because this one is from KDE3 and there are no nepomuk/strigi that _______________________________________________________________________________ currently if you download anything via ktorrent, your indexer will be triggered every secound (or every 5 secound with newer nepomuk). thats behavior is bad because it takes much CPU load oder time. Apps like chrome/chromium or the kde downloadstuff (rekonq, konqueror, kget) set for not-fonished files the prefix *.part . files with this prefix will not be indexed by nepomuk. wth this, it would be a good idea if ktorrent will do the same or something else to get nepomuk away as long as the download isnt finished Reproducible: Always Steps to Reproduce: enable nepomuk/strigi indexing service start ktorrent and download somethoing witch causes heavy load in nepomuk (movies *.mkv for example) Actual Results: nepomuk will gered everi 1-5secound and reindex this file, and you weak PC will take much longer for the rest Expected Results: not finished files should be not indexed as long as they are not finished yeah without the .part extension nepomuk will reindex the torrentfile again and again *** Bug 297945 has been marked as a duplicate of this bug. *** *** This bug has been confirmed by popular vote. *** |