On 4/2/06, Reinhard Nissl <rnissl@xxxxxx> 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@xxxxxx > > _______________________________________________ > vdr mailing list > vdr@xxxxxxxxxxx > 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
