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:
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.
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ó:
Hi,
Jose Alberto Reguero wrote:
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.
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?
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
Hi,
Jose Alberto Reguero wrote:
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.
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?
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, that's valuable output!
Do you use a FF card?
I have only budget cards and don't see this issue.
Bye.
El Miércoles, 29 de Marzo de 2006 22:38, Reinhard Nissl escribió:
Hi,
Jose Alberto Reguero wrote:
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.
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?
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, that's valuable output!
Do you use a FF card?
I have only budget cards and don't see this issue.
Bye.
I don't have a FF card. Only DVB-T budget cards. Thaks.
Jose Alberto
Hi,
Jose Alberto Reguero wrote:
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.
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?
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, that's valuable output!
Do you use a FF card?
I have only budget cards and don't see this issue.
I don't have a FF card. Only DVB-T budget cards.
Which VDR version are you using?
I'm using 1.3.44.
Bye.
El Sábado, 1 de Abril de 2006 10:13, Reinhard Nissl escribió:
Hi,
Jose Alberto Reguero wrote:
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.
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?
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, that's valuable output!
Do you use a FF card?
I have only budget cards and don't see this issue.
I don't have a FF card. Only DVB-T budget cards.
Which VDR version are you using?
I'm using 1.3.44.
Bye.
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:
> 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.
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?
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, that's valuable output!
Do you use a FF card?
I have only budget cards and don't see this issue.
I don't have a FF card. Only DVB-T budget cards.
Which VDR version are you using?
I'm using 1.3.44.
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();
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:
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?)
Greetings Thomas
El Sábado, 1 de Abril de 2006 23:01, Thomas Bergwinkl escribió:
Hello,
Reinhard Nissl 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?)
Greetings Thomas
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.
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?
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.
Bye.
Reinhard Nissl wrote:
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?
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.
Thomas
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.
On 4/2/06, Reinhard Nissl rnissl@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@gmx.de
vdr mailing list vdr@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
El Sábado, 1 de Abril de 2006 21:49, Reinhard Nissl escribió:
Hi,
Jose Alberto Reguero wrote:
>> 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. > > 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?
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, that's valuable output!
Do you use a FF card?
I have only budget cards and don't see this issue.
I don't have a FF card. Only DVB-T budget cards.
Which VDR version are you using?
I'm using 1.3.44.
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();
So, this is a matter of LiveBuffer patch. But I don't understand why it was working when switching channels.
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
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.
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.
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
I see.
Bye.