Changes in FTP release structure

[mrpijey]

Just a little heads up, I am changing the structure of the releases slightly, individually packing up each svf patch file so it's easy from the FTP to see what patches are included. So instead of a single media_svf.rar file without any clue what's inside there will be a media_svf\patchfilename.rar which contains the packed up svf file, often with it's original filename. In those cases where there's no ISO etc but only unpacked installer I will pack it up in a zip before patching. I am also working on breaking up the media_-rar files in general into individually packed up archives, so instead of a single media_iso.rar with several discs inside etc there will be media_iso\Disc01.rar etc instead.

All releases with a patch file set inside will also lose it's base language in the folder name, i.e instead of "My Release [English] [+]" it will be only "My Release [+]" instead. While I will try to maintain English as the base language there will be instances where English is missing, and then i will choose an another base language. But since all the patches will be visible individually this shouldn't be an issue. But [+] will from now on means that there are several individually localized releases within that are patched.

It's all a work in progress to try to find the best balance. For a sample take a look at '\(Misc) Compilations\PC (MSDN Downloads)\Applications\', which is where I started and you'll get an idea where this is heading.

I am also working to make sure the contents of the media_-folders will be displayed in the database.

This will foremost be applied to abandonware, but I am also looking into patching large releases if there are smaller incremental updates etc, so instead of having two large releases I might reduce the second one to a patch. I've done it so far with Star Citizen, but I might also revert it if I don't like it. Work in progress...

[Win7]

While thanking you for the announcement, as a long-time FTP member I honestly have perplexities – I have seen the FTP release structure change multiple times, and while I do acknowledge that the website and all the infrastructures are subject to (harsh) fees, that all the hardware it is relying on is expensive and all, I think that the overall browsing experience was faster in the (recent?) past than now, as anyone could more easily locate what they needed.

To be more precise, I strongly appreciated it when you sorted the Compilations folder and divided all of its content by platform and media source, so that one could tell apart MSDN downloads from dumps of physical media, but on the other hand locating the right language of a certain software has been seemingly getting harder and harder: up until a year ago, I would look for "My Release [English]" or "My Release [Italian]" and I would go straight for that one, instead of having to expand an archive with all the languages or language packs. And this one measure looks like no exception.

This is by no means an attack to anyone, but it's just a matter of understanding these ever-changing policies in order to better adapt to them. It could also be me being narrow-minded and a creature of habit, but anyway...

Win7

[mrpijey]

This is why I am packing up the patches individually since you can then see if we have a particular language, instead of having it all baked into a single rar-file. But the patches are necessary since we save a lot of drive space and the archive gets a lot easier to manage. And you also don't get 50 hits when searching for a particular title since all the languages will be contained within. So I understand your point of view, but I would also understand the other side not wanting the FTP to be flooded with almost-the-same releases but in different languages. Especially since Microsoft keeps releasing everything in separate languages instead of making one unified disc with all of them.

It's also not easy to come up with the perfect layout either, since there are so many different kind of titles across so many categories, and I need to consider many factors such as archive size, dedup efficiency, path length, release count etc as well when making a proper layout. Since we can't yet use the DB for downloads I will have to take some shortcuts for the time being, but in the end you will get your wish too as every separate language (stored as a patch) will be included in the DB as well.

[MrUTB]

It must be nice if you and your team develop a little system where uploader could to know how is going on with its uploads.

[mrpijey]

While offtopic, there's no system to develop here other than perhaps some simple notification system attached to the FTP application process. Otherwise there's no point since the process is simple: I download the uploads to my system and put them in the processing queue, and I process it whenever I get the time. And depending on how well the uploader bothered with reading the guide it will either go quick to process the release, or it will take a long time to do it. If it's quick then I will most likely prioritize it since my time is limited and I'll put off the more difficult ones until I get more time to do the heavy processing. And since I am alone doing the releases processing I can only do it when I have the time. There's very little automation that can be done here unless we have some custom uploading routine which can properly detect uploads and who uploaded them.

And a lot doesn't ever get processed because the member never replied to my rescan/redump request, or simply because the member didn't bother reading the guide at all leaving me with a completely useless upload. I tend to just ignore these as they are in 9/10 times made by members hoping for a quick and lazy way onto the FTP. In the past I used to email each member about these, but I quickly found out I would spend more time PMing members (who mostly never replied back) than processing releases. But I do respond to PMs if members have questions. And if we had more members willing to help out with processing it would also get quicker as I have a pretty heavy backlog of potential releases. Remember, 9/10 FTP applications are also often made by members who never uploaded anything (as required) or just uploaded some junk off some other site or an improperly prepared disc dump.

But on the related topic, maybe it would be of interest to keep an update thread about the FTP structure?

[computebrute]

An FTP structure changelog would be nice, yes.

[johndoe123]

I'd say that this is a very good idea. When will it be done though?

[DOS]

The changes sound good! I am curious as to why the patches give a disk space improvement for you when you already have deduplication, though? They'd certainly give a disk space benefit to me if I wanted to download multiple language versions of one piece of software since I don't use it!

[mrpijey]

It will be sorted as soon as I come up with a structure for the log.

And while dedup is good it's not as effective as using the patches, since the patches can handle much smaller chucks to further reduce the size. Dedup also doesn't decrease the total release size if you choose to download more than the default language.