cabji / hush Goto Github PK

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 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]

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.

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.

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.

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.

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.

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.

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 =====

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.

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.

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.