On 28.01.2009 10:32, alex bustamante wrote:
warning: `vdr' uses 32-bit capabilities (legacy support in use)
What is this exactly?
Your vdr is compiled against libcap version 1, while your kernel already
supports a newer version of capability handling, provided by libcap
version 2. Compiling
On 26.01.2009 08:39, Klaus Schmidinger wrote:
On 25.01.2009 23:53, Udo Richter wrote:
Attached is a new version of cDevice::PlayTsVideo and
cDevice::PlayTsAudio that properly handles partially accepted buffers of
the PlayVideo and PlayAudio functions. The original functions would
discard any
On 26.01.2009 12:10, Udo Richter wrote:
On 26.01.2009 08:39, Klaus Schmidinger wrote:
On 25.01.2009 23:53, Udo Richter wrote:
Attached is a new version of cDevice::PlayTsVideo and
cDevice::PlayTsAudio that properly handles partially accepted buffers of
the PlayVideo and PlayAudio functions
On 26.01.2009 22:25, Deti Fliegl wrote:
sometimes it is very useful to create and destroy cDevice based classes
at runtime. Currently it is only possible to create such classes at any
time but destroying causes inconsistency in the 'devices' array which
leads to segmentation faults in various
Hi list,
Attached is a new version of cDevice::PlayTsVideo and
cDevice::PlayTsAudio that properly handles partially accepted buffers of
the PlayVideo and PlayAudio functions. The original functions would
discard any partially written data.
These two functions are only used by devices that
Hi list,
The new S2API-Wrapper patch for VDR-1.7.4 is ready. Beside adding
support for the final 2G-flag, the patch also reverts the change that
sends TS data directly to the device, since TS playback support is even
newer than S2API support.
Since TS to PES conversion by VDR-1.7.4 is also
Hi list,
A first experimental version of the hard link cutter patch is available
for VDR-1.7.4.
The new version handles 1TB file sizes for TS recordings, properly
calculates the switch-to-large-files for 65535 files, and also handles
PES recordings properly with the old limits.
For TS
Hi list,
The Cuttime-patch modifies the recording time of edited recordings to
match the time of the first cut mark of the original recording. So if
you start a recording 5 minutes earlier, and then later cut off the
first 5 minutes, the resulting recording will have the proper start time
On 06.01.2009 16:06, Klaus Schmidinger wrote:
- Recording files larger than 4GB or with more than 255 separate
files hasn't been tested yet.
+ The index file format has been changed to support file sizes of up to 1TB
(previously 2GB), and up to 65535 separate files per recording
On 21.01.2009 19:33, Gerald Dachs wrote:
Assumed I have 2 free Tuners and I zapp through the channels of one
tuner. Would it be possible to tune the 2. tuner to the same time to
the after next channel in change direction, so that for the next
channel change in the same direction it would be
On 14.01.2009 02:48, LinHai wrote:
when I start the VDR-PC,The Screen displays:
/usr/bin/runvdr:line 576: 4515 Segmentation fault
Line 576 is in my latest patched runvdr extreme 0.4.0 release the line
in which the actual VDR process is launched, at least if you're using
the
On 11.01.2009 18:05, Joachim Wilke wrote:
2009/1/11 Lauri Tischlerl...@iki.fi:
Plse dont change it, now when searching for 'plugin' something sometimes
comes up also from german sources, if the term is changed to 'erweiterung'
all german sources will become essentially black holes.
If this
On 10.01.2009 21:58, Johann Friedrichs wrote:
there seems to be problem in pausing replays of new recordings (output
to FF). 4 out of 5 times vdr freezes when trying to continue the replay.
Poll in PlayVideo runs into a timeout and a new write gives EAGAIN. This
does not happen with old
On 11.01.2009 20:44, JJussi wrote:
Related question.. Is it possible to change order of those colors (what
represent color-keys) at screen?
Because my remote have those colors, but two of those are in different
order...
Would be a Skin-related issue. Skins get the key description by color
Hi list,
I've released the successor of the Multiproto dvb api wrapper patch. As
its predecessor, the patch allows VDR-1.7.2 to be run on kernels without
S2API support by wrapping S2API calls to old API calls.
Behavior can be configured in Make.config again:
DEFINES += -DDVB_S2API_RUNTIME=1
On 01.12.2008 16:02, Jörn Reder wrote:
Jörn Reder wrote:
With vdr 1.4 this worked perfectly, now with 1.6 VDR always prefers my
Budget CI card for recordings so I can't view any Pay TV when a
recording is active.
The rules that were added with 1.4.1-4 are still present, so they
probably got
On 15.12.2008 11:06, Frank Schmirler wrote:
- no channel sync
This would make an excellent addition to streamdev.
Rather a separate plugin or at most part of epgsync-Plugin. Streamdev should
stick to what it was meant for: streaming.
Streamdev is a receiving device within VDR, and VDR can do
On 15.12.2008 11:46, Nicolas Huillard wrote:
The problem is that xineliboutput seems to use a single
~/.xine/config_xineliboutput config file, stored in the home directory
of the vdr user, which is defined by /etc/passwd, which is the same on
all clients...
You could mount different locations
On 20.12.2008 23:37, Frank Schmirler wrote:
It seems that we have a different understanding of the term channel sync.
Streamdev-0.3.4 has the capabilities you're talking about. What I had in mind
was merging or replacing the client's with the server's channels list.
One thing is updating the
On 12.12.2008 23:23, Nicolas Huillard wrote:
The problems that come to mind in typical current multiple VDR are :
* DVB device handling is running even if there is no actual DVB device
(OK, this is not a problem in practice, except for device numbers)
When there are no DVB devices available at
On 13.12.2008 00:04, VDR User wrote:
Maybe those people who wants such a networking capable vdr should fork it and
implement the needed features?
Possibly. However, I could be wrong but didn't Klaus recently say if
anyone forks VDR, he would stop developing it? And it isn't as if
there's a
On 12.12.2008 18:06, VDR User wrote:
I can say I've seen many people move away from VDR because it doesn't
provide a good solution to this. After years of using standalone VDR
boxes, I too would love if we had the option to use a networked VDR
with each client being exactly as you
Karl Glatz wrote:
But the disadvantages are clear: Modern GPUs support more than the OSD
provided by VDR (even older gpus do that).
So none of these Output-Plugins will face the real problem: The OSD is
(mostly) limited to work with FF cards.
[...]
Even if you don't like such
Klaus Schmidinger wrote:
Is there any movement to files 2GB for the recordings?
I will most likely change this when going to TS recording format.
In doing so, I'd like to get rid of splitting recordings into separate
files altogether. However, I think there might be people who still
want
Jörn Reder wrote:
With vdr 1.4 this worked perfectly, now with 1.6 VDR always prefers my
Budget CI card for recordings so I can't view any Pay TV when a
recording is active.
The rules that were added with 1.4.1-4 are still present, so they
probably got over-ruled by something else.
Can you
Simon Baxter wrote:
Can anyone suggest a howto, or can guide me on how to circumvent this
entirely? Basically I need to:
1) auto log into 'vdruser'
2) start xine
This sounds familiar, and leads to the question: Do your *really* need a
window manager? Or do you just run xine fullscreen
Klaus Schmidinger wrote:
Well, I like the idea of taking the plain VDR and a FF DVB card
and have it run out of the box, without having to fiddle around
with any plugins ;-)
This is not really a good point any more, since at least latest
development 1.7.x builds wont work without a custom
Pasi Juppo wrote:
Would this approach allow easier implementation of a real client-server
solution for VDR or would VDR still need severe changes in order to
allow this?
Has not much to do with this. The limitation for a client-server
solution is that VDR has exact ONE display front end, ONE
Artem Makhutov wrote:
do you know an solution to make VDR (maybe with the use of the
sreamdev-plugin) to stream using multicast?
I have an IPTV Settop Box, which I would like to use for wathing TV, but
it only works with IP-Multicast...
The xineliboutput plugin connects its remote clients
Hi,
I've published version 0.1.2 of the OSDServer plugin.
The new version fixes a bug on VDR 1.5.11+ on text edit items.
The new version also adds a new Perl binding module that encapsulates
the OSDServer network protocol within Perl objects. By using the Perl
module, OSDServer is a lot
Niels Wagenaar wrote:
So, this should mean that VDR 1.7.x should focus on S2API because of
the obvious reasons. Has anybody started on a patch of somekind to
include S2API in VDR 1.7.0 or 1.7.1? Mainly I was thinking of doing
it myself (I have a Hauppauge WinTV-NOVA-HD-S2 which is allready
Petri Helin wrote:
In fact I am already wondering why plugins are not
hot-pluggable...
They are, to some degree, by using the proxy plugin. The proxy plugin
can delay loading a plugin, and for some plugins it can unload a plugin
while VDR is running. It can also do the requested
Hi list,
I've updated the runvdr extreme script to version 0.4.
The main new feature is the ability to launch an X server together with
VDR, for use with xine or xineliboutput. An installed login manager like
gdm/kdm/wdm/xdm wont be used, and can be used for a desktop login on a
different
Klaus Schmidinger wrote:
On 09/07/08 19:42, Clemens Kirchgatterer wrote:
...
i always wondered why dvb support was directly compiled in while other
back and frontends were supposed to be plugins. this clearly leaves a
sign that dvb is the preferd plattform.
Well, it was the first one -
The sky plugin does not compile any more, because it uses PID_MASK_HI
which got renamed to TS_PID_MASK_HI. Patch is attached. A similar
problem strikes for streamdev.
Cheers,
Udo
--- vdr-1.7.1-old/PLUGINS/src/sky/sky.c 2008-09-07 13:34:53.0 +0200
+++ vdr-1.7.1/PLUGINS/src/sky/sky.c
Hi list,
A minimal update to the DVB API wrapper for VDR 1.7.1 is available on my
web site.
http://www.udo-richter.de/vdr/patches.en.html#dvb-api-wrapper
http://www.udo-richter.de/vdr/patches.html#dvb-api-wrapper
Cheers,
Udo
___
vdr mailing list
VDR User wrote:
What ever happened to the idea of setting up VDR deveopment on
mercurial to allow the main contributors who want to work on it to do
so without hassle/delay?
My 2c on this:
Lets think this through: An open VDR repository for everyone to get in
their personal 'I want this'
Jelle De Loecker wrote:
I was wondering what the people on the VDR ml thought about this.
From a non-dvb-insider perspective who doesn't really need things like
s2 right now, I'm seeing this form a relaxed point of view.
The two APIs seem to do things different, but in the end they both offer
Hans Werner wrote:
Sourcecaps I believe has existed as a patch for about four *years* and
has it's own web page. Absolutely ridiculous. I am lost for words.
So I guess mythtv has something like that, right?
Also, I've never heard of anyone doing a more general patch that also
integrates
Morfsta wrote:
VDR does need some of its core functionality upgraded - for example
something like the Reel channel scan is badly missing, you should be
able to easily scan for transponders from within VDR, just like most
satellite receivers.
Hmmm. My VDR automatically updates its channel
Klaus Schmidinger wrote:
On 09/04/08 12:38, Morfsta wrote:
Does anyone know what is happening with VDR development these days?
There doesn't seem to be much activity - is Klaus taking a long
holiday or very busy with work!? :-)
This summer I had quite a few other things to do, and many
LinHai wrote:
when I run the vdr-1.7.0+h.264,there is something wrong with it.
syslog:
Aug 7 02:09:05 hdtv2 vdr: [10938] ERROR (svdrp.c,84): Address already
in use
VDR wants to open its port for SVDRP connections (default port 2001),
but someone else (another VDR?) has already opened
Hanno Zulla wrote:
So it appears that we have a problem with
1) too many vdr-related projects dying or being orphaned when the
original author looses interest
In most cases, its probably not just loosing interest, but running out
of time. Handling a job, a family and a time-consuming
Hi Klaus list,
Today I had an unexpected parse error in my channels.conf, in this line:
Test Feed;Test Feed:10920:hC56M2O0S0:S19.2E:22000:0:0:0:0:0:1:1063:0
The line was added by automatic transponder scan yesterday. The 'bug' of
this channel is that the SID (4'th last) is 0, triggering
Peter Marquardt wrote:
I don't see any advantages using vdr. Archived material might be used in
future productions, so you'll definitely want to record the best signal,
you can get. Furthermore, archived material might be needed to reproduce
the signal as close as it was, to determine where
Hanno Zulla wrote:
are there known users of vdr within TV or radio operators?
There was a claim that some TV stations use vdr to archive their
broadcast stream and another that vdr is used by cable companies as part
of their infrastructure.
You've probably heard of xeatre.tv, a large scale
Peter Münster wrote:
Is it possible with vdr, to send one audio channel to the headphones and
the other audio channel to the speakers (or another headphones)?
I don't think that this is currently possible, though it would be a
really great feature. The easy way from hardware point - use stereo
Hi list,
Is there a proper way to attach another stream receiver to the currently
receiving channel, and - more important - disconnect it properly on
channel change?
The problem arises from difficulties with the osdteletext plugin. (see
http://www.vdr-portal.de/board/thread.php?threadid=70372
Klaus Schmidinger wrote:
- Find a way to mark a receiver as being 'extremely unimportant', and
don't count them as NeedsDetachReceiver or as Receiving() in that case,
maybe by using -1 as priority.
Using a negative priority would be the right way:
cReceiver(tChannelID ChannelID, int
lucian orasanu wrote:
I dont understend why are you kep mantaining this
patch wen vdr-1.7.0 and all plugins should be evolving
on multiproto. Stop releasing this patch, keep it for you!!
I think that there's a need for it. In my opinion something like VDR
should work on any stable Linux
Hi list,
There's a new version of the DVB API wrapper patch. The new version is
compatible to the current multiproto drivers, and wraps the
DVBFE_SET_DELSYS call.
The new version is based on the vdr-1.7.0-multiproto-update.diff, and
probably works also with the vdr-1.7.0-h264-diff.bz2
lukkinosat wrote:
I set a time of 40 seconds, but if time watchdog is
less than 40 seconds, vdr exit with a segmentation
fault.
Is this normal? Is possible set a message with a time
greater of time watchdog?
It is. VDR 1.4.x even used a dirty workaround to display the 5 minute
shutdown
Rainer Zocholl wrote:
ARD swaps some transponders 2nd June.
With VDR that seems to be a great pain, or?
It doesn't have to, if they move their NID-TID-SID to the new
transponders. VDR will then follow with the existing channel to the new
transponder. Maybe they do that at the end of the
Lauri Tischler wrote:
Does VDR 1.4 - 1.6 work with multiproto drivers ?
The multiproto drivers are fully backwards compatible, all programs
based on the old API work as before. However, the additional features
like DVB-S2 are of course limited to multiproto-aware software like VDR
1.7 or VDR
Igor Nikanov wrote:
Chipmaker Via's S3 Graphics division has announced a high-performance
discrete graphics processor positioned as the first to meet the
embedded industry's thermal requirements. The 4300E targets gaming
and signage, offers HD video, DVI or HDMI output, and mixes dedicated
Lauri Tischler wrote:
If that looks hard, i can push a tree which is a result of the above
outlined steps.
Thanks a lot for providing http://jusst.de/hg/multiproto_plus.
Any instructions somewhere how to stuff that into stock kernel (debian)?
I really don't want to compile the total kernel.
Thiemo wrote:
The patch keeps a time stamp whenever a channel announcement is seen,
and the plugin tracks the first-seen and last-seen time of all channels
Is this timestamp stored in the channels.conf? If so, what about
compatibility?
No, it is not, to preserve compatibility and to keep the
Klaus Schmidinger wrote:
The new version also fixes a bug with the default DVBFE_MOD_AUTO
modulation on DVB-S.
Is this fix also relevant for the original VDR 1.7.0?
No, its just a wrapper bug: After importing a DVB-S channels.conf from
1.6.0, VDR uses DVBFE_MOD_AUTO as modulation, and
Hi list,
There's a new version of the DVB API wrapper patch that adds fallback
compatibility to the current stable DVB API without multiproto support.
The new version also fixes a bug with the default DVBFE_MOD_AUTO
modulation on DVB-S.
Also, the patch for VDR-1.5/1.6 that allows to read a
Peter Evertz wrote:
I am very interested in this feature. My providers (astra/hotbird) are
smart enough not to send not to much garbage, but deleting of unused
channels is really a pain. I am at 4500 Channels in my channels.conf and
I am pretty sure that at least 30 % of them are long gone.
Jean-Claude Repetto wrote:
My Medion MD 4688 remote (from Aldi) has lost its codes because the
batteries were dead :-(
I am not using LIRC, but the RC input of a WinTV DVB-S REV 1.3, and this
is my remote.conf file :
remote-event0._Setup /proc/av7110_ir 8000 20
remote-event0.Up
Ville Skyttä wrote:
I'm a bit confused about the locale dir stuff in VDR 1.6.0 especially wrt.
plugins. newplugin hardcodes LOCALEDIR to $(VDRDIR)/locale without taking
Make.config into account at all. The result is that plugins will try to
place their *.mo into a wrong location if LOCDIR
Clemens Kirchgatterer wrote:
But would it kill anybody to simply have all header files at
a standard place (/usr/include and /usr/local/include)?
yes it would. how would you install different versions of the same
libraries (with their headers) if it wasn't in different paths? and
what about
Timothy D. Lenz wrote:
which, but not all, will be shut down in a year. For ATSC .1 is the primary
channel and .2, .3, etc are the sub channels. The # on the remote could
be used for the . In the channels.conf an ATSC next channel number would
look like:
:@13.1
Well, at least I've never
Klaus Schmidinger wrote:
Users in Germany should please test this, too, and do an
export VDR_CHARSET_OVERRIDE=ISO-8859-9
before starting VDR.
In case we do head for a single override option, wouldn't it be more
consistent to do this with a command line option instead of an
environment
Hi list,
I've updated the runvdr extreme script to version 0.3.
The new version adds some distribution-like comfort to plugin
management, by managing whole directories of configuration files. A new
script, runvdr-conf.d, can be used to manage symbolic links in
/etc/runvdr/conf.d/ for
Hi list,
After some delays, I've finally updated some of my stuff to the latest
i18n standards of VDR. streamplayer-0.1.5 and proxy-0.1.4 now use the
VDR-1.5.8+ compatible i18n system including backwards compatibility and
all the latest newplugin changes. Also, both now have Italian
Rainer Zocholl wrote:
1.4.7), so having no signal on DVB-S is not un-typical for my system.
1.4.3 had the problem to restart vdr in such cases, beraking all
other recording(*).
This restart is not very noticable in the recording.
Believe me, I do notice them. And they really only happen
Udo Richter wrote:
Theunis Potgieter wrote:
udev rules
Any good rules that could be used as a starting point?
Since there's no working solution yet that really satisfied me, I've
digged into this, trying to get automatic persistent numbering of
/dev/dvb/adapterX to work.
My first attempt
Rainer Zocholl wrote:
until he learned that every card in the system MUST
have a -good- antenna signal, regardless if the card is used or not...
because EPG scan would use every card and that VDR behaves -unexpectable-
sick without -good- antenna signals.
I cannot confirm that. My VDR always
Rainer Zocholl wrote:
This unloading leads to ACPI interrupr errors
On the VDR console i could see 3 line
ACPI disabling interupt
This is not an error. If a DVB driver is unloaded, its IRQ is unused and
ACPI disables this IRQ line. As soon as the driver gets loaded again,
the ACPI IRQ will
Rainer Zocholl wrote:
For who knows french, there is an interresting thread about udev on
the dvbkivabien forum. I did use it to have my nexus always as primary
device
http://dvbkivabien2.info/viewtopic.php?f=21t=11255
Vous devez tre inscrit et connect pour pouvoir consulter le contenu
Wolfgang Rohdewald wrote:
char *s;
asprintf(s,%ld-%.9s,random(),artist.original());
segfaults only if illegal utf8 chars appear in artist.original()
asprintf returns -1, so s is nothing that could be freed,
and this gives a nice backtrace:
So its basically just free'ing an
Wolfgang Rohdewald wrote:
since asprintf leads to segfaults if feeded with incorrect UTF-8 characters,
I wanted to write a wrapper function which would then check the return value
of asprintf.
I never understood what the problem is with utf8 and asprintf, since
utf8 is mostly ASCIIZ
Theunis Potgieter wrote:
udev rules
Any good rules that could be used as a starting point?
I thought of doing this with udev, but there are some obstacles for
that: First, a DVB device has several device files, not just one. And
second, the usual trick to add a custom name as symlink doesn't
For people who encounter this bug on recent kernels:
dvb_api_wrapper.c:189: error: '__invalid_size_argument_for_IOC' cannot
appear in a constant-expression
This is caused by an obscure kernel compile check that is supposed to do
macro parameter checking for ioctl constants, but also prevents
Hi list,
Based on the original DVB API patch of last week, I've done a cleaner
rewrite of the patch. This time, the changes to the VDR sources are
limited to a few #includes and replacements of ioctl calls by the new
DVBFE_ioctl wrapper call. All the magic goes into this API wrapper, that
Klaus Schmidinger wrote:
Should there be a stable version 1.6.0 now, based on what's in
version 1.5.14, but without DVB-S2 or even H.264 support?
My answer is a clear and determined 'Maybe'. ;)
A new stable release would bring lots of useful features to the end user
that is still
Gregoire Favre wrote:
Great, I didn't try the Hard Link cutter (see
http://www.linuxtv.org/pipermail/vdr//2008-January/015070.html ) because
I can't seem to apply it cleanly on my vdr, do you have an idea on a
good way to cut H.264 reccording ?
Any detailed information would help. Note that
Hi list,
I've improved the hard link cutter patch. The new 0.2.0 version has
support for multiple /videoXX folders. The new patch tries to find a
compatible /videoXX folder that can hold a hard link for each file. Deep
mounted video folders (like mount to /video/nfs-server/ or
Andrey Kuzmin wrote:
I think that Morfsta's main point isn't any specific feature of VDR
like HD support. The point is VDR's development model itself. It is
closed now. Patches are not the answer to this problem. Developers have
to be very motivated to maintain patches from version till
Klaus Schmidinger wrote:
i suggest the introduction of a new command line option to switch
off writing any epg data (implicitly switching off epg scan). this way
only the server vdr maintains the epg and the clients only read it.
The clients would only read this once at program start.
I
Antti Seppälä schrieb:
BTW. we've actually been looking into adding support for receiving rtsp
streams and while it is more laborous than other protocols I think
implementing it would be entirely possible.
I have an experimental version of my streamplayer plugin that allows to
use RTSP
Hi,
I've published version 0.1.0 of the OSDServer plugin.
OSDServer is a plugin that allows external programs to use the OSD and
the menu system of VDR. Access is done via TCP/IP and a simple script
language that is primarily designed to be handled by perl programs and
shell scripts. Until
JJussi wrote:
How about, when there is no stream - no writing to HD.. OK, if there is 15
minutes break middle of stream, then recording jump those 15 minutes during
playback.
To clear things up: Of course, if there's no stream for whatever
reasons, VDR already does NOT write anything to
dom.plu wrote:
It can be interresting to use the emergency shutdown only when there are no
other records running at the same time
Sounds like a good idea:
Emergency exit on failing to record:
* Never
* Only if this doesn't break other recordings
* Always
Maybe this could even be based on
Torsten Kunkel wrote:
I would love it, if the Makefile could give an errorcode if something
went wrong.
Normally I'm using make plugins ./runvdr when testing plugins.
But if the compile of one or many plugins failes, the makefile gives an
OK, and vdr starts (with the old plugincode).
You
Stone wrote:
vdr: [4922] ERROR: cOsd::SetAreas returned 5
This is oeWrongAlignment, and is returned if an OSD area has negative
size, is outside of the screen, or does not byte-align.
The latter is triggered if a 1-bit OSD has a width that is not multiple
of 8, a 2-bit OSD has a width not
Gergely TAMAS wrote:
Does someone have a patch which enables xineliboutput 1.0.0rc2 to work
with vdr 1.5.9 ?
There's an official patch on the dev' web page:
http://phivdr.dyndns.org/vdr/vdr-xineliboutput/
(You'll need both, the 1.5.3 patch and the 1.5.9 patch)
Cheers,
Udo
Hi list,
I've uploaded version 0.2 of the po2i18n script that converts i18n
strings from gettext to i18n.c format.
The new version now properly handles multi-line i18n strings. To keep
things simple, its still NOT based on Locale::PO. (Sorry, Dieter. ;) )
Also, the Makefile integration for
Matthias Fechner wrote:
cp Make.config.template Make.config
edit it and set LOCDIR=./locale
ok I changed it, now VDR says at startup:
Aug 20 14:53:36 localhost vdr: [23028] found 21 locales in ./locale
Aug 20 14:53:36 localhost vdr: [23028] no locale for language code 'deu,ger'
[..]
But
Luca Olivetti wrote:
The diff fails on all po files, it's only me or does it happens to others?
po files are a pain for diff-patches because they have lists of source
code line numbers in the comments. If you've applied any other patch to
the VDR sources, and did a recompile, then all your po
Dieter Hametner wrote:
I kind of enhanced your script to use the CPAN module Locale::PO for reading
the .po/.pot files. Your implementation did not handle multi line msgids and
msgstrs well.
Hmmm, ok, I don't have multi-line strings that need translation, but
this is probably worth a fix.
Klaus Schmidinger wrote:
- Internationalization is now done with 'gettext' (following a suggestion by
Lucian Muresan).
To add another report, I had some trouble to pick anything but English
at first. After some fiddling and trying the various hints, here's what
was missing for me:
Hi list,
I've uploaded a little perl script and instructions to convert from the
new gettext based po i18n files to the old i18n.c system of VDR 1.5.6
and earlier. By using this script its easy to use the new po based i18n
system for translations, and still compile the plugins with full i18n
Klaus Schmidinger wrote:
On 08/18/07 12:29, Udo Richter wrote:
To add another report, I had some trouble to pick anything but English
at first. After some fiddling and trying the various hints, here's what
was missing for me:
[...]
... and now it works. Is there a way to make VDR less
Michael Brueckner wrote:
Get it here:
http://www.udo-richter.de/vdr/scripts.html#po2i18n
http://www.udo-richter.de/vdr/scripts.en.html#po2i18n
The download-links don't work. I think you must link to 'po2i18n-0.1.tgz'
instead of 'po2i18n.tgz' :)
Oooops! That happens if you don't check
Michael Nausch wrote:
But If I try to do the same on my testsystem (vdr-1.4.7) it won't work!
On syslog I'll only see:
Aug 18 17:21:59 tecvdr vdr: [1916] executing '/usr/local/bin/vdrshutdown
1187452313 1800 0 1'
Aug 18 17:40:51 tecvdr vdr: [1921] executing '/usr/local/bin/vdrshutdown
Matthias Schwarzott wrote:
This time I have some comments on Makefiles for plugins.
1. Is there any reason to not allow plain make without target to work? It
would be so easy to move the all: target before %.o: %.c line.
My plugins usually have an early extra target like this to allow a
Hi list,
For all the version junkies out there, here is proxy plugin version
0.1.3, with full support for VDR 1.5.7 and its new i18n system. Also
fixed: Proxify the WakeupTime() call of VDR 1.5.1.
This version is fully backwards compatible, though it requires gettext
support to compile on all
201 - 300 of 414 matches
Mail list logo
