cabji / hush Goto Github PK

A KVIrc addon - XDCC search system with automation features.

hush's Introduction

Hush ReadMe

About

Hush is an addon for KVIrc and requires at least v4.9.2 or higher from v0.2.6 onwards.

Hush aims to create a search system for XDCC channels along with automation for a number of aspects related to your media content. It removes the need to: publicly search for content, use subscription systems that reside on other computers and provides a degree of automation to continue content acquisition. It supports watching multiple IRC networks and channels.

Latest Update

20240110

Added new classes: hush::sport and hush::sportobject

Added new widgets to:

Control Sport settings

ToDo

Sport

Frontend: Build UI widgets to represent each "Sport Trail" the user creates
Backend: Decide how to build search strings to detect desired sport content
Backend: Decide how/when to perform a Sport search

bug notes

These bugs are pretty old now and for the most part don't seem to affect the operation of Hush, so they are very low priority.

aSTi bug

there is a bug that producesd the following error:

[Nov08-23:07:12] [KVS] Runtime error: Array index didn't evaluate to an integer [Nov08-23:07:12] [KVS] In script context "OnQueryNotice::hushErrorHandler", line 160, near character 17 [Nov08-23:07:12] [KVS] Code listing: [Nov08-23:07:12] [KVS] 158 ... [Nov08-23:07:12] [KVS] 159 #debug -c "$k(8)--> found active searchTerm %G_hush->%activeSearchTerm[%aSTi] at index [%aSTi]. removing it from the active searchTerm array <--$k()" [Nov08-23:07:12] [KVS] 160 debug -c $k(15)[FATAL ERROR]$k()\n$b()asti = %aSTi$b()\n typeOf asti = $typeOf(%aSTi)\nfnArrayBinarySearch was called using:\n st = %st\n activeSearchTermArray = %G_hush->%activeSearchTerms\n --- ($k(8)This value has caused onQueryNotice::hushErrorHandler to fail$k(), so check it [Nov08-23:07:12] [KVS] 161 debug -c "-------------" [Nov08-23:07:12] [KVS] 162 ...

%aSTi is somehow getting a null value (it should always be an int)

when this occurred on Nov 08, the debug logs showed that Hush had attempted to auto download a file 3 times although it successfully downloaded that file twice already. It should never duplicate downloads, so I need to determine the conditions that allow this to come about.

I am not sure if the multi-download bug relates to the aSTi bug?

The Multi Download Bug

Debug log showed that:

Passive search found 3 results (expected)
Primal.mkv was req from Waveform and downloaded successfully. (expected)
Passive search timer is triggered again at 2 hour interval, 0 results (expected)
searchesImport timer is triggered which re-adds the Primal search term to the Searches list [NOT EXPECTED] Expected behaviour is for Hush to filter the Primal search term from the list because we have already downloaded the title. Proposed Remedy: Find code section that deals with insertion of search terms into Searches list and ensure that a comparison against existing titles is being done. Check if the existing title list (or array) is being updated immediately when a new title is transferred successfully. Trace code logic after a transfer completes to decide where to update the existing list of titles.
Passive search found 3 results (expected)
hush::main::checkDownloadQueue finds an xdccobject with Status "Queued" under the PRimal search term (but we already have a completed download for this title!) [NOT EXPECTED] Expected behaviour is for checkDownloadQueue to see that we have a completed transfer for this search term already and to skip downloading.
Download of 2nd Primal title begins and completes. (expected)
Passive search found 1 result (expected)
hush::main::checkDownloadQueue finds an xdccobject with Status "Queued" under the PRimal search term (but we already have a completed download for this title!) [NOT EXPECTED] Expected behaviour is for checkDownloadQueue to see that we have a completed transfer for this search term already and to skip downloading.
3rd Primal title is requested from 84659 (expected)
At 23:07:12 a query notice triggers the hushErrorHandler. The query notice sent by the bot was: "Sorry, this command is unsupported" which is a case handled by hushErrorHandler
aSTi is returned value of hush::common::fnArrayBinarySearch
appears as though in this instance only, the error generated was dues to the $k()[FATAL ERROR]$k() <- square brackets were mistaken for an array index reference. This was not truly the aSTi bug.

Media Libary Scan Bug

On KVIrc startup, the media library scan function will run. It will successfully scan the configured media content locations and find Movies and TV titles, placing their values into the appropriate arrays and files.

If you open the Media Library window after startup and click the "Scan Media Library" button, the media scan will run, but it will find 0 or 1 title only.

This bug needs investigation.

hush's People

Contributors

Watchers

hush's Issues

hush::searches::epUp: search string not altering correctly

Debug output:
hush::searches::epUp: info: search string altered to: building.off.the.grid.s02.proper*.rare01

expected action:
search string should alter the "s02" to "s03" and ignore the episode value.

The download order of the Download Queue window is not obeyed

The order of items in the Download Queue window should be the order that Hush auto-downloads items in. This ordering is not obeyed.

Relevant debug log messages:

When the up or down arrow buttons are used the following is shown:
[Dec16-21:28:15] Setting the new downloadOrder array
[Dec16-21:28:15] The download queue was altered by btnMoveUp so refreshing the queue

When there is no "downloadOrder" array the following is shown:
[Dec16-19:52:19] hush::queueeditor::refreshQueue: we have no downloadOrder array. check data and try again.

It seems like if there is a downloadOrder array, debug message don't say much about it when the auto-download system runs.

Auto-cancel of transfer creates negative value in number of retries

If Hush auto-cancels a transfer for a passive transfer, the retry counter will display a negative value in the FCW:

[Jan07-13:04:47] Requested Pack - Heartland.CA.S13E09.720p.WEBRip.x264-aAF.mkv from [EWG]-[hAhA]-60
[Jan07-13:04:47] [Pack: #227][heartland s13][TV Shows][CANCEL]
[Jan07-13:04:55] Auto-Cancel Transfer of Heartland.CA.S13E09.720p.WEBRip.x264-aAF.mkv from [EWG]-[hAhA]-60
[Jan07-13:04:55] Reason: The transfer is from a passive bot (port 0). (Check settings to change this) [Autos: -1 of 2]
[Jan07-13:04:55] ===== Start of Auto Download Batch Loop =====
[Jan07-13:04:55] All files in local download queue processed. Finished downloading for now.
[Jan07-13:04:55] ===== End of Auto Download Batch Loop =====

Clicking to download a file from Instant Search generates red error in Debug Log

Sometimes an item in Instant Search will generate a red error in Debug Log. Example of the red error follows:

[Feb15-17:51:35] [KVS] Runtime error: Array index didn't evaluate to an integer
[Feb15-17:51:35] [KVS] In script context "hush::queueeditor::refreshItem", line 14, near character 17
[Feb15-17:51:35] [KVS] Code listing:
[Feb15-17:51:35] [KVS] 12 ...
[Feb15-17:51:35] [KVS] 13 %colOutput = @$parseColForOutput(%i,%st,%di);
[Feb15-17:51:35] [KVS] 14 @%lviDownloads[%qNum]->$setText(%i,%colOutput)
[Feb15-17:51:35] [KVS] 15 }
[Feb15-17:51:35] [KVS] 16 ...
[Feb15-17:51:35] [KVS] Window:
[Feb15-17:51:35] [KVS] CONSOLE [ID: 3]
[Feb15-17:51:35] [KVS] Call stack:
[Feb15-17:51:35] [KVS] #0 Array Element Evaluation [line 14, near character 17]
[Feb15-17:51:35] [KVS] #1 Scope Operator [line 14, near character 26]
[Feb15-17:51:35] [KVS] #2 Scope Operator [line 14, near character 4]
[Feb15-17:51:35] [KVS]

%G_hush->%optionsWidget occurrences need changing

at some point I changed the object handle %G_hush->%optionsWidget to %G_hush->%options

all these occurrences need to be changed as they are causing malfunctions.

found when the export settings to file option button is pressed in Options and it does nothing.

Download activated from FCW shows up as being from channel "IRC" and Download Queue entry doesn't update as it downloads

If you opposite click on "DCC" for a pack in the FCW log to start the download, the entry in the Download Queue window will be shown as being from channel "IRC" which is incorrect. The entry for the pack in the Download Queue window doesn't update as the download happens either in these circumstances.

Auto downloaded item evaded existing Search Exceptions and can't redownload

This bug is currently theoretical and I need to let time play out to see if it occurs.

If you have a file that evades your search exceptions and is moved to a configured media library location, it's possible that Hush will not allow a re-download of the same search term after you delete the file (if you have that option ticked).

Ideally, there needs to be a user-friendly way of searching the Permanent Record and allowing the user to remove entries from it to re-allow a future auto-download.

the aSTi bug

The aSTi bug occurs in the onQueryNotice handler and it happens when we look for a serchTerm in the %G_hush->%activeSearchTerms array.

What causes the aSTi bug is when we have 2 downloads occurring under the same searchTerm in the downloadHash. This is currently achievable if you manually search using instant search and download multiple items at the same time from the same search results.

Once you have multiple downloads from the same searchTerm going, when the first download completes, Hush will remove the searchTerm from %G_hush->%activeSearchTerms which is incorrect. Then when the second download ends, we get the warning about the aSTi bug conditions being met as %G_hush->%common->$fnArrayBinarySearch() returns a boolean $false value.

Hush was first designed with automatic downloading in mind, so when it looks to request a pack chances are it will look at the %G_hush->%activeSearchTerms array and if it finds the candidate pack's associated searchTerm in there it will stop what its doing and move on. If it knows it s a manual download, it will most likely just go right ahead and request the pack anyway. However, I don't think it's been explicitly coded to add an additional searchTerm to the %G_hush->%activeSearchTerms array in these conditions.

Need to check if it does that.

Manual Download requested from Instant Search falls under same searchTerm

If a manual search is performed and multiple desired items are in the result list, when the user clicks to request them, the items will all be listed under the same searchTerm in the Download Queue widget.

Because the items are in the same searchTerm in the downloadHash, if the first item completes the subsequent items will at least be marked as "Previous Pack Completed" in the Download Queue, which is incorrect.

I am unsure how this affects requesting/downloading of the subsequent items. Testing needs to be done.

Example: if you searched for "bad boys" the movies, and both Bad Boys 1 and 2 are available, you can request them both in the searchTerm "bad boys" in the downloadHash and Download Queue

Sometimes a Request stalls on the "Requested" status forever

Auto download system will request a pack from a bot and, for whatever reason, the download just stalls on "Requested" status in the download queue.

Need a timer system whereby a pack request will timeout if the bot doesn't respond within a particular timeframe.

"IRC Network Unavailable" status of xdcc pack won't be downloaded

If Hush attempts to download a pack while disconnected from an IRC network, the pack's status is set to "IRC Network Unavailable".

If all of the packs in a downloadHash{searchTerm} are marked as this, Hush will never attempt to download these packs again when the IRC connection comes back.

There needs to be a mechanism that looks for IRC connection and updates the pack statuses and resumes downloading.

Media Library Scan bug