[WiP] Timeshifting in a single looping .ts file (1 Viewer)

[tourettes]

Definitely not true. When a second client tunes to a channel already tuned by another client, the second client will simply get access to the existing timeshift buffer. It will not create a new one.

OK, this is not the case in For The Record. Here, every client gets his own file, much easier, especially when clients start to zap around. They own the file/rtsp, so they can zap as much they want.

We have the shared buffer in use since it allows new user to see the already timeshifted material that some other user has caused to be generated. Also you can swap to a different HTPC and then continue with the different client and the same TS buffer content is available).

Other issue that we have is the HD bandwidth. The original .patch thread that this .patch was "forked" was trying to fix the extensive HD usage. Now it would bring part of the issue back since reading and writing would be much more IO agressive (reading same buffer / file multiple times is getting a benefit from OS cache).

 

[disaster123]

AW: Timeshifting in a single looping .ts file

arion_p
but this is only working with rtsp right? Is there a chance that the rtsp bugs get fixed in tsreader? I mean is there anybody in the MP team who can do this?

 

[miroslav22]

We have the expertise, it's just a question of priorities unfortunately

I'm more than happy to look at the remaining issues with RTSP as soon as 1.2.0 beta is out.

 

[arion_p]

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

@arion_p
but this is only working with rtsp right? Is there a chance that the rtsp bugs get fixed in tsreader? I mean is there anybody in the MP team who can do this?

Nope, it works with UNC as well (that is if UNC works for you)

 

[disaster123]

AW: Timeshifting in a single looping .ts file

It works here most of the time. Will try that.

 

[dvdfreak]

Definitely not true. When a second client tunes to a channel already tuned by another client, the second client will simply get access to the existing timeshift buffer. It will not create a new one.

OK, this is not the case in For The Record. Here, every client gets his own file, much easier, especially when clients start to zap around. They own the file/rtsp, so they can zap as much they want.

We have the shared buffer in use since it allows new user to see the already timeshifted material that some other user has caused to be generated. Also you can swap to a different HTPC and then continue with the different client and the same TS buffer content is available).

Interesting information, but aren't these very rare use-cases? Who benefits from this in practice? It sounds cool from an engineering point-of-view, but in the real world I don't see a really huge benefit either.

 

[tourettes]

Interesting information, but aren't these very rare use-cases? Who benefits from this in practice? It sounds cool from an engineering point-of-view, but in the real world I don't see a really huge benefit either.

At least few team members are using the functionality (I am not ). But like arion said that you can watch the live tv on living room and then pause the stream and go to bedroom to continue the watching (in future with proper UI support). With the proposed change you would be losing the duration that takes to move between rooms (and probably you want to do something else like brush your teeth etc in the middle).

We should keep in mind that this patch shouldn't be reducing the possible use cases when compared to the current way how things are working.

 

[dvdfreak]

We should keep in mind that this patch shouldn't be reducing the possible use cases when compared to the current way how things are working.

Not necessarily. If this new way of timeshifting is added as an option, you leave the choice to the user. If he gets better and more reliable results with .tshift, but loses the pause/resume you just described, he may choose for more reliable and stutter-free live TV anyway

 

[tourettes]

We should keep in mind that this patch shouldn't be reducing the possible use cases when compared to the current way how things are working.

Not necessarily. If this new way of timeshifting is added as an option, you leave the choice to the user. If he gets better and more reliable results with .tshift, but loses the pause/resume you just described, he may choose for more reliable and stutter-free live TV anyway

Options are nightmare from maintenance point of view. The more you can unify the used code the better. It would be good if we could drop for example the RTSP completely - it wont be good just to add bunch of code to increase the amount of maintenance work - MP1 has mainly maintenance work nowadays ).

In my opinion the patch should be good to replace the current way of TS buffer handling or otherwise it is not worth adding (of course I'm not making that decission).

 

[dvdfreak]

I still think the use-case you described is low-on-value I would rather hit Record and be sure I won't miss anything, and on top of that I can turn off my first client, after which I can move to my second client, playing back the recording I had started.

But that's just me What happens to that first client anyway in your example? It stays powered on and paused during the night? So TvServer keeps streaming the whole night long?