You are correct in the factor being skewed when thinking of the entirety of the queuesize. The way Altbinz does things is a fifo style, and each complete set is unrar'd and the duplicates erased. The problem is the last file to be added has to be predicted if it will have enough space to unrar successfully and not trigger the free space setting on altbinz., hence it is the only file that relies on that *3 factor.
Unraring to another drive is not the most optimal for organizing. I have Network HD's ... they are not on 24/7, and also I don't want to clog my 100mb/s lan with unraring files or other luxury congestion. Also I archive to my network ... resulting in wise use of bandwidth. I delete the junk or bad quality, and I watch the non-archive material and erase immediately after. That is the optimal usage, because all your doing in the end is dumping it somewhere else ... my somewhere else is organized and has a controlled point of entry.
bool Download::onDownload(float downloadSize)
{
float m_freeSpace, m_requiredSpace;
char answer;
m_freeSpace = freeSpace - queueSize;
m_requiredSpace = downloadSize * 3;
if( m_freeSpace <= 0 )
{
cout << "Warning: Not enough space for current download!" << endl;
cout << "Continue yes(y) or No(n)? ";
cin >> answer;
if ( answer == 'y' )
{
return TRUE;
}
else
return FALSE;
}
else if ( m_requiredSpace > m_freeSpace )
{
cout << "Warning: Rough space required to complete this download and unrar sucessfully = " << m_requiredSpace - m_freeSpace << endl;
cout << "Continue yes(y) or No(n)? ";
cin >> answer;
if ( answer == 'y' )
{
return TRUE;
}
else
return FALSE;
}
else
return TRUE;
}
Above is a quick code I wrote to get my revised request. Nothing complicated, I am assuming there is syntax errors in there. Anyways upon importing the NZB, and starting the download sequence, a call to a function belonging to a Download class ... which ensures that the total current file being added to download will occupy the space left over from a 1 to exchange of space from the queuesize to the free space. Ideally with a compression factor in play, queue size should be 1.02 to 1.05 times bigger or 2%-5% bigger. Now the space left over is compared to the required space. This required space is the downloading file's size times the times 3 factor for expansion. This should determine whether there is enough space left to unrar succesfully the last file that is added to the queue. If not, a good estimate of the required space is spit out, with a user input to determine whether to proceed or cancel.
I hope what I am saying makes sense, this is what I call failure to communicate through over engineering
.
