On 4/2/06, Reinhard Nissl <rnissl at gmx.de> wrote:
>> Hi,
>> Thomas Bergwinkl wrote:
>> >>>>> So, this is a matter of LiveBuffer patch. But I don't understand why
> >> it
> >>>>> was working when switching channels.
> >>>>>
> >>>>> Anyway, to fix it properly, the following line in
> >>>>> cXineDevice::SetPlayMode() most be adapted to LiveBuffer:
> >>>>>
> >>>>> m_settings.SelectReplayPrebufferMode(!Transferring());
> >>>>>
> >>>>> For vanilla VDR, Transferring() reports the existence of a transfer
> >>>>> thread which means, VDR sends Live TV to vdr-xine.
> >>>>>
> >>>>> So, how could I detect Live TV in the case of a VDR with LiveBuffer
> >>>>> patch?
> >>>>>
> >>>>> Is there a way to automatically detect that the LiveBuffer patch was
> >>>>> applied to VDR?
> >> >>
> >>>> In config.h LIVEBUFFERVERSION is defined, when livebuffer has been
> >> applied:
> >>>> #define LIVEBUFFERVERSION 106
> >>>>
> >>>> When the livebuffer is active (replaying)
> >>>> cTransferControl::ReceiverDevice() returns the receiving device. So
> you
> >>>> could use this for detecting Live TV.
> >>>>
> >>>> But I think it would be better to adapt the livebuffer patch so that
> >>>> cDevice::Transferring() returns also true when a livebuffer recording
> >> is
> >>>> played. (Or does something argue against it?)
> >>> I try to force Live TV in vdr-xine for LiveBuffer to solve the
> problem.
> >> View
> >>> channels work ok. But when moving back or forward into the LiveBuffer
> >> don't
> >>> work very well.
> >>
> >> Hhm, it seems that it is not that easy to find a proper solution. Maybe
> >> cDevice::Transferring() could be patched to return true when
> >> LiveBuffer's reader and writer are almost at the same position (delta ~
> >> 8 frames) and to return false otherwise.
> >
> > I don't know vdr-xine, so why is it neccessary to distinguish between
> LiveTV
> > and a recording. And why does fast forward / backward doesn't work
> correctly
> > when you in LiveTV mode?
> >
> > Patching cDevice::Transferring() the way you suggested shouldn't be much
> of
> > a problem. But this behaviour doesn't seem to me very logical.
>> xine wants to read data on demand which is possible for sources like
> DVDs, files on disk and VDR recordings sent via vdr-xine.
>> But on demand access is not possible for LiveTV as the satellite
> broadcasts at a constant data rate. Seeking forward to catch up with
> replaying will most likely result in a buffer underflow.
>> That's why I distinguish between LiveTV and recording and establish a
> buffer in LiveTV mode, which allows little seeks and other on demand
> burst accesses. The average input / output rate should typically be equal.
>> The buffer is reestablished when VDR clears the device and that's why
> moving forward / backward gets quite sluggish. Buffering is not
> necessary in this case as VDR can honor all on demand requests.
>> Bye.
> --
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:rnissl at gmx.de>> _______________________________________________
> vdr mailing list
>vdr at linuxtv.org>http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>HI,
I was wondering if there had been anything done with this to date.The thread
here just kind of ends with a defined problem and no solution.
I have channel changes working correctly with buffer size manipulations but
the initial start of xine is a slideshow until pause is initiated and
released to create an additional buffer. Increasing the buffers in setup
does not seem to make a difference on the initial startup. It appears that
there is a difference in the way the buffer is handled on startup as opposed
to a channel change.
I have been working with both Vdr-1.3.44 and vdr-1.3.47 with the xine
plugins v0.7.8 and v.0.7.9. The problem exists in either combination.
Livebuffer is 0.1.7 included with the bigpatch.
Any insight would be appreciated.
Kurt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxtv.org/pipermail/vdr/attachments/20060424/b9c96706/attachment.htm