Request system

Issue #31 new
Gfy created an issue

The obvious main usage for a request system would be for people that are actually looking for a certain SRR file, but the system should be designed to preserve as much historical information as possible when no SRR file is available. Being able to use it for requests should be the side effect.

I see two different use cases:

  • Someone wants to have a certain SRR file so he can reconstruct a release.
  • Someone wants to have a missing file: an NFO, a sample,...

I think this should be two different request systems. I'm going to call them release and file request.

System 1: release

When a user wants to request an SRR file, he must upload at least one file too! This can be an NFO, SFV, SRS,... In the worst case this is an SRS for the main movie file. This way we get to preserve stuff. I see this can be a problem for music or games. For music we could allow bad srs files to be uploaded. (it could still give useful flac information for example) For a game the .cue could be used or let them calculate the crc/md5 for the iso they have and put it in a .sfv or txt file.

The more files added, the higher up in the list of requests with the same amount of votes?

Admins can remove files and other people can also add files to existing requests.

This system could be used to dump nfo databases in. This is not abuse, so there should be a way to indicate real requests vs info. By default it could be given 0 votes. The creator has to explicitly vote for it. (this can be checking a checkbox upon creation and/or pushing a button)

When new SRRs are uploaded, the table with requests should be checked. If the new upload was for a request, all the files of the request will be added to the adds queue.

It should be possible to add a list of file names. (found through some cache or the Internet Archive)

APIs and/or scripts could be made available for adding content to this. Different files with the same name should be possible.

System 2: file

The second system is for asking things that aren't available in an SRR or in the request. Currently I see two types: a request can be made for a missing file or one can request a file name.

The type and the file extension should be given. This way someone can view only the requests for NFOs for example. Have an option 'other' when the extension isn't known/in the list.

Someone can have an old divx release and grabbed the nfo back in the day from isonews.com. It looks like "Movie Name - Group.nfo". When the release request was made, this NFO was added. This is what the file name request type is for.

This can also be used when a broken proof file is only available: no checking of what is actually there. Unless for requireing to set a larger message.

In this system users can enter text. We might require checking them so they actually don't request illegal stuff.

Something to notify admins when a request is fulfilled. Maybe allow comments for this?

Other

People should be able to vote for/view requests in both systems. Who added/changed what should be kept internally.

Mail/pm voters when a request has been fulfilled.

Some list search like adding of requests. (but still require adding files though) If a user can't be bothered with this, why should we?

Ranking requests: votes, # files, # srr uploads/requests by voters,...?

Keep a list of deleted requests? This way we can ask the user if is sure to add it again. Store delete reason: e.g. SRR is actually on the site under another name.

Requests should be (batch)confirmed?

There are gabs and maybe inaccuracies. How would you solve these?

Comments (0)

  1. Log in to comment