I made recently some tests to see how sorting algorithms can still work when the comparisons have some probability to be false.
I made my tests on lists of size around 100 elements, and i haven't tested seriously with metrics of how "mixed" is a list, but still, here are my results :
For very small error rates (mabe under 2-3%), gnome sort is able to get very close to a fully sorted list. That is because it is able to correct past errors.
For bigger error rates, the problem is mostly that some algorithms tend to make mistakes that results in having 2 parts of the list that are independently sorted, but that should be merged.
For that, merge sort is a bit better, because it does make a "globally sorted" list, but it isn't really satisfying, because it has big errors. I would recommend doing something like merge sorting the list, and then gnome sorting it, so the gnome sort corrects some mistakes. You can get even better results when repeating the sortings multiple times (i found that merge sort twice and then a bunch of gnome sort works very well).
For your specific problem, gnome sort isn't ideal, because it is using a lot of comparisons, so, as mentionned before, merge sort can be very interesting for that particular purpose.
Finally, i must mention that, in the experiments i made, the one that gets the closest to a sorted list is the odd-even sort, that has almost no errors. The only problem is that it tends not to stop, because it always finds that there is still an element to sort (that is caused by previous random mistakes). But a simple iteration-counter that stops the algorithm after a number of iterations (that depends on the list length) does the job (also, changing the halt condition of the odd-even sort may work, but then it wouldn't sort perfectly even with no errors on the comparisons).
Special mension for that algorith because it is beautifull when visualised : odd-even sort visualised with bar graph
Just to drop a quick idea, you may create a data-structure to store the comparisons that the user already answered to (it would probably be a graph). To prevent the algorithm from asking hundreds of questions to the used, you may use transitivity of the relation "the film is better". As your question mentions, the transitivity isn't always respected by the user, so i would try to use the transitivity only if it is confirmed multiple times (example: you consider that A is better than B only if there are two other films X and Y that are such that A > X > B, AND A > Y > B, but not if it there is only one other film that respects that property).
But that technique requires manipulating paths across a graph or something alike.
Maybe you also could use marks given on each film, to confirm a certain comparison, so you could say "i'm shure that A is better than B only if the user already said that A > X and X > B and if the mark given to A is better than the mark given to B). If the mark is the same, or not coherent with the transitivity, you then would ask the user to give the actual comparison.