#1
|
|||
|
|||
Strange Clipboard Sensitivity
I am new to JDownloader 2, and I have spend a week to fine tune my usage process. It feels good but the clipboard was not sensitive no matter how I fine tune the settings and advanced settings.
The non-sensitive behavior is : In Windows 10 Home, when I use it with Firefox Quantum (63.0.1 64bit), and copy link in the browser using mouse operations or touches operations, I feel the Linkgrabber is not detecting links occasionally (about 1 in 4 link copy undetected) and I need to switch off then on the Linkgrabber function to force it to detect. I tried to update Java and many things, but the behavior stay. Today I find a setting in the Bubble Notify, which may be the cause of the un-responsiveness. When I uncheck all "Show Bubble if" options and then check one only "during linkcrawling and onlinecheck" , the clipboard grabbing become much more responsive. (about 1 in 20-30 link copy undetected). Consecutive copy does not stop sensing that often any more. Now I can use JD much more easily, and like to share this experience with new users, and also hope this low sensitivity can be improved. Source Rev: Core: 40030 Launch: 4664 AppWork Util: 3172 Browser: 39912 Updater: 726 Java: 1.8.0_162 32bit |
#2
|
||||
|
||||
Can you provide more infos? What are the system specs?
Is the amount of data copied to clipboard small or large? How *fast* do you copy to clipboard? Does it happen on all sites or just some? The current waittime is 100ms , that JDownloader waits 100ms after not detecting a clipboard change (actual using windows api to query for changes) and then can detect new changes.
__________________
JD-Dev & Server-Admin |
#3
|
|||
|
|||
I follow up your questions to help you check what is happening....
Quote:
After my setting the Bubble setting now, I can continue using my clipboard manager with JDownloader together, and the link-loss is very rare (about 1 in 30-40 copy) When I turn on "the Download started, stopped or has been paused", the link-loss come back (about 1 in 4~6 copy), and is annoying since I need to check whether the bubble has comes up. So are you suggesting that, this copy event is detected by sampling? Can this copy event be detected more reliably, like interrupt or exception? Last edited by pulokade; 19.11.2018 at 16:22. |
#4
|
||||
|
||||
3 seconds is more than enough time to parse the content of the clipboard, so sampling rate of 100ms after last non change is not the problem.
Also I don't see how *download started, stopped or has been paused* can be connected to the clipboard monitoring loss as those are not connected with each other. Would it be possible that we can do a teamviewer session and check this together. Contact us via support@jdownloader.org Or maybe send me example links and I will try to reproduce the issue as I can't do it right now
__________________
JD-Dev & Server-Admin |
#5
|
|||
|
|||
teamviewing may not be possible at the moment, but i think i shall keep using JDownloader and see if i can be more specific in spotting the problem.
about the image link, it doesnt seem to be specific to some address, and the copy-loss can happen on any image link randomly. When it happens, it feels like JD has not notice the clipboard has changed, and then re-copying sometime DOES activate JD to linkgrab. Switching off and then on the linkgrab function can detect the clipboard, too. I have checked the clipboard content when this loss happens. Everytime, the clipboard contains the target image link correctly (i paste it out to check), and the linkgrab has not detected it, and the downloader only downloaded the previous image. In other words, it looks like the linkgrab has completely missed the change of the clipbroad from previous link to target link. If I switch off and then on the linkgrab function, or re-copy sometime, the target link got detected then, and the download is started. This is what I observed. 100ms sampling sounds ok, but it feels like it may not be related to the sampling rate... Last edited by pulokade; 19.11.2018 at 17:30. |
#6
|
||||
|
||||
On windows clipboard change detection relies the windows api that returns a counter/number that increases/changes each time the content of the clipboard changes.
JDownloader checks for change and either parses the content or waits 100ms and checks again. Copying the same content again will be blocked by the *change detection* so you will have to copy something else and then the link again for having an actual change. adding the same link twice will result in one content processing. Yes, I don't think it's connected to the samling rate. But I need a reliable way to reproduce the issue in order to find/fix it. So would be great of help when you can try to find a way to reproduce the issue so you can tell/show me. Thanks for your help with this
__________________
JD-Dev & Server-Admin |
#7
|
|||
|
|||
For the Change Detection, you are correct, I have tried to do the copy from a plain text link on an image, the 1st time I copy it will activate JD, then from the 2nd time on will have no effect on JD.
But it is curious that when the loss happens, and I paste the content out, it is the target image, and re-copying it from a right-mouse click from firefox DOES activate JD sometimes. This is very strange, and I fail to reproduce the problem reliably. |
#8
|
||||
|
||||
You could try to copy the links into text/notepad and then fast copy stuff and check if the issue is connected somehow to firefox(version) or happens with every tool.
__________________
JD-Dev & Server-Admin |
#9
|
|||
|
|||
After a week of testing, I have tried both ways of operation
-- use mouse to copy single link from Firefox webpage -- save the source to a text file, use mouse to select and copy the image link using ctrl-c this is thru a link-by-link process. My conclusion is that JD does missed some links during both processes. And i checked the clipboard, it has the most current link i just copied, but JD really missed that link, and does not activate linkgrabber. This missing is happening randomly, and I see it about 5-10 links will score 1 miss. Is it possible to open up some clipboard setting for the user to change with?? So that I can experiment more for the development. |
#10
|
|||
|
|||
In this month of testing, I have observed a strange behavior, which I believe is the source of the in-sensitive clipbroad.
This may be the competition between link analysis and page analysis. When I copy link to an image and hope auto-clipbroad can capture the link, the success rate is about 80-95%. About 5-20% will score a miss. When I copy link to a PAGE WITH AN IMAGE, the auto-clipbroad can capture the download with very near 100% success rate. This is very good! So I guess sometime the page-analysis function capture the link to an image link, and therefore make the decision to download nothing. Could you check is this the bug inherited?? Thanks |
#11
|
||||
|
||||
Try this:
Settings --> Advanced Settings --> "clipboard skip mode" --> Change to NEVER -psp-
__________________
JD Supporter, Plugin Dev. & Community Manager
Erste Schritte & Tutorials || JDownloader 2 Setup Download |
#12
|
||||
|
||||
@pulokade: We need example links. Adding a non supported link (url format must be supported by a plugin) will result in nothing being added. It may be that you're trying to add links and think they are supported but they are not. Adding a single unsupported link will result in JDownloader trying to check that url. This special handling does not kick in when adding multiple links at once.
You should try to create a way to reproduce the issue. For example copy all links into a textfile and then you can send us this file for testing. I still offer to let us check this together via teamviewer
__________________
JD-Dev & Server-Admin |
#13
|
|||
|
|||
I have got some example images from this list.
**External links are only visible to Support Staff****External links are only visible to Support Staff** Here I collected there individual direct image links and also their webpage links for test (of course you should skip the videos in the list, I only test images). On my computer as noted at the first post, the two lists show a significant success rate difference as mentioned. Please remember that the behavior is random, i.e. image will score miss at random, but not some particular image that will constantly score miss, and the miss rates are very different in the two cases. You can try all files in the list using both image links and webpage link, then you should be able to repeat the said bahavior. I dont know if the OS or the browser have something to do with it, but the difference is pronounced in my PC. If you can find some machines with similar setting, you may be able to reproduce it easily. **External links are only visible to Support Staff****External links are only visible to Support Staff** **External links are only visible to Support Staff****External links are only visible to Support Staff** **External links are only visible to Support Staff****External links are only visible to Support Staff** **External links are only visible to Support Staff****External links are only visible to Support Staff** **External links are only visible to Support Staff****External links are only visible to Support Staff** **External links are only visible to Support Staff****External links are only visible to Support Staff** **External links are only visible to Support Staff****External links are only visible to Support Staff** **External links are only visible to Support Staff****External links are only visible to Support Staff** **External links are only visible to Support Staff****External links are only visible to Support Staff** **External links are only visible to Support Staff****External links are only visible to Support Staff** |
#14
|
|||
|
|||
Quote:
Thanks for the suggestion. I have tested but for direct image links I still score about 10-15% miss. For weblinks it also miss but the miss rate is significantly better. I think this is not the reason behind the clipbroad misses. |
#15
|
||||
|
||||
Thanks for the links. How exactly do you add those?
Do you add the /p/.... link from browser address or how exactly? because normally you don't add the direct links by yourself but just add the supported instagram links. And I wonder why you provide the direct images AND the instagram links?
__________________
JD-Dev & Server-Admin |
#16
|
|||
|
|||
Quote:
It seems our machines have some configuration difference, so that you score no miss, but I constantly score misses. The rate is about 20% and the result is not fixed to certain images, so an accurate reproduction of the issue is not possible. I shall continue to report my founding. |
#17
|
||||
|
||||
I would suggest to create a dummy list, eg
http://cdn8.appwork.org/1.txt http://cdn8.appwork.org/2.txt ... http://cdn8.appwork.org/300.txt and then copy links from this one by one and check which links are missing and if you can find a way to reproduce that. of course those links will show up as offline but that shouldn't matter at all. most important is to find a way to reproduce the way so you can either show us or we can can reproduce it for ourselves
__________________
JD-Dev & Server-Admin |
Thread Tools | |
Display Modes | |
|
|