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

[tourettes]

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.

Depends on from who you ask I personally wont even use multi seat (better to keep MP of the bed room ). But I know that removing such functionality wont be possible.

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?

Currently yes, I think the server will be running happily for the whole evening (many people have 24/7 servers in any case so it wont be that bad). But we shouldn't just think about the current state as arion said there are plans for the "handle TS buffer to other client" and in that case the pause / server left running over the night is not an issue anymore.

 

[arion_p]

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?

Nope, once the second client attaches to the stream, you can power down the first client and second client will assume ownership of the card and the timeshift buffer.

Regarding the value of this feature, you should ask Chris (i-loop). Personally I don't want to have to remember to delete the recording the next day. Plus if you start recording the time you decide to move to the bedroom, you loose the timeshift buffer corrected already.

 

[dvdfreak]

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?

Nope, once the second client attaches to the stream, you can power down the first client and second client will assume ownership of the card and the timeshift buffer.

Yes, but by that time you are e.g. upstairs in your bedroom. And have no easy access to the other client, so you have to go down the stairs again, power down that client, and then go back up to resume watching TV upstairs. A lot of hoopla compared to simply starting a recording

Anyway, it doesn't really matter. The point is simple: this is a rare use-case and you'll probably find as many people in favor of using this, or in favor of using the recording technique. Because both have pros and cons.

So in that respect: it this really important enough to discuss in this thread, with regards to this patch?

It's easy to over-engineer anything to death or reduce it to a complex piece of **** that sort of works if you're lucky...

 

[miroslav22]

Personally I think the ability to move to a different client is invaluable and I frequently use it. An example being match of the day on a saturday night when i'm usually shattered. I rarely make it all the way through without pausing and moving to the bedroom!

Again personally i'm not really in favour of losing the flexibility of being able to leave timeshifting paused for long durations. I know it sounds silly, but there's been times when i've had to go out unexpectedly or been on the phone for 100x longer than I expected to be! You don't always know in advance to push record. I could live with this but i'd rather not have to use a 30-40GB timeshifting file per tuner!

 

[tourettes]

So in that respect: it this really important enough to discuss in this thread, with regards to this patch?

Yes, I think it is since:

1) we don't want to have multiple different ways of timeshifting buffer handling (code complexity)
2) we don't want to reduce the current functionality (that is even used by the team members)

We want the patch to be as good as it can so it is able to replace the current implementation.

It's easy to over-engineer anything to death or reduce it to a complex piece of **** that sort of works if you're lucky...

Like adding the third way of buffering wouldn't fall into a case that causes the code complexity to grow? Off topic, but still worth to remind again how the maintenance work will increase (RTSP is party broken because of it is a different code branch - something that I haven't ever bothered to look at since I personally wont need it).

 

[dvdfreak]

Funny thing is, switching to a second client with paused live TV shouldn't actually be different between .tshift and .tsbuffer. So it's not that important to keep beating this to death

The biggest difference is that the file can't easily grow -- causing issues with pausing live TV for a very long time. I proposed a .lock file to at least improve this a bit, but since more than one client could access the file, I guess having more than one .lock file must be supported then.

 

[miroslav22]

I've no problem with what your suggesting, I just think it sounds quite difficult to implement (and especially debug!)

 

[disaster123]

AW: Timeshifting in a single looping .ts file

Wouldn't it make sense to reduce MPs timeshifting / livetv functionality to one way? I mean everybody uses RTSP or everybody uses UNC (regardless of tshift or tsbuffer)? Atm there are bugs here and there. And the baddest thing at all: BOTH ways are not working 100%fine - except you're using single seat but isn't MP meant to be multi client thing?

 

[riksmith]

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

Wouldn't it make sense to reduce MPs timeshifting / livetv functionality to one way? I mean everybody uses RTSP or everybody uses UNC (regardless of tshift or tsbuffer)? Atm there are bugs here and there. And the baddest thing at all: BOTH ways are not working 100%fine - except you're using single seat but isn't MP meant to be multi client thing?

Yes that seems logic to me. I have no clear idea what the problems with RTSP are. Can we start a separate collection thread for that?

 

[arion_p]

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