2011-03-18 15:52:42 +01:00
|
|
|
|
# VDR streamdev plugin language source file.
|
|
|
|
|
|
# Copyright (C) 2008 streamdev development team. See http://streamdev.vdr-developer.org
|
|
|
|
|
|
# This file is distributed under the same license as the VDR streamdev package.
|
|
|
|
|
|
# Javier Bradineras <jbradi@hotmail.com>, 2011
|
|
|
|
|
|
#
|
|
|
|
|
|
msgid ""
|
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
"Project-Id-Version: streamdev 0.5.0\n"
|
Fixed problems related to VTP filter streaming like ringbuffer overflows,
stuttering or aborting video stream (refs #2045)
Toerless Eckert wrote:
This patch tries to resolve problems in streamdev-client that
can occur when enabling "StreamFilters". Enabling this option
is necessary to receive certain programs with dynamic PIDs such as
some german "regional" broadcast (eg: NDR).
Problem:
Without this fix, the following behavior was observed on a Raspberry
PI running streamdev-0.6.1-git with VDR-2.6.1:
- Buffer overflows of filter data
- Stop/go video on channels
- Total stopping of video
More logs in:
http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/125237-
streamdev-client-filter-daten-streamen-ndr-raspberry-haengt/
Analysis:
VDR expect section data from filters separately from the
main program stream. Historically, it received each filter data
via a separate file descriptor from the DVB card. In the streamdev-client
module, a socketpair is used to feed filter data to the main VDR code.
During certain operations in VDR, such as startup or channel change
(depending also on the speed of initialization of the video output driver),
VDR does not consume the filter data as fast as it is provided by
streamdev-client, resulting in overflow of the default socket buffers
used by streamdev-client.
To add to the problem of overflowing the socketpair buffers, the
streamdev-client code sends several times a second short packets into
the socketpair to determine if the receiving side (VDR) has closed
the socketpair (IsClosed(), CarbageCollect()). This further clogs
up the socketpair() buffer.
The raspberry PI socketpair buffering behavior seems to be the same
as that of other 3.x linux systems, the socket buffer size is by
default 163840, and it can be increased via sysctl net.core.wmem_max.
During startup, it can take up to 10 seconds before VDR will consume
filter data, so the socketpair buffer can fill up with 10 seconds worth
of data.
Solution
1. IsClosed()/CarbageCollect() where removed from client/filter.c
and replaced by explicitly tracking when VDR closes a filter socket.
This alone seems to already resolve the problem of hanging or stop&go
video and seems to be sufficient to receive dynamic-PID channels reliably.
2. filter.c was enhanced to request a larger socket buffer size
if config option FilterSockBufSize is set.
3. If supported (if streamdev-client runs on linux), the socketpair
queue is "flushed" to reduce the amount of "random" packet drop messages
and to rather drop sequential messages.
2015-01-24 00:19:04 +01:00
|
|
|
|
"Report-Msgid-Bugs-To: <vdrdev@schmirler.de>\n"
|
|
|
|
|
|
"POT-Creation-Date: 2015-01-16 22:32+0100\n"
|
2011-03-18 15:52:42 +01:00
|
|
|
|
"PO-Revision-Date: 2010-06-19 03:58+0100\n"
|
|
|
|
|
|
"Last-Translator: Javier Bradineras <jbradi@hotmail.com>\n"
|
2011-12-13 12:59:31 +01:00
|
|
|
|
"Language-Team: Spanish <vdr@linuxtv.org>\n"
|
|
|
|
|
|
"Language: es\n"
|
2011-03-18 15:52:42 +01:00
|
|
|
|
"MIME-Version: 1.0\n"
|
|
|
|
|
|
"Content-Type: text/plain; charset=ISO-8859-15\n"
|
|
|
|
|
|
"Content-Transfer-Encoding: 8bit\n"
|
|
|
|
|
|
|
|
|
|
|
|
msgid "Hide Mainmenu Entry"
|
|
|
|
|
|
msgstr "Ocultar entrada en men<65> principal"
|
|
|
|
|
|
|
2013-01-29 00:02:17 +01:00
|
|
|
|
msgid "Simultaneously used Devices"
|
|
|
|
|
|
msgstr ""
|
2011-03-18 15:52:42 +01:00
|
|
|
|
|
|
|
|
|
|
msgid "Remote IP"
|
|
|
|
|
|
msgstr "Indicar IP del Servidor"
|
|
|
|
|
|
|
|
|
|
|
|
msgid "Remote Port"
|
|
|
|
|
|
msgstr "Indicar puerto remoto del Servidor"
|
|
|
|
|
|
|
2012-03-03 23:24:30 +01:00
|
|
|
|
msgid "Timeout (s)"
|
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
|
2011-03-18 15:52:42 +01:00
|
|
|
|
msgid "Filter Streaming"
|
|
|
|
|
|
msgstr "Filtrar transmisi<73>n"
|
|
|
|
|
|
|
Fixed problems related to VTP filter streaming like ringbuffer overflows,
stuttering or aborting video stream (refs #2045)
Toerless Eckert wrote:
This patch tries to resolve problems in streamdev-client that
can occur when enabling "StreamFilters". Enabling this option
is necessary to receive certain programs with dynamic PIDs such as
some german "regional" broadcast (eg: NDR).
Problem:
Without this fix, the following behavior was observed on a Raspberry
PI running streamdev-0.6.1-git with VDR-2.6.1:
- Buffer overflows of filter data
- Stop/go video on channels
- Total stopping of video
More logs in:
http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/125237-
streamdev-client-filter-daten-streamen-ndr-raspberry-haengt/
Analysis:
VDR expect section data from filters separately from the
main program stream. Historically, it received each filter data
via a separate file descriptor from the DVB card. In the streamdev-client
module, a socketpair is used to feed filter data to the main VDR code.
During certain operations in VDR, such as startup or channel change
(depending also on the speed of initialization of the video output driver),
VDR does not consume the filter data as fast as it is provided by
streamdev-client, resulting in overflow of the default socket buffers
used by streamdev-client.
To add to the problem of overflowing the socketpair buffers, the
streamdev-client code sends several times a second short packets into
the socketpair to determine if the receiving side (VDR) has closed
the socketpair (IsClosed(), CarbageCollect()). This further clogs
up the socketpair() buffer.
The raspberry PI socketpair buffering behavior seems to be the same
as that of other 3.x linux systems, the socket buffer size is by
default 163840, and it can be increased via sysctl net.core.wmem_max.
During startup, it can take up to 10 seconds before VDR will consume
filter data, so the socketpair buffer can fill up with 10 seconds worth
of data.
Solution
1. IsClosed()/CarbageCollect() where removed from client/filter.c
and replaced by explicitly tracking when VDR closes a filter socket.
This alone seems to already resolve the problem of hanging or stop&go
video and seems to be sufficient to receive dynamic-PID channels reliably.
2. filter.c was enhanced to request a larger socket buffer size
if config option FilterSockBufSize is set.
3. If supported (if streamdev-client runs on linux), the socketpair
queue is "flushed" to reduce the amount of "random" packet drop messages
and to rather drop sequential messages.
2015-01-24 00:19:04 +01:00
|
|
|
|
msgid "Filter SockBufSize"
|
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
|
2012-03-04 01:15:40 +01:00
|
|
|
|
msgid "Live TV Priority"
|
|
|
|
|
|
msgstr ""
|
|
|
|
|
|
|
2011-03-18 15:52:42 +01:00
|
|
|
|
msgid "Minimum Priority"
|
|
|
|
|
|
msgstr "Prioridad m<>nima"
|
|
|
|
|
|
|
|
|
|
|
|
msgid "Maximum Priority"
|
|
|
|
|
|
msgstr "Prioridad m<>xima"
|
|
|
|
|
|
|
2011-12-11 11:35:12 +01:00
|
|
|
|
msgid "Broadcast Systems / Cost"
|
|
|
|
|
|
msgstr ""
|
Fixed problems related to VTP filter streaming like ringbuffer overflows,
stuttering or aborting video stream (refs #2045)
Toerless Eckert wrote:
This patch tries to resolve problems in streamdev-client that
can occur when enabling "StreamFilters". Enabling this option
is necessary to receive certain programs with dynamic PIDs such as
some german "regional" broadcast (eg: NDR).
Problem:
Without this fix, the following behavior was observed on a Raspberry
PI running streamdev-0.6.1-git with VDR-2.6.1:
- Buffer overflows of filter data
- Stop/go video on channels
- Total stopping of video
More logs in:
http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/125237-
streamdev-client-filter-daten-streamen-ndr-raspberry-haengt/
Analysis:
VDR expect section data from filters separately from the
main program stream. Historically, it received each filter data
via a separate file descriptor from the DVB card. In the streamdev-client
module, a socketpair is used to feed filter data to the main VDR code.
During certain operations in VDR, such as startup or channel change
(depending also on the speed of initialization of the video output driver),
VDR does not consume the filter data as fast as it is provided by
streamdev-client, resulting in overflow of the default socket buffers
used by streamdev-client.
To add to the problem of overflowing the socketpair buffers, the
streamdev-client code sends several times a second short packets into
the socketpair to determine if the receiving side (VDR) has closed
the socketpair (IsClosed(), CarbageCollect()). This further clogs
up the socketpair() buffer.
The raspberry PI socketpair buffering behavior seems to be the same
as that of other 3.x linux systems, the socket buffer size is by
default 163840, and it can be increased via sysctl net.core.wmem_max.
During startup, it can take up to 10 seconds before VDR will consume
filter data, so the socketpair buffer can fill up with 10 seconds worth
of data.
Solution
1. IsClosed()/CarbageCollect() where removed from client/filter.c
and replaced by explicitly tracking when VDR closes a filter socket.
This alone seems to already resolve the problem of hanging or stop&go
video and seems to be sufficient to receive dynamic-PID channels reliably.
2. filter.c was enhanced to request a larger socket buffer size
if config option FilterSockBufSize is set.
3. If supported (if streamdev-client runs on linux), the socketpair
queue is "flushed" to reduce the amount of "random" packet drop messages
and to rather drop sequential messages.
2015-01-24 00:19:04 +01:00
|
|
|
|
|
|
|
|
|
|
msgid "VTP Streaming Client"
|
|
|
|
|
|
msgstr "Cliente trasmisi<73>n VTP"
|
|
|
|
|
|
|
|
|
|
|
|
msgid "Suspend Server"
|
|
|
|
|
|
msgstr "Suspender servidor"
|
|
|
|
|
|
|
|
|
|
|
|
msgid "Server is suspended"
|
|
|
|
|
|
msgstr "Servidor en suspensi<73>n"
|
|
|
|
|
|
|
|
|
|
|
|
msgid "Couldn't suspend Server!"
|
|
|
|
|
|
msgstr "Imposible suspender el servidor!"
|