gibberish

Member
  • Content count

    5
  • Joined

  • Last visited

About gibberish

  • Rank
    Newbie

Contact Methods

  • ICQ
    0
  1. SFV Support

    you are 100% wrong. sfv is released with EVERY scene mp3 release, failure to do so results in an instant nuke.
  2. SFV Support

    the whole point is that the P2P'er DOESNT MAKE THE SFV. the sfv is made by the scene before the release goes out. it is relaitvely easy to tell if a sfv has been remade by a user on a p2p network. if you are conscious enough to use sfv's in the first place then you are conscious enough to know not to remake them yourself. when in a hub of ONLY scene releases, the one or two people with a remade sfv stand out 1 mile apart from the other 100 users without a remade sfv, because your search box will show: +98 01-artist-track-sour.mp3 +02 01-artist-track-sour.mp3 it is obvious that the 98 people with the same file have the correct sfv, and the 2 people with a different version of the same file have either a) not tested their files with the sfv or tested their files, realised that their files are corrupt and remade the sfv (unlikely). the implementation of sfv support would rule out scenario A because it would be done automatically upon download, hence less people would be sharing 'bad' files.
  3. SFV Support

    im sorry but you obviously mis-understand what sfv's are for. when an mp3 release (or any other for that matter) is pre'd, there is an sfv file. the sfv file contains the checksums for the files inside the release. on p2p many people like to edit id3 tags, transcode mp3's, or make adjustments to files - this means the files are not original. but it is hard to see with the bare eye... so you run the sfv and it tells you if the files are original or not. nothing needs updating, the file is already made. sfv DOES ensure the archive is completed. there are ways to tell that your sfv is original. also, it is a good bet that if somebody value's sfv files enough to check their files with them then it is unlikely they would merely make a new sfv if their files failed crc check. i know very well that that behaviour doesnt happen in our hub, because we value original releases.
  4. SFV Support

    no this is not a cosmetic feature, it is necessary when archiving scene releases. it is not about file corruption, it is about making sure that files are as they were when they were released and is important for many hubs which specialise in segmented downloading. i can find 20 sources for the same file in a hub of ~100 people thanks to people who collect scene releases only.
  5. SFV Support

    +1 for sfv support it was one of my favourite features in dc++, to see it in apex would be very useful. i usually forget to check my files after i downloaded so to have it done automatically is a great help. great client by the way, i only switched a month ago and i'll never go back to dc++