Am 2012-03-02 00:18, schrieb Tony Houghton:
Going off on a tangent, there's been some discussion about "Pause and rewind live TV". That could be implemented fairly easily in clients with a big RAM buffer, without adding any complexity to the server.
Big RAM buffer means long breaks between channel changes.
Gerald
about "Pause and rewind live TV".
What is live TV there, as it is already recorded ... ?
Only users which didn't got into VDR and epgsearch timers do call for this live buffer function. They hope for a kind of security, which this function doesn't really provide.
You want to have a feeling how it feels, if a live buffer is the underlying central function in a PVR solution, just go and test MythTV.
Cheers fnu
On Fri, 2 Mar 2012 10:30:37 +0100 "fnu" vdr@auktion.hostingkunde.de wrote:
about "Pause and rewind live TV".
What is live TV there, as it is already recorded ... ?
Only users which didn't got into VDR and epgsearch timers do call for this live buffer function. They hope for a kind of security, which this function doesn't really provide.
I disagree, my sister's got a Humax which can pause and rewind, it's really useful. She's even willing to have inferior picture quality (older MPEG decoder, analogue SCART etc vs modern TV's inbuilt decoder) just to be able to pause and rewind.
VDR can already pause, but what if there's a sudden distraction and you miss something before you can press the pause button? Then rewind is very nice.
You want to have a feeling how it feels, if a live buffer is the underlying central function in a PVR solution, just go and test MythTV.
Do you mean because of slow channel switching? A buffer doesn't have to cause that, see my other post.
Am 02.03.2012 10:30, schrieb fnu:
You want to have a feeling how it feels, if a live buffer is the underlying central function in a PVR solution, just go and test MythTV.
I think the main objection against buffering was that for old FF cards, this also forces transfer mode, resulting in additional lag and bandwidth issues. Since HDFF cards AFAIK can split their stream on card for live view and recording, this isn't valid any more.
Live viewing could be just like its currently, with an additional (RAM?) recording running in the background, and VDR could jump to that recording on rewind/pause key hit.
Cheers,
Udo
On Fri, 02 Mar 2012 08:29:00 +0100 Gerald Dachs vdr@dachsweb.de wrote:
Am 2012-03-02 00:18, schrieb Tony Houghton:
Going off on a tangent, there's been some discussion about "Pause and rewind live TV". That could be implemented fairly easily in clients with a big RAM buffer, without adding any complexity to the server.
Big RAM buffer means long breaks between channel changes.
Not necessarily, because you don't have to wait for the buffer to fill before playing the content. I meant to play the stream as soon as possible, but also keep the data in a buffer for a short time so the viewer can rewind. It wouldn't need to be for long, not even more than a minute, because what I had in mind is when you miss what someone said and rewind to hear it again.
However, if the user pauses instead the buffer should be able to grow as necessary. That gets complicated if the pause ends up being longer than the available RAM. Possible strategies are:
Drop the buffer (LIFO or FIFO?) and miss some of the programme. Not good.
Allow the client to write the buffer to disc. Partly duplicates server functionality but I think it's probably the best plan.
Signal the server to start recording. But then the client has to be able to match up its buffer with what the server has recorded after the buffer filled and let the server know when the temp recording is no longer needed. Complicated.
Have the server record everything it plays and not bother with buffering in the client. I don't think most people want VDR to work that way because of extra load on the hard drive.
On Fri, Mar 2, 2012 at 4:13 AM, Tony Houghton h@realh.co.uk wrote:
Signal the server to start recording. But then the client has to be able to match up its buffer with what the server has recorded after the buffer filled and let the server know when the temp recording is no longer needed. Complicated.
Maybe something like this would work...
User can define how much of his ram he wants used for buffering. VDR uses x% of this for constant buffering. The remainder is only used when pause/rewind has been pressed. When the remainder is filled, the entire buffer is dumped to disk as a temp recording, which continued to be recorded until a) live view has been resumed for X secs, or b) until the show ends. The temp recording is then purged after a user defined X minutes (or never if 0) of it's last modified timestamp.
If live buffering is to be added, it should have some flexibility, but it still doesn't need to be overly complicated. Whatever the actual live buffer behavior, I believe a ram-based solution is the best choice for a number of reasons.
Have the server record everything it plays and not bother with buffering in the client. I don't think most people want VDR to work that way because of extra load on the hard drive.
HELL NO! I will not use software that forces my harddrive(s) into a constant write state 24/7. I don't want the extra wear. I don't want the extra heat. I don't want the extra power consumption. And I'm certainly not alone.
On 3/2/2012 11:06 AM, VDR User wrote:
On Fri, Mar 2, 2012 at 4:13 AM, Tony Houghtonh@realh.co.uk wrote:
Signal the server to start recording. But then the client has to be able to match up its buffer with what the server has recorded after the buffer filled and let the server know when the temp recording is no longer needed. Complicated.
Maybe something like this would work...
User can define how much of his ram he wants used for buffering. VDR uses x% of this for constant buffering. The remainder is only used when pause/rewind has been pressed. When the remainder is filled, the entire buffer is dumped to disk as a temp recording, which continued to be recorded until a) live view has been resumed for X secs, or b) until the show ends. The temp recording is then purged after a user defined X minutes (or never if 0) of it's last modified timestamp.
If live buffering is to be added, it should have some flexibility, but it still doesn't need to be overly complicated. Whatever the actual live buffer behavior, I believe a ram-based solution is the best choice for a number of reasons.
Have the server record everything it plays and not bother with buffering in the client. I don't think most people want VDR to work that way because of extra load on the hard drive.
HELL NO! I will not use software that forces my harddrive(s) into a constant write state 24/7. I don't want the extra wear. I don't want the extra heat. I don't want the extra power consumption. And I'm certainly not alone.
I agree, this is what MythTV does and why I never tried to fully install it. I started to once to try it out, but I just didn't like the need for continous recording. Would be ok with sold state drives that don't ware out with use like the current ones do. But even they are too costly for me to even look at.
-
fnu -
Gerald Dachs -
Timothy D. Lenz -
Tony Houghton -
Udo Richter -
VDR User