I tried it out just now... Connected to the Stress test server, got the header, went into LfS, clicked lfstv, clicked play... It loaded the track fine, but then it said "Couldn't load skin:" with WolleT's skin and helmet and I was back at the main menu... Happened on WinXP Prof. 32-bit and Patch U22, if that helps...

Quote from WolleT :

Never had more than 6 watchers on the relay.

LOL, that must have been 100% our teammembers then! (were watching EAS pool 1 race the other day)

Anyway, fantastic work on that application, looking forward to seeing this develop in the future!!

Quote from maczo :

Also, I've got a question: what happens if there are no racers on track? Is any replay data sent then?

Hm, good question, i think yes, because you are on the server as a spec. But i think also it takes a lot of time until the data will be send.



Yesterday i updated the client version. Had some problems with the communication between caster and relay server. I hope this problem is solved.
There was also a problem in the serverlist, some "dead" caster was shown.

Today i will update the client again. I will include a notice in the serverlist, how long it takes until the header and the replay data will be received. Also i will include a message in the log, when the replay is ready to watch.

LFS keeps writing to the mpr file when there are no drivers on track, but at a much slower pace. Thats one of the biggest drawbacks I see in LFS TV, the server should be able to 'decide' on the fly which transfer rate to use, which can be tricky to say the least.

Well, if you measure the rate at which the file grows, you can calculate the rate at which you should stream.

Yes, and the clients should be also synchronized to read at the proper speed, depending on how much data theyre receiving, so the server should not only send actual mpr data, but also bitrate info to prevent clients reaching the end of the replay.

There is no problem with the data speed. Only the watcher has to wait a little longer for the header and the first replay data. If he got the first replay data, he can watch the replay normal.

Its not about the beginning of the data but the end. If a client has a read rate of say 10 bits per second and it only gets 2 because no cars are on track, that client will reach the end of the replay and stop, thinking it has reached the end of the mpr. Somehow server should 'tell' clients to read at a slower pace when the actual data written to the mpr slows down.

No, LFS is playing the replay everytime in the same speed. It doesn't matter how many cars are on the track. The replay data will always played in the same speed.

Only the packet size is variable. For example, the data for one car is 160 bytes per second (example too) in the replay. Then in the replay is a time packet with data how much car packets are follow.

So in the one car replay every second there is a TIME-packet and a CAR-packet. In a three car replay: TIME-packet, CAR-packet, CAR-packet, CAR-packet.

When the caster sends every kb the data, it will take 5 secs on the one car replay until the replay stream will be send. On the three car replay the packet size is after 2 secs reached.

So i have the same time data in both replays, only the traffic is higher in the three car replay, because it has more car pakets in for a second.

BUT this is only an example, i'm not sure about the replay data structure. I only know it from the testing, that it's working like this way.

I hope you understand my poor english.

We got office crisis here now, but I'll come back to this later, I'd love to get this working

This is great, I had thought a lot about in game LFS TV, but always thinking about conecting as spectator to a "fake" relay server. This is much more straightforward, even if it brings its own shortcomings.

Voiceovers are not much of a problem, you can always set up a ventrilo, teamspeak or whatever server. If the delay for all clients ends up being more or less similar (say within 5 or 10 seconds) and the speakers are watching a delayed stream themselves, it should be mostly ok for general commentary.
Maybe you could even somehow skip enough time frames for the latecomers once they are already watching so they can catch up and every ends up pretty much in sync.
Another cool thing would be having the mpr client start LFS by himself and load the mpr file when it is ready, I think the latest LFS versions can do that.

And crazier stuff. If the relay client acts as a server itself, the main server could redirect new connections to willing clients, and you could have potentially thousands of people watching almost live races. And then here come the sponsors... mwahahahahahah

Quote from WolleT :

No, LFS is playing the replay everytime in the same speed. It doesn't matter how many cars are on the track. The replay data will always played in the same speed.

Isn't this the problem itself?

If a broadcasters LFS does not write to the temporary mpr for some time, no data can be sent to clients until it does (unless you manage to grab mpr data from memory / internal buffer). LFS still buffers and plays the replay at the same speed, meaning that if there was no data sent for some time, a replay can reach 'the end'.

Setting a bitrate wouldn't solve this, but the relay could broadcast a pause / unpause for clients to send thru insim, pausing playback if data flow is too low.

What a great app:

I tried it with my teammate and it works nearly fine! One problem I see is the user himself who cannot wait till the message "replay ready to watch" is out - there must be a message like "plz wait - this can take a few min" instat of "conected"

We tested on a server with 12 racers and it seams to work fine till the first or secound racer has finished. Then there was a LAG and LFS told me about an error in the .mpr file.

I closed LFS and LFSTV, tried it again and could watch till the vote for a restart was done. Then LFS was jumpin back to the MAIN-Menue.
But I think this is normal - a mpr can only save till the race restarts.

Then I closed LFS and LFSTV, tried it again and could watch the Race till (i think) a new Racer has connected or joined the race. Then i read the german message: "kann Wageninfo nicht hinzufügen - unbekannte ID" after i was kicked to the main-menue.


Durin all my closin and restartin of the app - ELR```Button was allways connected!

Another little bug: I connected and saw the field standing in their startin possition and after the Crosslightning switched to green the drivers was shown in the secound lap by passin the Startline - then LAG after 10 Secounds.

Hope I could help and wait for the next releases!

this is getting more and more awsome! keep up that good work

Wow. This is cool (I think i've said wow about 5 times in the last 30 minutes )
I'll try and see if I can get this working with LFS FM broadcasts.

It says error when I try to download the latest version.

Try harder next time

http://www.triso.de/download/lfstv/lfstv_0_0_1_6.zip

This a great idea!

But is possible to generate a video streamming like *wmv streamming?

This is a real TV streamming for all people...

JS

Quote from jscorrea :

This a great idea!

But is possible to generate a video streamming like *wmv streamming?

Yes with the relevant hardware, and its been done by a number of leagues in the past.

I wont waste more energy on explaining why LFSTV is a good idea, rather than streaming.

I did trie it with somebody and we both get this msg in LFS:

File failed header check ...\lfstv.mpr

it was me.

i tried to watch another race and it worked. That means we both did something wrong with caster setup.

but what can u do wrong?

i don't know.i e-mailed tom(the guy who created it i think) about the incident and waiting for the reply now.

do u have allways other streams in LFSTV?

any1 with this can they watch what im casting at the moment? (COPS AND ROBBERS UK)