On 4/2/06, <b class="gmail_sendername">Reinhard Nissl</b> <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br><br>Thomas Bergwinkl wrote:<br><br>>>>>> So, this is a matter of LiveBuffer patch. But I don't understand why<br>>> it<br>>>>>> was working when switching channels.<br>>>>>>
<br>>>>>> Anyway, to fix it properly, the following line in<br>>>>>> cXineDevice::SetPlayMode() most be adapted to LiveBuffer:<br>>>>>><br>>>>>> m_settings.SelectReplayPrebufferMode(!Transferring());
<br>>>>>><br>>>>>> For vanilla VDR, Transferring() reports the existence of a transfer<br>>>>>> thread which means, VDR sends Live TV to vdr-xine.<br>>>>>><br>>>>>> So, how could I detect Live TV in the case of a VDR with LiveBuffer
<br>>>>>> patch?<br>>>>>><br>>>>>> Is there a way to automatically detect that the LiveBuffer patch was<br>>>>>> applied to VDR?<br>>> >><br>>>>> In
config.h LIVEBUFFERVERSION is defined, when livebuffer has been<br>>> applied:<br>>>>> #define LIVEBUFFERVERSION 106<br>>>>><br>>>>> When the livebuffer is active (replaying)<br>>>>> cTransferControl::ReceiverDevice() returns the receiving device. So you
<br>>>>> could use this for detecting Live TV.<br>>>>><br>>>>> But I think it would be better to adapt the livebuffer patch so that<br>>>>> cDevice::Transferring() returns also true when a livebuffer recording
<br>>> is<br>>>>> played. (Or does something argue against it?)<br>>>> I try to force Live TV in vdr-xine for LiveBuffer to solve the problem.<br>>> View<br>>>> channels work ok. But when moving back or forward into the LiveBuffer
<br>>> don't<br>>>> work very well.<br> >><br>>> Hhm, it seems that it is not that easy to find a proper solution. Maybe<br>>> cDevice::Transferring() could be patched to return true when<br>
>> LiveBuffer's reader and writer are almost at the same position (delta ~<br>>> 8 frames) and to return false otherwise.<br>><br>> I don't know vdr-xine, so why is it neccessary to distinguish between LiveTV
<br>> and a recording. And why does fast forward / backward doesn't work correctly<br>> when you in LiveTV mode?<br>><br>> Patching cDevice::Transferring() the way you suggested shouldn't be much of<br>> a problem. But this behaviour doesn't seem to me very logical.
<br><br>xine wants to read data on demand which is possible for sources like<br>DVDs, files on disk and VDR recordings sent via vdr-xine.<br><br>But on demand access is not possible for LiveTV as the satellite<br>broadcasts at a constant data rate. Seeking forward to catch up with
<br>replaying will most likely result in a buffer underflow.<br><br>That's why I distinguish between LiveTV and recording and establish a<br>buffer in LiveTV mode, which allows little seeks and other on demand<br>burst accesses. The average input / output rate should typically be equal.
<br><br>The buffer is reestablished when VDR clears the device and that's why<br>moving forward / backward gets quite sluggish. Buffering is not<br>necessary in this case as VDR can honor all on demand requests.<br><br>Bye.
<br>--<br>Dipl.-Inform. (FH) Reinhard Nissl<br>mailto:<a href="mailto:firstname.lastname@example.org">email@example.com</a><br><br>_______________________________________________<br>vdr mailing list<br><a href="mailto:firstname.lastname@example.org">email@example.com
</a><br><a href="http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr">http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr</a><br></blockquote></div>HI, <br>
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.<br>
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.<br>
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.<br>
Any insight would be appreciated.<br>