[WiP] Timeshifting in a single looping .ts file (2 Viewers)

[mbuzina]

how about first documenting all requirements to the buffering mechanism and then try to design a solution that fits best? (sorry just my 2ct, I know more theory than practice, but sometimes standing back is quite usefull).

So what should the time shift buffer allow:
1. Each stream sent to a client should be buffered
2. Each stream buffer should hold at least min buff size bytes of stream to allow skipping
3. When a client changes channel or switches off, my idea: unused buffer is discarded, a new buffer is created viewing is started from the live point on.
4. When a client pauses a stream, the stream buffer continues recording to the buffer, playback is halted. Buffer grows unti lmax buff size is reached
5. When max buff size is reached, the server stops adding to this stream buffer
6. If another client is timeshifting of the same buffer which has grown to full size, and current client would miss data, a second buffer should be started and all currently viewing clients should be moved to the new buffer as soon as they pass the starting point of this buffer.
7. Any client can scan through all existing buffers for a given channel
8. Buffer shrinks to min buff size after all clients view point is past this point in the buffer (can be lazy).

Other requirements?

 

[disaster123]

AW: Re: AW: Timeshifting in a single looping .ts file

ah thanks arion - really didn't know that. So this won't work atm. Any ideas?

The only way I can think of is that each TsReader should place a shared lock at the current file position being read making sure that at no time it leaves the file without a lock in place (i.e. first place the new lock then release the previous). The lock can be 1 byte long. TsWriter OTOH should try to get an exclusive lock on the region of the file it is about to write before writing anything. The lock should span the entire region that will be modified (not just one byte). If the lock cannot be obtained (the call should be non-blocking) the data should be discarded - the buffer is full.

Use LockFileEx() to place shared and/or exclusive locks. I do not know how well this works over network.

I hate to repeat myself, but I find this a better solution. Locks are atomic, the OS automatically keeps track of multiple locks from multiple clients and it is a hell lot easier to implement

Yes i think the same. The only think to benchmark would be how fast locks over SMB are. I had some bad experience with them in the past - trying todo nearly the same with miroslavs patch to ensure that the client doesn't read pos. where the writer is still writing - the result was even more stuttering.

 

[FreakyJ]

AW: Timeshifting in a single looping .ts file

The problem isn’t timeshifting, right? So as I told before the best solution would be to fix RTSP. Mirsolav already mentioned that he is willing to have a look at.
The advantages are easy:
1. We don’t have a new timeshifting concept which maybe introduce new issues
2. We use a concept which is already implemented in MP and easy to set up

To introduce a new timeshifting format would be like to give somebody a new heart because he has high blood pressure…

 

[dvdfreak]

If someone fixes RTSP to zap as fast as a timeshift file, and to be just as reliable in playback -- I agree.

But these may be two big ifs, depending on who's willing and capable of looking at these.

 

[glenn 1990]

I also have problems with unc, tsreader sometimes stops or playes a old ts buffer when the server switches the timeshift file (few times a evening).

I tried everything to solve this (changed tcp settings, autotuning, switched network drivers, NIC, router), the problem was gone for a while, but now it's back and I changed nothing. So I don't know what to try now.

I'm also using For The Record, but I've the same problem with MP. I also get many freezes with RTSP.
So 2 streaming methodes and none is working fine.

I'll be a very happy person If this patch gets in the svn.

 

[mcrob83]

AW: Timeshifting in a single looping .ts file

Feature here, feature there...but what has to work, are the basic things first of all. When they got to work, we can talk about things, that extend the functionality. Thatswhy I've changed from MP-Server to 4TR Argus, because the assembling is clear and working good with many good features, that make the administration easy. Since 1.1.0 Beta there's a good progess in MP's stability, but the main bugs especially when watching tv for a longer time with lots of zapping, where never solved.
Thatswhy I support everyone's work here, who is now working hard to push Media Portal and Fortherecord where they should be.

 

[tourettes]

Re: AW: Timeshifting in a single looping .ts file

Feature here, feature there...but what has to work, are the basic things first of all. When they got to work, we can talk about things, that extend the functionality. Thatswhy I've changed from MP-Server to 4TR Argus, because the assembling is clear and working good with many good features, that make the administration easy. Since 1.1.0 Beta there's a good progess in MP's stability, but the main bugs especially when watching tv for a longer time with lots of zapping, where never solved.
Thatswhy I support everyone's work here, who is now working hard to push Media Portal and Fortherecord where they should be.

Please keep this sub forum only as technical discussion (and test results directly related to the proposed patch) about the patch that is in the topic of the thread (first post).

I really hate when I have to clean up this part of the forum from general chat. Consumes just too much time... time that could be actually used to fix things or write new code. And it is not only my time that is lost, other devs need to filter out the "noise" as well. So, please try to avoid the general talk.

If there is some general discussion or bugs in the current code please open a new thread (or search for an existing thread that fits into the topic).

Thanks for understanding.

 

[dvdfreak]

Perhaps we can move on to more essential things: has any of the MP devs tried the patch? And if so, could they give some insight on the zapping problem?

Somehow tsreader gets confused right after a zap, when the file is seeked to the end... The strange thing is that only the filereader is replaced with the new one, so it should normally not even be aware the bits are coming from a different source, but yet something goes wrong.

Any help or insight on this?

 

[tourettes]

Perhaps we can move on to more essential things: has any of the MP devs tried the patch? And if so, could they give some insight on the zapping problem?

Sorry, I have no live tv that I could debug on (living room HTPC is off the testing territory ).

Somehow tsreader gets confused right after a zap, when the file is seeked to the end... The strange thing is that only the filereader is replaced with the new one, so it should normally not even be aware the bits are coming from a different source, but yet something goes wrong.

What is the actual behavior that happens on those failed zaps? Does the playback just freeze?

It could be that timestamps are somehow messed up.

 

[dvdfreak]

Somehow tsreader gets confused right after a zap, when the file is seeked to the end... The strange thing is that only the filereader is replaced with the new one, so it should normally not even be aware the bits are coming from a different source, but yet something goes wrong.

What is the actual behavior that happens on those failed zaps? Does the playback just freeze?

It could be that timestamps are somehow messed up.

OK, let me perhaps start by giving some solid facts, to make sure we can zoom in on the actual problem:

1. The .ts file itself is ok. It's exactly the same data that's written as to the .tsbuffer file (and that zaps fine).
2. The issue occurs even before the file has looped/wrapped, so the situation is in fact almost identical to .tsbuffer.
3. After a messed-up zap, if you skip back e.g. 30 seconds and let it play -- it plays fine, also accross the zap, and shows the new channel without problems.

And yet, the seek and resume playback after a zap shows artifacts. So let me try and describe what happens:

Important to say: sometimes it zaps fine. But most of the times it zaps, then shows a freezed frame of the old channel for a second or so, after which the new channel shows up, but totally messed up (showing video and audio continuity errors in the log) -- and it stays messed up until you skip back like described above.

Other times it zaps, freezes momentarily and then shows the new channel after some messed up frames (to it seems to recover).

Does this help in "guessing" where the problem might lie?