Did some testing this morning, and it basically works.
I've also read these two threads/posts but i can't really see any of the problems they describe.

The streamed replay basically presents exactly what i was expecting from any other replay, all time information is there, race time, splits, laptimes, qualifying results. Cars move like usual, the only change needed in the header are the two missing track config bytes. (i think)

To try it locally, make a copy of temp_mpr.mpr once a second or so and change bytes 72 and 73 to match the combo.

Open up a second instance of LFS and play the copy.

The only problem i've come across so far is LFS catching up, maybe a read-ahead fails so the replay stops. LFS doesn't write continuously to the file but uses a small cache, and i'd guess dataflow sometimes decreases and the file isn't written to for several seconds. Still it does sort of work. I just watched two editions of a 6-lap race at the same time, the second edition about 20 seconds behind. Not a very interesting race, but the streamed replay played from grid start to race finish.

I think this could actually be a good (initial) solution, when/if we get keyframes in replays they'd probably work in a streamed one as well seeing how the replay format is designed. Also bandwidth usage is extremely low, while testing on a half-full server (which i'd guess ran 3 or 4 pps) i hit about 2.5 kb/s.

Has this been thoroughly explored?

Wow, that's really great news. So it would basically be possible that e.g. during a EPS race one person is on the server and records the replay. A special software would stream the datafile from his mpr directory and other people could use a client software to save the stream on their HD and watch it? I guess the only problem is writing the software, because there needs to be a LFS TV server software as well which receives the mpr stream from one person and is capable to stream it to dozens of other people.

Anyone's up o do this task? It would be really nice to have some sort of LFS TV in the future.

Hehehe, interesting, interesting... So if I understand correctly, what's needed is:
- someone online on the according race server to create the temp_mpr.mpr
- an app that instantly streams that mpr file onto an online host
- an app on the client side that "downloads" the mpr from the stream host and inputs it into LFS

?

I think the "input into LFS" part is pretty simple. The app only needs to write the streamed file into the mpr directory, nothing more. You open the streaming mpr just like any other local mpr. LFS shouldn't even notice that it's streamed.

Cool... so what ur saying is LFS doesnt check the replay in advance for a proper ending (whatever that would be, bit-wise)?
Edit: oh it doesnt indeed, now I understand the last part of the first post... wow, it actually looks pretty simple doesnt it...

So who's up for programming such an app? I can help with testing.

Quote from GP4Flo :

So who's up for programming such an app? I can help with testing.

Filur, I know he's got the skillz. Just to explain alittle on what he was doing. He was writing to the temp_mpr file with the game he was currently in. He then used a program to change the 72 and 73 to the correct values. He then opened another instance of LFS and started playing the temp_mpr file. Quite ingenious. How ever I don't think this could be used for streaming of files across the internet. Not with out alot of hacking going on. You'd have to use UDP, you'd have to keep the data pretty constant. 20 or 30 sec lead time would be ideal .

I'm up for testing and lending a hand where I can Was thinking along the lines of streaming replays a few weeks ago, but I never got around to trying it out - and don't have the skills to do much about it

The main problem I imagine would be to watch the replay live (I mean with a slight delay).

If someone connect to the stream at midrace, LFS will read the mpr from the start and won't know where does the stream file start. Also, if the spectator do a fast forward by changing the speed, LFS will not detect the point where it can't go forward longer and will probably send an error (or crash) instead of waiting for the stream.

I've just tried it.... it's FRICKING genious thats for sure.... dont get why I should change bytes 72 and 73 though? It works without doing that here.


Edit: oh right, I see now... too enthusiastic at first... the other instance was running on SO Classic, while I tried SO Town online. So it went crazy after t2

Glad to see people are trying to make it work. As I was about the 15th person to suggest it


so, does it work?
Does it work effectivly?
Can people watch races live, instead of waiting for replays to be edited?

Just a few Q's

Quote from The General Lee :

so, does it work?
Does it work effectivly?
Can people watch races live, instead of waiting for replays to be edited?

It's more of a Proof of Concept, than a "real" system imho. The main issue being that basically you're serving an ever changing replay file to multiple people, if you join a session half way through, you need to start at the beginning. It's certainly a step in the right direction despite this

filur, I've thought about this take quite a few times, although never had the opportunity to sit down and do any testing with it. In theory a traditional server-client program, using some magic with a webdav server and symlinks / ntfs junctions would be possible or some other bespoke system, would be very possible, but it does have that one limitation above; although its not really a big problem

I dont know what the mpr files look like, but maybe its posible to request a modified header of the mpr-file when connect to the TV-Server, then it could be possible the join the TV-server midrace and watch.

the problem I see in this is that you may of course get a modified header from the tv server, but you have the whole temp_mpr.mpr-file that is there on the harddisk and you can not determine where the race is at the moment.

But actually I can join a server midrace and my LFS starts to record a mpr file. So I would guess it must be possible to get a header an then the mpr data from that time I join LFS-TV server without the hole file from the time before.

But its just a thought I have no idea .

The problem is, how do you get the header to each individual when they join, if you're only writing to one file? Unless there's like a header file written for each replay, so that the client program reads the header THEN reads the rest of the mpr from another file. No idea.

I don't see a problem with this. Every individual would have to watch the replay from the beginning. So his client would connect to the LFS-TV server and download the whole replay which has been uploaded so far.

The main problem is that the client has to continue downloading the replay, so someone needs to write a special software for that.

Quote from GP4Flo :

Every individual would have to watch the replay from the beginning.

Not nice when u want to see the last hour of the 24h race live

Isnt it possible to create a new file for every client? I think that's what JamesF1 suggests too. A new file with an mpr header gets created for every time someone connects to the LFS TV server and from then on the client uses the incoming temp_mpr stream on his own file..? Files could grow quite large though, and especially with a couple of people connected, space on the LFS TV server might run out soon...

this is good news, filur! thank you!

No, what I meant is this:

Each race replay would have a specific header, containing information about the track, the cars, etc. I would presume (although I don't KNOW) that this could be relatively easily generated for any given moment in the race (seeing as each replay has a header).

When a client joins, they get sent the header based on the MAIN REPLAY POSITION.

So if a client joins at the start, they get a header based on the start. If I client joins mid-race, they get a header based on that point in the race.

Then, the stream will essentially be the same. So, what I'm suggesting is that, should it be viable, each client gets sent a custom header, and is then "passed onto" the "regular" stream...

Maybe I don't explain it very well

Quote from JamesF1 :

No, what I meant is this:

snip..

Maybe I don't explain it very well

I think I see what you're getting at now. Basically you mean that the "relay" is aware of the point in time when a client connects. It then takes the incoming stream, chops out the data that occurs before this point, and hacks the header - typically by setting the "immediate start", "number of players", results, etc. flags.

In theory you wouldn't need to create a file per client, but store this all in the memory on the relay. Using something like APR's buckets and brigades to chop and change the MPR without too much duplication. The "problem" with doing this is that we'd need to understand the whole MPR structure, and how its written to the temporary file; which we don't at present.

I think it's quite pointless to hack it like this... Doubt this streaming would work properly. That's something for Scawen to implement.

Replay system & MPR format needs updating anyway.

Quote from hackerx :

I think it's quite pointless to hack it like this... Doubt this streaming would work properly. That's something for Scawen to implement.

Not much hacking involved, streaming basically works properly already.

Quote from the_angry_angel :

Basically you mean that the "relay" is aware of the point in time when a client connects. It then takes the incoming stream, chops out the data that occurs before this point, and hacks the header - typically by setting the "immediate start", "number of players", results, etc. flags.

I don't think that this is currently possible. AFAIK the replay files do not contain the simulation state information; Instead, the user inputs are loaded from the MPR and fed into the physics engine to generate the next simulation state. Hence there is no way to 'chop' previous data from the file as the current simulation state depends on all that previous data.

We would require the equivalent of keyframes in the MPRs for that sort of mid-race join system to work.