Thanks for the suggestion but that is not what is going on. dl.exe is a packed python exe and it is unpacking itself to run. Monitoring performance shouldnt be an issue unless you have lots of them and your computer and/or internet connection isnt up for supporting lots of downloads and connections to the web. Please provide debug logs of monitoring and I can take a look.
I found the cause to the program's unresponsive nature. I had 100s of disabled monitors thinking that they would be ignored. The file processing of these are terribly slow and essentially hands the program. I removed them and it works fine again. You should consider appending .disabled or something to these monitor files, read them into the database but make the monitor ignore them.
Regards
If they are disabled they should not be being processed. If you have logs would be good to see them to see what is going on so I can fix if that is required.
This is easy for you to test, just add allot of disabled monitors, you'll see that the program crunches though them and basically hangs. I just delete the monitors I do not use now.
Support Migration
Hi guys
The latest update 2021.09.02 for the extraction engine launches dl.exe and then conhost.exe, and relaunches dl.exe again with the same command line placing even more burden on Media Recorder which is almost completely non-responsive when the monitor is activated (it was pretty unusable before when the monitor is activated). I suggest a rewrite of the listner for dl.exe into a thread of it own and separate it from the user interface.
It does seem to work better though when adding urls manually. But it broke the monitor.
Regards
--- Import ---
Author: JB
Created At: 2021-09-16T22:20:13+08:00
Updated At: 2021-09-16T22:20:13+08:00
Views: 17
Votes: 0
--- Import ---