SFV Support

[Crise 26]

what we want is a feature that ensures that only complete releases are hased into the share, there is no such program.

Define "complete release"?

No, I am not stupid and I know what you mean by it, but my point is... there is no such thing as "release" defined anywhere in any standard... and no program can say if anything that has unknown number of definitions is complete or incomplete. This is a fact.

Thus, what you asked is impossible and as you said yourself there is no such program (even a DC client such as fulDC is not such a program).

What we can do is check finished file's integrity against an .sfv file but that in no way guarantees what you ask. Sure you can say that every scene release contains an .sfv file, but what you fail to see is this: DC is not the original distribution method for these releases, so it is perfectly possible that the .sfv is incorrect or has gotten corrupted during the transfer from scene ftp to DC users share in a hub (which is quite often through more than one people's computer).

Or alternatively, I could create a "scene release" of my own out of the dvd made from the film footage taken on my last family holiday in Egypt, and share it on DC, and no program could tell the difference between this fraud tailored by me. (with this I intend to point out, that creating .nfo files split-file archives and an .sfv, is not a secret zen art known only to those that release stuff to scene ftps).

Besides you seem to get the function of the .sfv file wrong, even though I am no specialist, I can be fairly certain when I say that its original purpose is to check the files for possible corruption during the transfer from ftp to users computer (DC clients have TTH to check for corruption during transfers), and hardly to check for missing files. (I can be fairly certain of this because, if scene release is incomplete, non working or corrupted it gets nuked).

However, as a final note, to check release completeness with the .sfv is fools doing, for in order to do that you could have to download many files that would turn out to be useless if the release proves to be incomplete (just use the .nfo file, your eyes and and your common sense to see if it is obviously incomplete or not, when queuing stuff).

Btw. If people request a feature for checking scene release integrity we can't implement such a feature because if we did it might be seen as encouraging our users into using our program for illegal activities, which we do not do or sign in any way.

[0ndjultomte 0]

Define "complete release"?

No, I am not stupid and I know what you mean by it, but my point is... there is no such thing as "release" defined anywhere in any standard... and no program can say if anything that has unknown number of definitions is complete or incomplete. This is a fact.

Thus, what you asked is impossible and as you said yourself there is no such program (even a DC client such as fulDC is not such a program).

What we can do is check finished file's integrity against an .sfv file but that in no way guarantees what you ask. Sure you can say that every scene release contains an .sfv file, but what you fail to see is this: DC is not the original distribution method for these releases, so it is perfectly possible that the .sfv is incorrect or has gotten corrupted during the transfer from scene ftp to DC users share in a hub (which is quite often through more than one people's computer).

Or alternatively, I could create a "scene release" of my own out of the dvd made from the film footage taken on my last family holiday in Egypt, and share it on DC, and no program could tell the difference between this fraud tailored by me. (with this I intend to point out, that creating .nfo files split-file archives and an .sfv, is not a secret zen art known only to those that release stuff to scene ftps).

Besides you seem to get the function of the .sfv file wrong, even though I am no specialist, I can be fairly certain when I say that its original purpose is to check the files for possible corruption during the transfer from ftp to users computer (DC clients have TTH to check for corruption during transfers), and hardly to check for missing files. (I can be fairly certain of this because, if scene release is incomplete, non working or corrupted it gets nuked).

However, as a final note, to check release completeness with the .sfv is fools doing, for in order to do that you could have to download many files that would turn out to be useless if the release proves to be incomplete (just use the .nfo file, your eyes and and your common sense to see if it is obviously incomplete or not, when queuing stuff).

Btw. If people request a feature for checking scene release integrity we can't implement such a feature because if we did it might be seen as encouraging our users into using our program for illegal activities, which we do not do or sign in any way.

Oh boy, you are really missing the point here. It's obvious that you are not a active dc users in anything but public hubs.

Yes a complete release is in this context well defined! And its the first thing one bases a eventual nuke upon. The SFV file! Tada...

The sfv file is a check sum that you use to verify that you have all the rar files and that they are intact.Hence why not use it ? Right now only the crc checking is done. Every single SFV check program checks for complete releases... if a file is missing there will be a log of that or even a file created in its place with the extension .missing.

Well since you cant see the point of utilizing sfv to more then 50%, let me put it in simple terms.

User X get a release written to a directory that is shared( via manual copying or ftp) when a refresh is schedualed the DC client check each file against the checksum and if its ok its shared, if not its not shared. And why not fully utilize the sfv? dont share each file directly only share each file in that directory if all files are ok.

This would mean that you could share a incoming directory and hence it would spread releases faster! and wont require manual labour (as in moving sfv checked releases into a shared directory) ...

It's all about sharing! Automating the steps makes life a better place for us all

A question for you, have you every downloaded a release and when its done just realizing it was a incomplete share that you downloaded? Now you have to search for that release again and start dl again to get the missing files! Extremely annoying and a waste of time.

[Guest Toast]

May i suggest a compromise ?

SFV Checker as a plugin ?

if anyone is good at making plugin this matter could be resolved fast then its optional :)

[0ndjultomte 0]

Look at the number of views of this thread! There is clearly a huge demand/interest for such a feature! and its just a extension of the already implemented crc check code ...

Plugin or not doesn't matter. As long as you get the functionality.

[Crise 26]

Oh boy, you are really missing the point here. It's obvious that you are not a active dc users in anything but public hubs.

That is incorrect assumption, the amount of public hubs I am in is a minority (since I only connect to public hubs where I have a key, with the exception of dcdev public).

Yes a complete release is in this context well defined! And its the first thing one bases a eventual nuke upon. The SFV file! Tada...

The sfv file is a check sum that you use to verify that you have all the rar files and that they are intact.Hence why not use it ? Right now only the crc checking is done. Every single SFV check program checks for complete releases... if a file is missing there will be a log of that or even a file created in its place with the extension .missing.

True enough, however, sfv checking is not a general cure for incomplete or broken releases nor is it a technology developed for that purpose. So in that sense it is incorrect to say that "Every single SFV check program checks for complete releases" it can only check for existence and validity of files which checksums are presented in certain sfv file, no more no less. (This is what I was trying to imply with my lookalike release example, which proves that if you rely on sfv too much false positives are possible).

User X get a release written to a directory that is shared( via manual copying or ftp) when a refresh is schedualed the DC client check each file against the checksum and if its ok its shared, if not its not shared. And why not fully utilize the sfv? dont share each file directly only share each file in that directory if all files are ok.

This would mean that you could share a incoming directory and hence it would spread releases faster! and wont require manual labour (as in moving sfv checked releases into a shared directory) ...

It's all about sharing! Automating the steps makes life a better place for us all

If it is all about sharing then you should understand the view which I'll present next. If you download a file and it is part of a release then later you realize that in fact the source you used was missing the file X, of course you'll go looking for that file and meanwhile your incomplete release is being shared and thus available through TTH auto searches for those who are also downloading them, but might be doing so from another source where the file X is present (ie. the source which you will most likely find when hunting for the missing file). Since downloading one file segmented from multiple sources is a reality now having the rar files you have for the release shared despite the fact that they are missing one file will actually help the files spread faster.

A question for you, have you every downloaded a release and when its done just realizing it was a incomplete share that you downloaded? Now you have to search for that release again and start dl again to get the missing files! Extremely annoying and a waste of time.

I will say only this, to this day a program has yet to beat my ability to think rationally and judge whether something on the net is complete/incomplete or worth my while in general.

Programs are made by humans so they are never perfect since humans are prone to errors in their logic. Even so humans and computer driven programs are not on equal footing. While programs, and computers generally, excel in speed there are other things where human mind can greatly outperform a program because of the way we can think opposed to computers since the level of abstraction which human brain is capable of is far greater than that of any computer or AI.

[burek 0]

dont share each file directly only share each file in that directory if all files are ok.

Isn't it better to allow users to download from you files you have already downloaded, while you are downloading the rest of the files? This way everything goes faster. Even torrents work that way, they even go much further, allowing users to upload finished segments of the same file, to users who need it, so you can upload to others those parts of file, you're already downloading, that are downloaded successfuly.

Long story short, in my opinion it is better that everybody share what they have and I will choose what to download from whom, rather than to wait for everybody to complete the download of all rar files in order to be able to share them.