It will only play the ones of the same version that it recorded. To play the other ones you will have to find out what version it was used to record those demos and install that version to play them. Thats one of the biggest disadvantage of demomanager
UT has its own engine for demo recording and demomanager runs a custom one. Sometimes demomanager can play the demos made with the UT engine one. It is kinda like a mismatch when it isnt able to play another demo.
Technically, you can play demos if your client can reconstruct the package/objectmap of the demorecorder's client. In reality this means that demos recorded by people using v432, v436, v440 and v451 can be played by anyone using v432-v451b. Demos recorded by people using v451b can only be played by people using v451b. The actual demo recording engine doesn't matter. Demo Manager needs to be registered as a demo recording engine to make some of its demo playback features work but under the hood it's still using the regular Engine Demorecorder for the actual recording.
I've been toying around with an experimental fix for this problem but it's not really worth it. The only solutions I can see are:
1) Have demomanager store extra meta information when it records a demo (full packagemaps and objectmaps). This would come down to an additional file of ~100Kb that needs to be stored for every demo (and read by demomanager when opening the demo for playback).
2) Have demomanager store every package in the packagemap for every demo (this would require 100+Mb extra for every demo).
Both solutions would require demomanager to hook into the actual recording process (which isn't happening right now). Moreover, solution 1 isn't garantueed to work (although in most cases it would). In my current development version, demo manager just shows a popup if your client is incompatible with the demo you're trying to play.