Could ETA be made to work with Check before download option?

[sab12397]

Could I request an enhancement so the ETA is displayed on the Queue page for all items even if the Check before download option is selected?

I assume it is this option causing the problem since enabling it there is no means to know when each item in the queue is estimated to finish it only displays an ETA for the first item in the queue.

The Total for each item is known as it is displayed in the Remain/Total column could the ETA be based on this and the current download speed presuming just the same as when the Check before download option is not selected?

Thanks

[shypike]

The problem is that SABnzbd doesn't know the ETA's when it's checking.
ETAs are determined from a prediction based on the average download speed (of the last minute or so).
During pre-check this is an unknown as there is little relation between check speed and download speed.
There will be improvements in pre-check.
Currently it should be seen as an experimental feature that should *only* be used
if you cannot afford to download anything that is not likely to succeed.

[sander]

The problem is that SABnzbd doesn't know the ETA's when it's checking.
ETAs are determined from a prediction based on the average download speed (of the last minute or so).
During pre-check this is an unknown as there is little relation between check speed and download speed.

Maybe SAB could remember the "last known" speed and use that for the ETA.

There will be improvements in pre-check.
Currently it should be seen as an experimental feature that should *only* be used
if you cannot afford to download anything that is not likely to succeed.

I think pre-check is more and better than what you say. I have pre-check always on, and I like it: it gives me confidence in a download that is going to happen (or not).

To give an idea about the 'cost' (read: time) of pre-check:

Code: Select all

$ cat sabnzbd.log* | grep -i notifyOSD | grep -i bla

2012-07-22 15:39:57,772::INFO::[growler:267] Send to NotifyOSD: NZB added to queue / bla S01 E01 Pilot.nzb
2012-07-22 15:41:20,822::INFO::[growler:267] Send to NotifyOSD: NZB added to queue / bla S01 E01 Pilot.nzb
2012-07-22 15:54:44,142::INFO::[growler:267] Send to NotifyOSD: Post-processing / bla S01 E01 Pilot
2012-07-22 15:55:16,828::INFO::[growler:267] Send to NotifyOSD: Download Completed / bla S01 E01 Pilot

So the pre-check takes 1:23
Actual download takes 13:24
Unpack/repair takes 0:32

So I consider the 1:23 (which is 10% of the time?) a good investment. And I have no download limitation.

An improvement to pre-check could be: I would like to see how much is available, so "103% available".

[shypike]

Maybe SAB could remember the "last known" speed and use that for the ETA.

It's the speed of the pre-check which itself is harder to predict.
On my 100 Mbits/sec connection, pre-check takes about 20-25%% of the actual download time,
which is prohibitive for me. Especially given that few fail (and I have no caps).
As I am looking at improving the way pre-check works, I'm not going to spend
effort now in improving its looks.

[sab12397]

Thanks for reply.

I understand the pre check is an unknown time variable but ETA is only an estimate.

I understand I do not get a vote but for me it displaying something even if it excludes the pre check time is better than nothing.

I really miss knowing when my queue is estimated to complete.

[shypike]

The same happens to the ETA is you pause or have a short interruption.
Currently, the ETA is based on the speed of the last few minutes.
This is not necessarily the best method.
At some point, this will be looked at too.
As any software project (especially free open source) there are always much more
bugfixes, wishes and improvements than there is time available.
(And there's emails and forum posts to answer.)