Is there a way to wait until having data ready when starting xine? (vdr-xine is not in mode LiveTV with LiveBuffer). The replay is a slide show without sound. If pause and resume xine the problem is gone. Its only trouble when starting xine. Changing the channel solves the problem with Frameswait(LiveBuffer )= 8. With Frameswait(LiveBuffer) = 0 when changing the chanel, or starting xine the replay is a slide show without sound.
Jose Alberto
Hi,
Jose Alberto Reguero wrote:
Hhm, the buffer, which is established when switching the channel, is also established when xine connects to vdr-xine. This is the output of my system:
vdr-xine: Client connecting ... frame: (0, 0)-(720, 576), zoom: (1.00, 1.00) vdr-xine: Client connected! [avAVMM]buffered 8.7 frames (v:13.7, a:8.7)
What's your output? Does it help to increase the buffer size?
Bye.
El Martes, 28 de Marzo de 2006 23:10, Reinhard Nissl escribió:
I change in SetPlayMode:
if (m_settings.LiveTV()) { ::fprintf(stderr, "LiveTV\n"); softStartTrigger = sstNormal; } else { np = true; ::fprintf(stderr, "No LiveTV\n"); }
and my output is:
............ SetAudioChannelDevice: 0 SetVolumeDevice: 0 status: volume=0 mute=1 frame: (0, 0)-(-1, -1), zoom: (1,00, 1,00) SetAudioChannelDevice: 0 SetPlayMode: 1 No LiveTV SetDigitalAudioDevice: 0 SetAudioChannelDevice: 0 vdr-xine: Client connected! read(4) returned 0, error 0: Conseguido vdr-xine: Client disconnected!
I increase the buffer size to the maximun and don't help.
Thanks. Jose Alberto
El Sábado, 1 de Abril de 2006 10:13, Reinhard Nissl escribió:
I am using vdr 1.3.45, vdr-xine 0.7.8 and LiveBuffer 0.1.7 but I have the same problem with vdr 1.3.44. I also try vdr-xine with and without network. I find a solution putting in xineDevice.c cXineDevice::OnClientConnect
cLiveRecorderControl::GetLiveRecorder()->Resume();
Thanks.
Jose Alberto
Hi,
Jose Alberto Reguero 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?
Bye.
Hello,
Reinhard Nissl wrote:
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?)
Greetings Thomas
Hi,
Jose Alberto Reguero wrote:
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.
Bye.
Reinhard Nissl wrote:
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.
Thomas
Hi,
Thomas Bergwinkl wrote:
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.
On 4/2/06, Reinhard Nissl rnissl@gmx.de wrote:
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
El Sábado, 1 de Abril de 2006 21:49, Reinhard Nissl escribió:
It only work for me switching channels with setup option Frameswait(LiveBuffer )= 8
From the README.LiveBuffer Frameswait: The number of frames, which have to be received, until the replay of the livebuffer starts Jose Alberto
-
Jose Alberto Reguero -
Reinhard Nissl -
Stile -
Thomas Bergwinkl