Re: [vdr] [ANNOUNCE] VDR developer version 1.7.30
12.09.2012 10:39, Tobi kirjoitti: On 11.09.2012 11:30, Anssi Hannula wrote: Hmm, I'm the original author of the patch, not sure why Tobias Grimm is credited here Sorry, that's probably because I maintained this in the Debian package since 2008 and the patch tools added my name to the patch header. I think Manuel sent the patch to Klaus - he asked me 3 months ago who the original author is and from http://projects.vdr-developer.org/git/vdr-plugin-streamdev.git/tree/CONTRIBUTORS#n110 ...I figured out it's you. Yeah, he asked me too and I said the same. This information probably got lost somewhere. Yep :) I didn't meant to take credit for this! But I'm sure Klaus will fix this. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.30
10.09.2012 17:05, Klaus Schmidinger kirjoitti: The changes since version 1.7.29: [...] - The new function cDevice::HasInternalCam() can be implemented by devices that provide encrypted channels in an already decrypted form, without requiring explicit handling of a CAM (thanks to Tobias Grimm). Hmm, I'm the original author of the patch, not sure why Tobias Grimm is credited here (I sent it to you several years ago - for some reason I thought you didn't like it, but I guess I should've just sent it again... sorry for that). -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.30
11.09.2012 19:05, Dominic Evans kirjoitti: On 11 September 2012 10:30, Anssi Hannula anssi.hann...@iki.fi wrote: 10.09.2012 17:05, Klaus Schmidinger kirjoitti: - The new function cDevice::HasInternalCam() can be implemented by devices that provide encrypted channels in an already decrypted form, without requiring explicit handling of a CAM (thanks to Tobias Grimm). Hmm, I'm the original author of the patch, not sure why Tobias Grimm is credited here (I sent it to you several years ago - for some reason I thought you didn't like it, but I guess I should've just sent it again... sorry for that). http://patchwork.linuxtv.org/patch/12893/ Ah, so I *did* send it again after all ;) -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Force VDR to save channels.conf
26.05.2012 23:54, Tobi kirjoitti:
On 26.05.2012 20:56, Artem Makhutov wrote:
How ever - when I restart VDR the changes are not getting saved to
channels.conf.
Check the syslog. There might be a plugin not cleanly shutting down,
making the vdr abort it's shutdown sequence causing it's settings to not
be saved.
Unless things have changed very recently, VDR doesn't save channels.conf
on shutdown.
It only saves it
a) Immediately after user manually modifies channels via VDR
b) 10 minutes after automatic channel update
I've been hit with this many times as well, so I'd suggest to change VDR
so that it saves automatic channel updates on exit as well. Suggested
patch attached (only compile-tested, so actual testing is needed).
--
Anssi Hannula
Index: vdr-1.7.26/vdr.c
===
--- vdr-1.7.26/vdr.c
+++ vdr-1.7.26/vdr.c 2012-05-27 14:32:06.886993810 +0300
@@ -1299,6 +1299,10 @@
Setup.CurrentVolume = cDevice::CurrentVolume();
Setup.Save();
}
+ if (Channels.Modified()) {
+ // Save any automatic channels.conf modifications
+ Channels.Save();
+ }
cDevice::Shutdown();
EpgHandlers.Clear();
PluginManager.Shutdown(true);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
FHS patch This change would be welcome (I'm the VDR package maintainer of Mageia distribution), though it hasn't really been a big issue for me. A couple of comments regarding the INSTALL part: 06.04.2012 16:01, Christopher Reimer kirjoitti: +CACHEDIR = /var/cache/vdr +CONFDIR = /var/lib/vdr Just for the record, this is a bit against FHS rules (Users must never need to modify files in /var/lib to configure a package's operation.), but there really is not better option either... (maybe fhs-discuss@ could be asked for a clarification). +LOCDIR = $(PREFIX)/share/locale +PLUGINLIBDIR = $(PREFIX)/lib/vdr +RESDIR = $(PREFIX)/share/vdr +VIDEODIR = /srv/vdr/video0 Ditto here, /srv contains site-specific data which is served by this system., which video data really isn't. (btw, why 'video0' and not 'video' like is VDR default?) On Mandriva/Mageia packages I use '/var/lib/vdr/config' and '/var/lib/vdr/video', but as I said, they aren't really any better than your suggestions :) Maybe just add a note that the INSTALL example doesn't really conform to current FHS? -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.26
11.03.2012 16:59, Klaus Schmidinger kirjoitti: On 11.03.2012 15:24, Udo Richter wrote: Am 10.03.2012 16:18, schrieb Klaus Schmidinger: Any plugins that implement cStatus::ChannelSwitch() need to add the parameter 'bool LiveView' to that function. The 'status' plugin, part of the VDR source, does not yet use the new LiveView parameter. Yikes! Sorry about that. Just one of many plugin breakages. People should look out for warnings like this: ../../../include/vdr/status.h:33: warning: ‘virtual void cStatus::ChannelSwitch(const cDevice*, int, bool)’ was hidden status.c:21: warning: by ‘virtual void cStatusTest::ChannelSwitch(const cDevice*, int)’ This usually means that channel switch reporting is no longer working! People with C++11 compatible compilers can enable C++11 support and add another declaration like this to cStatus: virtual void ChannelSwitch(const cDevice *Device, int ChannelNumber) final; That will cause the wrong parameters to be treated as an error. Isn't there a way of making this a general error? Like -Woverloaded-virtual makes this a warning, could something like -Eoverloaded-virtual make it an error? -Werror=overloaded-virtual I'd hate to have to add that final keyword to all virtual function declarations... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
28.02.2012 12:24, Gero kirjoitti: On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote: On 28.02.2012 09:32, Frank Schmirler wrote: On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote What exactly is the use case for this, anyway? VDR has two purposes: live view and recording. And the current priority scheme handles this pretty well IMO. I guess in the meantime you could add network streaming to the list of purposes, too. Sure! But talking about future, I think a good VDR-design would be a real client/server-design. Or lets say a modern VDR consists of a backend and a frontend, which may run on different machines, but may also be run on the same machine. So networking is evident and vital. If I understand things right, the decoding of streams is a frontend task, so it would be possible to abstract all datasources as input. That means, streams may come from dvb-card, network, files (any file, that might contain stream data) and of cause from plugins, that might generate streams from pictures or the like. So the backend (beside the recording/timer part) just uniforms the streams and makes them available via network. Frontend demuxes/decodes the streams (if necessary) and routes them to the real output devices. Taking into account, that networking can be broadcasted via UDP or streamed over single TCP-connection, it implies that different frontends might use the same stream from backend or each frontend might use a different stream. That also implies a complete different handling of setup and/or input/commands from frontend. If connection between backend- and frontend-vdr could be established over network, as well as using shared memory, the 2 parts could behave like one, if they were run on the same machine. With that design, vdr could handle all media, that make sense respect to looking and listening, so no more need for xbmc and other hacks ;) I'd very much like something that would result in a better-behaving server-client VDR system, i.e. so that clients just see the recordings,timers,channels,epg just like they are on the server, instead of duplication and the mess when they get out-of-sync. I guess Klaus wants to keep VDR working as a monolithic entity like it currently is, though, but maybe a thin-client (VDR instance with viewing+menu only, with timers/recordings/channels transmitted from the main VDR instance) support could be added as an optional feature. (and probably a similar headless option to have VDR without current-channel and GUI and stuff like that, for the backend) At the moment it all works pretty well in streamdev, ... As far as I understood available docs, streamdev is not able to handle recordings, so I would not say all works I'll keep this in mind for after version 2.0. Why so far? Because 1.6.0 was released a long time ago, and we want a new stable version soon? :) I think, many vdr-users crave for redesign and I'm sure, that some users are willing to participate. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe and IEC958 audio
On 28.01.2012 02:31, Anssi Hannula wrote: On 27.01.2012 16:12, Dominic Evans wrote: I have a digital S/PDIF output from my VDR frontend hooked up to a decent home amplifier and surround speakers. In the past I've had no problems using this via a vdr-sxfe frontend both for stereo MPEG-2 audio, as well as for 5.1 AC-3 on HD channels. audio.device.alsa_default_device:plughw:0,1 audio.device.alsa_front_device:plughw:0,1 audio.device.alsa_passthrough_device:plughw:0,1 audio.device.alsa_surround51_device:plughw:0,1 audio.output.speaker_arrangement:Pass Through However, recently (perhaps due to a kernel / alsa update?) I've found that I have to execute `iecset audio on` (to make analog MPEG-2 audio work) and `iecset audio off` (to make AC-3 passthrough work). Any idea why this might be? I'm not sure why it worked before (the most obvious reason would be a different amplifier which doesn't care for the IEC/AES status bits, but I'm sure you would've mentioned it if that was the case...). Instead of plughw:0,1 for the devices, use e.g. symbolic plug:iec958 (may need CARD=foo parameter if you have multiple cards, in that case look at aplay -L output for the correct value) for normal playback In case you or someone else needs the CARD=foo, the syntax to set ALSA device parameters when using the 'plug' plugin which I forgot to mention is: plug:'iec958:CARD=foo' or plug:iec958:CARD=foo and iec958:AES0=0x06 for passthrough. And the reason I gave no plug for passthrough is that any automatic conversion done by the 'plug' plugin would corrupt the raw encoded audio data. The iec958 ALSA device will automatically set default IEC/AES values when you open the device, making iecset audio on unnecessary. The AES0=0x06 added for passthrough will do the same as iecset audio off (i.e. it will set non-pcm bit 0x02 in the AES0 byte, default AES0 being 0x04 (non-copyright bit)) for the duration of playback. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to convert a JPEG image to an HD video frame?
On 24.07.2011 21:07, André Weidemann wrote: Here are two simple lines to convert a jpg image to mpeg2: convert $Pict -background '#00' -resize 1920x1080 -gravity center -extent 1920x1080 /tmp/test.jpg ffmpeg -i /tmp/temp.jpg -an -vcodec mpeg2video -b 2500 -s 1920x1080 -qscale 2 -f mpeg2video $Mpeg Note: Depending on your distro, ffmpeg may not support mpeg2 video encoding. For mpeg4 the ffmpeg line looks like this: ffmpeg -i /tmp/temp.jpg -an -vcodec mpeg4 -b 2500 -s 1920x1080 -qscale 2 -threads 4 -f mp4 $Mpeg For libx264 it looks like this: ffmpeg -i /tmp/temp.jpg -an -vcodec libx264 -vpre lossless_ultrafast -s 1920x1080 -qscale 2 -threads 4 -f mp4 $Mpeg Note that -f mp4 means the output is not raw mpeg-4/H.264 but in the mp4 file format. For raw video (like mpeg2video in your first example), for MPEG-4 one can use -f m4v and for H.264 -f h264. The -vpre parameter requires a preset. They can usually be found under /usr/share/ffmpeg/libx264-*.ffpreset. If you want a 10 second video at 25 fps, you can do it like this: ffmpeg -loop_input -t 10 -r 25 -i /tmp/temp.jpg -an -vcodec mpeg4 -b 2500 -s 1920x1080 -qscale 2 -threads 4 -f mp4 $Mpeg You may want to adjust the number of threads according to the number of cores in your machine. André ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD programme recording still broken
On 11.06.2011 12:24, Klaus Schmidinger wrote:
On 11.06.2011 00:30, Luboš Doležel wrote:
On 10.6.2011 23:59, Klaus Schmidinger wrote:
The defualt is 5.
From MANUAL:
DVB:
Update channels = 5 Controls the automatic channel update
function. '0' means
no update, '1' will only update channel names,
'2' will
only update PIDs, '3' will update channel
names and PIDs,
'4' will perform all updates and also add
newly found channels,
and '5' will also add newly found transponders.
Note that adding new transponders only works
if the EPG scan
is active.
Klaus
Now I know why I disabled this function. Right after enabling it, VDR
added CAIDs to all encrypted channels and I cannot tune them any more
(I use streamdev-server).
CT HD;CS
Link:11973:v:S23.5E:27500:2010=27:2020=cze@4,2023=qaa@4;2021=cze@106:0:D0F,624,D70,D03,D96:14070:3:3214:0
How should I tell VDR not to care about encryption, as the decryption
is fully handled by the dvbloopback virtual DVB device (sasc-ng)?
I guess that's something the streamdev-server should handle.
One solution is to use the patch
streamdev/patches/vdr-1.6.0-intcamdevices.patch (also attached) for VDR,
so that VDR won't try to decrypt channels received by streamdev-client.
I wrote it in 2008 to allow receiving channels in streamdev client that
are already decrypted by the CAM of the main VDR instance, while
allowing the use of the same channels.conf.
(it may not apply cleanly anymore)
--
Anssi Hannula
Index: vdr-1.6.0-nocamdevices/device.c
===
--- vdr-1.6.0-nocamdevices/device.c
+++ vdr-1.6.0-nocamdevices/device.c 2008-04-27 18:55:37.0 +0300
@@ -363,6 +363,7 @@
int NumCamSlots = CamSlots.Count();
int SlotPriority[NumCamSlots];
int NumUsableSlots = 0;
+ bool InternalCamNeeded = false;
if (Channel-Ca() = CA_ENCRYPTED_MIN) {
for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = CamSlots.Next(CamSlot)) {
SlotPriority[CamSlot-Index()] = MAXPRIORITY + 1; // assumes it can't be used
@@ -376,7 +377,7 @@
}
}
if (!NumUsableSlots)
-return NULL; // no CAM is able to decrypt this channel
+InternalCamNeeded = true; // no CAM is able to decrypt this channel
}
bool NeedsDetachReceivers = false;
@@ -392,11 +393,13 @@
continue; // this device shall be temporarily avoided
if (Channel-Ca() Channel-Ca() = CA_DVB_MAX Channel-Ca() != device[i]-CardIndex() + 1)
continue; // a specific card was requested, but not this one
- if (NumUsableSlots !CamSlots.Get(j)-Assign(device[i], true))
+ if (InternalCamNeeded !device[i]-HasInternalCam())
+ continue; // no CAM is able to decrypt this channel and the device uses vdr handled CAMs
+ if (NumUsableSlots !device[i]-HasInternalCam() !CamSlots.Get(j)-Assign(device[i], true))
continue; // CAM slot can't be used with this device
bool ndr;
if (device[i]-ProvidesChannel(Channel, Priority, ndr)) { // this device is basicly able to do the job
- if (NumUsableSlots device[i]-CamSlot() device[i]-CamSlot() != CamSlots.Get(j))
+ if (NumUsableSlots !device[i]-HasInternalCam() device[i]-CamSlot() device[i]-CamSlot() != CamSlots.Get(j))
ndr = true; // using a different CAM slot requires detaching receivers
// Put together an integer number that reflects the impact using
// this device would have on the overall system. Each condition is represented
@@ -410,18 +413,18 @@
imp = 1; imp |= device[i]-Receiving(); // avoid devices that are receiving
imp = 1; imp |= device[i] == cTransferControl::ReceiverDevice(); // avoid the Transfer Mode receiver device
imp = 8; imp |= min(max(device[i]-Priority() + MAXPRIORITY, 0), 0xFF); // use the device with the lowest priority (+MAXPRIORITY to assure that values -99..99 can be used)
- imp = 8; imp |= min(max((NumUsableSlots ? SlotPriority[j] : 0) + MAXPRIORITY, 0), 0xFF); // use the CAM slot with the lowest priority (+MAXPRIORITY to assure that values -99..99 can be used)
+ imp = 8; imp |= min(max(((NumUsableSlots !device[i]-HasInternalCam()) ? SlotPriority[j] : 0) + MAXPRIORITY, 0), 0xFF); // use the CAM slot with the lowest priority (+MAXPRIORITY to assure that values -99..99 can be used)
imp = 1; imp |= ndr; // avoid devices if we need to detach existing receivers
imp = 1; imp |= device[i]-IsPrimaryDevice(); // avoid the primary device
- imp = 1; imp |= NumUsableSlots
[vdr] [PATCH] do not flag all audio tracks as clean effects in remux.c
Hi! cPatPmtGenerator::MakeLanguageDescriptor in remux.c incorrectly flags all audio tracks as clean effects, which means a track without any voice or language. The proper solution would be to preserve the audio_type of the original stream (which may indicate e.g. a visual-impaired audio track, as used for e.g. automated subtitles-to-speech audio tracks by YLE here in Finland). The attached patch is a simpler stop-gap measure that simply always sets the audio_type to the value of 0x00 which means a normal track, which is obviously better than marking the track as a special clean effects one. -- Anssi Hannula --- vdr-1.7.16/remux.c 2010-06-05 16:32:15.0 +0300 +++ vdr-1.7.16-m/remux.c 2011-02-14 19:37:58.575610709 +0200 @@ -225,7 +225,7 @@ Target[i++] = *Language++; Target[i++] = *Language++; Target[i++] = *Language++; - Target[i++] = 0x01; // audio type + Target[i++] = 0x00; // audio type Target[Length] += 0x04; // length if (*Language == '+') Language++; ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to remove double quotes in names for sharing in samba?
Andrey Kuzmin kirjoitti torstai, 22. huhtikuuta 2010 23:40:51: What I'm trying to do is to make a samba network share to /video folder to watch recordings from windows PCs. Everything works, BUT... Many EPG titles from my provider contain double quotes, so recordings look like TITLE_IN_RUSSIAN . When file names countains , samba converts this to something like _324CDE35 , so share contains unreadable directory names. I haven't found any way to force samba to deal with double quotes, so looking now for any way to force VDR to remove double quotes from recording names. VDR option --vfat removes special characters from recording file names. One obvious way is to make a shell script that removes , but in this case it's not clear when to execute it, I mean how to know that recording finished. See Executing commands before and after a recording in INSTALL. Though I guess --vfat is probably enough for you. Any other ideas how to walk around this issue? -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH] fix plugin arguments corruption
VDR uses the construct strcpy(s, s + 1) in plugin arguments processing for
stripping first character of s. However, as per strcpy man page, the source
and destination strings may not overlap.
There are a couple of ways to fix them, but the attached patch simply changes
them to memmove(s, s + 1, strlen(s)). The patch applies both to 1.7.10 and
1.6.0.
This fixes plugin arguments corruption with glibc 2.11 on x86_64.
--
Anssi Hannula
Index: vdr-1.7.10/plugin.c
===
--- vdr-1.7.10/plugin.c
+++ vdr-1.7.10/plugin.c 2010-01-06 12:47:43.396957257 +0200
@@ -172,15 +172,15 @@
static char *SkipQuote(char *s)
{
char c = *s;
- strcpy(s, s + 1);
+ memmove(s, s + 1, strlen(s));
while (*s *s != c) {
if (*s == '\\')
- strcpy(s, s + 1);
+ memmove(s, s + 1, strlen(s));
if (*s)
s++;
}
if (*s) {
- strcpy(s, s + 1);
+ memmove(s, s + 1, strlen(s));
return s;
}
esyslog(ERROR: missing closing %c, c);
@@ -215,7 +215,7 @@
if (!q)
q = p;
switch (*p) {
-case '\\': strcpy(p, p + 1);
+case '\\': memmove(p, p + 1, strlen(p));
if (*p)
p++;
else {
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] multiple non-independent frontends (was: Re: [ANNOUNCE] VDR developer version 1.7.11)
Klaus Schmidinger wrote: On 06.01.2010 14:22, Tomasz Bubel wrote: [...] - Added support for DVB cards with multiple fontends. Note that this only works for DVB cards where each frontend can be used independently of all the others on the same adapter. [...] Any chance of using using DVB-T frontend on HVR-4000? This card have 2 separate frontends. And as quoted on http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000: Multiple frontends are supported: DVB-S/S2 and DVB-T appear as /dev/dvb/adapterN/frontend0 and /dev/dvb/adapterN/frontend1 respectively. Due to a hardware limitation, the two frontends cannot be used simultaneously. However they can be used sequentially within the same application. The driver handles the mutual exclusion appropriately. Well, that's still a problem. Is there a defined way (via the LinuxDVB driver API) through which VDR can find out whether the frontends can be used independently? Shouldn't all frontends that are independent show up as completely different adapters in /dev/dvb/, so that VDR can assume only one frontend per adapter is usable simultaneously? If not, why is that? -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Dynamic PIDs
Klaus Schmidinger wrote: On 24.11.2009 18:28, Jouni Karvo wrote: Jouni Karvo kirjoitti: Rolf Ahrenberg kirjoitti: On Mon, 23 Nov 2009, Jouni Karvo wrote: is there somewhere a patch that would remove the break when the broadcaster uses dynamic pids (such as YLE). Now, when a programme starts at YLE, they change the Audio PID number, leading to VDR re-tuning or something, that leads to a 1-2s break in the show. There is no change in frequency, so I don't see any reason why there is such a break. As a quick fix just disable the pid updates (Channel update: no/names only). Yle is always using the same pid numbers although they're switching them on and off, so you can easily fix these numbers in your channel.conf. Tried this, but it seems it loses the subtitling PIDs. Is there a way to get both - subtitling and non-breaking TV viewing? It might be interesting to learn why they do this PID cycling in the first place. Have you ever tried contacting them and asking why they do such a stupid thing? Different programmes have a different number of languages, so the number of active pids changes. Isn't that correct behaviour? -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Dynamic PIDs
Klaus Schmidinger wrote: On 24.11.2009 19:22, Anssi Hannula wrote: Klaus Schmidinger wrote: On 24.11.2009 18:28, Jouni Karvo wrote: Jouni Karvo kirjoitti: Rolf Ahrenberg kirjoitti: On Mon, 23 Nov 2009, Jouni Karvo wrote: is there somewhere a patch that would remove the break when the broadcaster uses dynamic pids (such as YLE). Now, when a programme starts at YLE, they change the Audio PID number, leading to VDR re-tuning or something, that leads to a 1-2s break in the show. There is no change in frequency, so I don't see any reason why there is such a break. As a quick fix just disable the pid updates (Channel update: no/names only). Yle is always using the same pid numbers although they're switching them on and off, so you can easily fix these numbers in your channel.conf. Tried this, but it seems it loses the subtitling PIDs. Is there a way to get both - subtitling and non-breaking TV viewing? It might be interesting to learn why they do this PID cycling in the first place. Have you ever tried contacting them and asking why they do such a stupid thing? Different programmes have a different number of languages, so the number of active pids changes. Isn't that correct behaviour? Sure, but why cycle them through various values, and not use the same ones for the same languages? As far as I can see they keep them the same, and VDR retunes just because the number of tracks changes. As long as the PID switch takes place outside a show, that's of course ok. Switching them *inside* a show is IMHO not a good idea. The change of active PIDs takes place when a show begins, causing 1-2s of stream to go missing due to the retune as Jouni described in the initial post. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softplay like plugin for vdr-xine w/ vdpau?
Torgeir Veimo wrote: 2009/9/12 Gregoire Favre gregoire.fa...@gmail.com: On Sat, Sep 12, 2009 at 06:09:28PM +1000, Torgeir Veimo wrote: Am looking for a softplay like plugin for use with vdr-xine in a vdpau setup. I couldn't really find anything suitable. Could you describe what you want exactly ? I use http://home.vrweb.de/~rnissl/ but I am not sure of what you're looking for. Softplay is a plugin that lets you play back media files from disk of any format supported by ffmpeg using the softdevice plugin. I'd like to play back h.264 files from disk using vdr. You might want to try out vdr-xineliboutput, as it contains such a feature. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.9
Goga777 wrote: Your headers seem broken. What should happen (i.e. in upstream kernel git) is: let's have a look on my headers (debian sid kernel 2.6.30 s2-liplianin dvb) Did you look in /usr/include/linux/dvb/... or in /usr/src/linux/... ? /usr/src/s2-liplianin/linux For compiling userspace stuff (which vdr for sure is), the versions in /usr/include are used. not so necessary it's possible to change this behaviour -- edit -- Make.config -- DVBDIR = /usr/src/s2-liplianin/linux Run this: g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -E -DREMOTE_KBD -DLIRC_DEVICE=\/dev/lircd\ -DRCU_DEVICE=\/dev/ttyS0\ -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DVIDEODIR=\/video\ -DCONFDIR=\/etc/vdr\ -DPLUGINDIR=\./PLUGINS/lib\ -DLOCDIR=\./locale\ -I/usr/include/freetype2 -I../s2-liplianin/linux/include -o vdr.processed.c vdr.c vdr.processed.c should contain the preprocessed C++ source code. Please attach it (provided it is not too large) or upload somewhere. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.9
Goga777 wrote: Run this: g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -E -DREMOTE_KBD -DLIRC_DEVICE=\/dev/lircd\ -DRCU_DEVICE=\/dev/ttyS0\ -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DVIDEODIR=\/video\ -DCONFDIR=\/etc/vdr\ -DPLUGINDIR=\./PLUGINS/lib\ -DLOCDIR=\./locale\ -I/usr/include/freetype2 -I../s2-liplianin/linux/include -o vdr.processed.c vdr.c vdr.processed.c should contain the preprocessed C++ source code. Please attach it (provided it is not too large) or upload somewhere. vdr.processed.c.bz2 http://slil.ru/27922128 Which distribution and version are you using? And package name where /usr/include/linux/types.h and related files would also help: rpm -qf /usr/include/linux/types.h (on rpm systems) dpkg -S /usr/include/linux/types.h (on deb systems, I think) -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.9
Goga777 wrote: Which distribution and version are you using? debian sid kernel 2.6.30 And package name where /usr/include/linux/types.h and related files would also help: rpm -qf /usr/include/linux/types.h (on rpm systems) dpkg -S /usr/include/linux/types.h (on deb systems, I think) arvdr:/usr/src/vdr-1.7.9# dpkg -S /usr/include/linux/types.h linux-libc-dev: /usr/include/linux/types.h Thank you. The bug is in libcap header file /usr/include/sys/capability.h It does evil stuff like this: 25 /* 26 * Make sure we can be included from userland by preventing 27 * capability.h from including other kernel headers 28 */ 29 #define _LINUX_TYPES_H 30 #define _LINUX_FS_H 31 #define __LINUX_COMPILER_H 32 #define __user 33 34 typedef unsigned int __u32; 35 typedef __u32 __le32; This completely prevents including /usr/include/linux/types.h, etc. It seems my distro has a patch that removes all the above lines to resolve this issue. I'll try contacting libcap upstream on this issue. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.9
Anssi Hannula wrote: Thank you. The bug is in libcap header file /usr/include/sys/capability.h It does evil stuff like this: 25 /* 26 * Make sure we can be included from userland by preventing 27 * capability.h from including other kernel headers 28 */ 29 #define _LINUX_TYPES_H 30 #define _LINUX_FS_H 31 #define __LINUX_COMPILER_H 32 #define __user 33 34 typedef unsigned int __u32; 35 typedef __u32 __le32; This completely prevents including /usr/include/linux/types.h, etc. It seems my distro has a patch that removes all the above lines to resolve this issue. I'll try contacting libcap upstream on this issue. In the meantime, attached is a workaround that contains a clear comment describing the issue. -- Anssi Hannula Index: vdr-1.7.9/vdr.c === --- vdr-1.7.9/vdr.c +++ vdr-1.7.9/vdr.c 2009-08-23 23:26:15.935332431 +0300 @@ -32,7 +32,6 @@ #include pwd.h #include signal.h #include stdlib.h -#include sys/capability.h #include sys/prctl.h #include termios.h #include unistd.h @@ -64,6 +63,9 @@ #include tools.h #include transfer.h #include videodir.h +// include this one last due to some versions of it being buggy: +// http://www.linuxtv.org/pipermail/vdr/2009-August/021194.html +#include sys/capability.h #define MINCHANNELWAIT10 // seconds to wait between failed channel switchings #define ACTIVITYTIMEOUT 60 // seconds before starting housekeeping ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD clients for vdr
Magnus Hörlin wrote: Hi. My opinion is that nvidia's ION platform with vdpau and XBMC gives the best result. The atom's cpu load is 10% playing 1080p h264 so forget the 3GHz core2 unless you want to play Flash HD movies or other non-vdpau formats. Isn't Flash HD content usually encoded in H.264? That's the case in youtube, at least, and the clips play fine using vdpau decoding in mplayer. It's not very cheap yet but you can build a fanless one for €200. For example a http://www.cartft.com/catalog/il/1072 together with 2G ram and a pico-psu. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.8 - __u8’ does not name a type
Goga777 wrote: Hi I added #include asm/types.h as Tobi recommended http://e-tobi.net/websvn/filedetails.php?repname=vdr-pkgpath=%2Fvdr%2Fbranches%2Fdevel%2Fdebian%2Fpatches%2F99_dvb-header-fixes.dpatch and after that I could compile vdr 178 [...] ../s2-liplianin/linux/include/linux/dvb/frontend.h:92: error: ‘__u8’ does not name a type Strange, that file (at least current version) #includes linux/types.h, which in turn (/usr/include/linux/types.h) #includes asm/types.h. Including asm/types.h from VDR should not be necessary. Could you confirm that your frontend.h file also contains #include linux/types.h and tha tyour /usr/include/linux/types.h #includes asm/types.h ? -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Compilation issues with recent DVB header files vs libc6
Tobi wrote: Anssi Hannula wrote: The kernel headers should be fixed to use strict types (patches available). See my earlier reply on the issue: http://linuxtv.org/pipermail/vdr/2009-March/019783.html You're right. Thanks for the pointer! I've seen this weeks ago and thought it would have already made it into 2.6.29. I've applied the patch from Arnd Bergmann's core/header-fixes branch to 2.6.29.1 which seems to work fine. Let's hope this gets fixed in 2.6.29.x or 2.6.30. The patches have been applied for 2.6.30. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
Jouni Karvo wrote: I'd be pleased, if there would be some kind of a caretaking, so that the pause-live-tv recording would just disappear after returning to other modes of operation. I think it would not break anything for the user, since you can always use the specific recording button in the menu to create an actual recording. Agreed. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
VDR User wrote: On Thu, May 7, 2009 at 11:38 AM, Jouni Karvo jouni.ka...@iki.fi wrote: I'd be pleased, if there would be some kind of a caretaking, so that the pause-live-tv recording would just disappear after returning to other modes of operation. I think it would not break anything for the user, since you can always use the specific recording button in the menu to create an actual recording. If you want to pause live tv, how else would you suggest caching the stream? It's either going to be to ram or some storage device, and if you don't save the stream (aka record it), how are you supposed to play it back? Unless you mean VDR should somehow determine that you've caught up to live tv from playing back at the point you paused it, and then delete the recording/cache without caring if you wanted to keep it for any reason. He meant the latter. I really hope Klaus never intends to implement something like the live tv buffer that myth has. The idea of one of my harddrives saving nonstop 24/7 is really really lame. Huge waste of power, constant heat, and unnecessary wear on the harddrive for something that probably doesn't even get used that much in the first place. Use RAM. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Best practices for running vdr-xine
Simon Baxter wrote: IMHO... I've used both, and xineliboutput is arguably easier to get working as you only need the standard xine-lib for your repo, but I've chosen over the years to use vdr-xine as it seems to give the most options to change the front end, as it uses the standard one. What do you mean here? xineliboutput can be used with standard xine frontends as well, e.g. with xine-ui: xine xvdr://127.0.0.1#nocache;demux:mpeg_block I start it with: xine --no-splash -Bfpqg -r anamorphic -V xv -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1 --post vdr_video --post vdr_audio vdr://tmp/vdr-xine/stream#demux:mpeg_pes /dev/null 21 It's served me well for 5 years... -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Compilation issues with recent DVB header files vs libc6
Tobi wrote: Hi! Recent DVB driver releases (now in Kernel 2.6.29) cause trouble compiling VDR (see snippet A below). The common solution to this seems to be to add a -D__KERNEL_STRICT_NAMES. It felt wrong somehow and I didn't liked this, so I tried another solution, which is to have any libc6 sys/* includes appear before the linux DVB header includes linux/*. Doing this only in dvbdevice.c seems to do the trick for VDR (see snippet B). I works for VDR 1.6.0 as well as VDR 1.7.4. I think the root of this problem is caused by the Kernel headers / DVB drivers changing from asm/types.h to linux/types.h: -#include asm/types.h +#include linux/types.h How should this problem ideally be fixed? Is my solution (snippet B) better than using -D__KERNEL_STRICT_NAMES or should the kernel / DVB driver developers be blamed for this? The kernel headers should be fixed to use strict types (patches available). See my earlier reply on the issue: http://linuxtv.org/pipermail/vdr/2009-March/019783.html -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] compil vdr-1.7.4 against v4l-dvb hg as of today
Gregoire Favre wrote: Hello, just tried compiling vdr-1.7.4 against my v4l-dvb hg's source which fails if I don't use this : [...] This is because of a kernel regression: http://lkml.indiana.edu/hypermail/linux/kernel/0902.3/00411.html A set of patches fixing this is available here: http://lkml.indiana.edu/hypermail/linux/kernel/0902.3/00955.html and here: http://git.kernel.org/?p=linux/kernel/git/jaswinder/linux-2.6-tip.git;a=shortlog;h=core/header-fixes Specifically, the one fixing the breakage in DVB headers is make most exported headers use strict integer types, i.e.: http://git.kernel.org/?p=linux/kernel/git/jaswinder/linux-2.6-tip.git;a=commitdiff;h=57b4b9d7b56d283b6619a893341be16d1a0467a6 I do wonder why it hasn't yet been pushed into Torvalds' tree (it has been over a week since the patches were published), though. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] can't compile xine for vdr
Ludwig Nussel wrote: Darren Salt wrote: I demand that Ludwig Nussel may or may not have written... Andreas Hölscher wrote: I installed a fresh SuSE 11.1 on my computer and tried to compile xine-lib for use with xine vdr plugin. [..doesn't work..] I'm not a programmer, so I don't know what to do now. Can anyone point me in the right direction please? libxine1 as shipped on 11.1 already contains the vdr plugin. Packman has the xine plugins for mpeg. That's binary-incompatible with other distributions. I hope that the soname has been adjusted appropriately... No, I actually haven't paid attention to that problem. AFAICS the ABI incompatible changes affect post_video_port_s in post.h and xine_video_port_s in video_out.h. Only post plugins or new video outputs would be affected by that I guess. So hopefully not that bad after all. Well, the SONAME in libxine reflects application interface only. The plugin API has a different versioning. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Finnish DVB-C channel Nelonen HD - h264
JJussi wrote: On Sunday, 29. Juneta 2008 03:34:57 Anssi Hannula wrote: [h264 @ 0xb791d708]PAFF interlacing is not implemented This indicates that xine-lib is not using a new enough ffmpeg snapshot that supports PAFF. Depending on the version of ffmpeg your distribution provides, adding --with-external-ffmpeg to xine-lib ./configure line could be enough. I think PAFF interlacing was added to ffmpeg sometime last year. But as you can see from xine-lib compile log, --with-external-ffmpeg is on.. ffmpeg version is 0.4.9_p20070616-r2 as compile log states. Too old ffmpeg snapshot, then. If the problem is just PAFF, then a newer snapshot will fix it. However, PAFF + spatial direct mode is not supported by current ffmpeg. If that is the case, the error message will change to PAFF + spatial direct mode is not implemented. I'm not on Welho so I don't know whether Nelonen HD uses that mode. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Finnish DVB-C channel Nelonen HD - h264
Anssi Kolehmainen wrote: On Sun, Jun 29, 2008 at 08:02:05PM +0300, Anssi Hannula wrote: JJussi wrote: On Sunday, 29. Juneta 2008 03:34:57 Anssi Hannula wrote: [h264 @ 0xb791d708]PAFF interlacing is not implemented This indicates that xine-lib is not using a new enough ffmpeg snapshot that supports PAFF. Depending on the version of ffmpeg your distribution provides, adding --with-external-ffmpeg to xine-lib ./configure line could be enough. I think PAFF interlacing was added to ffmpeg sometime last year. But as you can see from xine-lib compile log, --with-external-ffmpeg is on.. ffmpeg version is 0.4.9_p20070616-r2 as compile log states. Too old ffmpeg snapshot, then. If the problem is just PAFF, then a newer snapshot will fix it. However, PAFF + spatial direct mode is not supported by current ffmpeg. If that is the case, the error message will change to PAFF + spatial direct mode is not implemented. When I try to play streams with mplayer (debian-multimedia, 1:1.0.rc2svn20080531-0.1) it says: [h264 @ 0x87a30d0]PAFF + spatial direct mode is not implemented% 85 0 0% I'm not on Welho so I don't know whether Nelonen HD uses that mode. FWIW, I put a few seconds long test clip of that channel to http://kelvin.aketzu.net/~akolehma/nelonen-hd.ts Hmm, I indeed get the same message with current ffmpeg SVN (using ffplay). However, the picture is decoded fine (!). Recoded using vdr-streamdev and wget http://vdr:3000/TS/12 -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Finnish DVB-C channel Nelonen HD - h264
JJussi wrote: Hi! I have vdr-1.7.0 installed and when I tune to that Nelonen HD channel, I get very disordered picture and sound. And lot's of errors. Have anybody here at HTV are managed to get that h264 channel working, if yes, how? (What I'm missing) Full logfile can be found http://jjussi.pp.fi/logs/h264.log [h264 @ 0xb791d708]PAFF interlacing is not implemented This indicates that xine-lib is not using a new enough ffmpeg snapshot that supports PAFF. Depending on the version of ffmpeg your distribution provides, adding --with-external-ffmpeg to xine-lib ./configure line could be enough. I think PAFF interlacing was added to ffmpeg sometime last year. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine + mplayer-plugin + MPlayer - is it possible ?
Goga777 wrote: Hi i try to run MPlayer on my vdr 170 + mplayer-plugin from HG + vdr-xine (if it possible) in mplayer.sh I have written #!/bin/sh CMDLINE=mplayer -fs -vo xv -ao alsa -cache 4096 -slave -nolirc -quiet DISPLAY=:0.0 $CMDLINE $1 |logger exit but after the start of reply some file with mplayer-plugin I have resume: resume file is '/mnt/asp/video/hdtv/.mplayer.resume' resume: assuming empty resume file [VO_XV] Could not grab port 65. [VO_XV] Could not find free Xvideo port - maybe another process is already [VO_XV] using it. Close all video applications, and try again. If that does [VO_XV] not help, see 'mplayer -vo help' for other (non-xv) video out drivers. Error opening/initializing the selected video_out (-vo) device. [...] I think the xine locked the videocard and due to this MPlayer can't lock it. Is it possible to solve this issue ? Your card/driver only has one Xvideo port. Some ATI card maybe? Possible solutions: a) Fix xine/vdr-xine to completely release video output (xvideo port) when ePlayMode is set to pmExtern_THIS_SHOULD_BE_AVOIDED. b) Change video card or try a different driver. c) Use some other output method (such as opengl) than Xvideo for either xine or mplayer. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine + mplayer-plugin + MPlayer - is it possible ?
Goga777 wrote: Your card/driver only has one Xvideo port. Some ATI card maybe? yes ATI Radeon 9600 How is it possible to know how many xvideo ports has my card/driver ? xvinfo tells that. E.g. I get: # xvinfo X-Video Extension version 2.2 screen #0 Adaptor #0: NV17 Video Texture number of ports: 32 [..lots of lines removed...] -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine + mplayer-plugin + MPlayer - is it possible ?
Goga777 wrote: I don't know if this is applicable for your setup, but did you try vdr-plugin-xineliboutput instead of vdr-plugin-xine? It is at least 3 things in one: - Client/Server architecture: splits VDR (server) and displaying software - Media Player integrated (via OSD) - X11 (XV or others) display (vdr-sxfe) no, I didn't try to use xineliboutput ? is it support h.264 video ? Yes. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with dvd plugin.. Anyone know how to fix?
VDR User wrote: Recently I've been getting the following error when compiling the dvd plugin: /usr/include/dvdread/ifo_types.h:32:2: error: #error Must include inttypes.h or stdint.h before any libdvdread header. This is with debian sid, gcc-3.4 and gcc-4.2, and dvd-0.3.6-b04. I tried to add #include inttypes.h into the beginning of /usr/include/dvdread/ifo_types.h but it had no affect. Many thanks for your help! You probably need to define __STDC_LIMIT_MACROS, e.g. add -D__STDC_LIMIT_MACROS to compiler parameters. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with dvd plugin.. Anyone know how to fix?
VDR User wrote: On Sat, May 31, 2008 at 10:00 PM, Simon Baxter [EMAIL PROTECTED] wrote: Hi. I had the same problem originally. Can't remember what I did, and in what order - but this should help [EMAIL PROTECTED] dvd]# pwd /root/vdr-1.6.0/PLUGINS/src/dvd [EMAIL PROTECTED] dvd]# grep stdint.h * ca52.c:#include stdint.h tools-dvd.h:#include stdint.h [EMAIL PROTECTED] dvd]# grep inttypes.h * ca52.h:#include inttypes.h dvdspu.c:#include inttypes.h dvdspu.h:#include inttypes.h tools-dvd.h:#include inttypes.h I have those too, but they were already there. I'm using a CVS snapshot of dvd plugin from 2007-10-30. I added #include stdint.h and #include inttypes.h to the top of all those files and still got the same error. Which libdvdread-dev version are you using? I've got: ii libdvdread-dev 0.9.7-10 library for reading DVDs (development) I have the same. With libdvdnav 0.1.10 works directly, with 4.1.1 I need the below define, with 4.1.2 I need the below define and a patch to libdvdnav: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/libdvdnav/current/SOURCES/libdvdnav-4.1.2-c%2B%2B-header.patch?revision=202766view=markup Btw, I also tried adding -D__STDC_LIMIT_MACROS to compiler parameters as Anssi suggested but that had no affect as well. -- Anssi Hannula -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with dvd plugin.. Anyone know how to fix?
VDR User wrote: On Sun, Jun 1, 2008 at 12:30 PM, Anssi Hannula [EMAIL PROTECTED] wrote: With libdvdnav 0.1.10 works directly, with 4.1.1 I need the below define, with 4.1.2 I need the below define and a patch to libdvdnav: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/libdvdnav/current/SOURCES/libdvdnav-4.1.2-c%2B%2B-header.patch?revision=202766view=markup I downgraded to 0.1.10 and had no compile errors. Then I upgraded back to 4.1.2 and tried compile with that patch and the define but the error reappeared! I guess the only solution for me is to use the old 0.1.10 package. Not sure why 4.1.2 + patch + define didn't work for me if it works at your end..! To Halim: I use a nexus card and the dvd plugin seems to work here. I have not noticed any sync problems. I also have only played retail dvd's, no self-burned. What version of dvd plugin you are using? (I don't know if it matters, though) -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR constantly adding and deleting filters
: [30682] Adding, pmtPid 264, Index = 4, Sid = 209
May 6 05:18:43 epsilon vdr: [30688] Deleting, pmtPid 259, pmtIndex = 2,
lastPmtScan = 0
May 6 05:18:43 epsilon vdr: [30688] Adding, pmtPid 260, Index = 4, Sid = 129
May 6 05:18:43 epsilon vdr: [30685] Deleting, pmtPid 256, pmtIndex = 0,
lastPmtScan = 0
May 6 05:18:43 epsilon vdr: [30685] Adding, pmtPid 257, Index = 2, Sid = 273
May 6 05:18:43 epsilon vdr: [30682] Deleting, pmtPid 264, pmtIndex = 3,
lastPmtScan = 0
May 6 05:18:43 epsilon vdr: [30682] Adding, pmtPid 260, Index = 5, Sid = 257
May 6 05:18:43 epsilon vdr: [30679] Deleting, pmtPid 1144, pmtIndex = 8,
lastPmtScan = 0
May 6 05:18:43 epsilon vdr: [30679] Adding, pmtPid 1145, Index = 10, Sid =
1510
May 6 05:18:43 epsilon vdr: [30688] Deleting, pmtPid 260, pmtIndex = 3,
lastPmtScan = 0
May 6 05:18:43 epsilon vdr: [30688] Adding, pmtPid 258, Index = 5, Sid = 145
May 6 05:18:43 epsilon vdr: [30682] Deleting, pmtPid 260, pmtIndex = 4,
lastPmtScan = 0
May 6 05:18:43 epsilon vdr: [30682] Adding, pmtPid 261, Index = 6, Sid = 241
May 6 05:18:43 epsilon vdr: [30685] Deleting, pmtPid 257, pmtIndex = 1,
lastPmtScan = 0
May 6 05:18:43 epsilon vdr: [30685] Adding, pmtPid 258, Index = 3, Sid = 289
May 6 05:18:43 epsilon vdr: [30688] Deleting, pmtPid 258, pmtIndex = 4,
lastPmtScan = 0
May 6 05:18:43 epsilon vdr: [30688] Adding, pmtPid 261, Index = 6, Sid = 4369
May 6 05:18:44 epsilon vdr: [30682] Deleting, pmtPid 261, pmtIndex = 5,
lastPmtScan = 0
May 6 05:18:44 epsilon vdr: [30682] Adding, pmtPid 259, Index = 7, Sid = 177
May 6 05:18:44 epsilon vdr: [30685] Deleting, pmtPid 258, pmtIndex = 2,
lastPmtScan = 0
May 6 05:18:44 epsilon vdr: [30685] Adding, pmtPid 259, Index = 4, Sid = 305
May 6 05:18:44 epsilon vdr: [30688] Deleting, pmtPid 261, pmtIndex = 5,
lastPmtScan = 0
May 6 05:18:44 epsilon vdr: [30688] Adding, pmtPid 264, Index = 7, Sid = 4417
May 6 05:18:44 epsilon vdr: [30685] Deleting, pmtPid 259, pmtIndex = 3,
lastPmtScan = 0
May 6 05:18:44 epsilon vdr: [30685] Adding, pmtPid 261, Index = 5, Sid = 353
May 6 05:18:44 epsilon vdr: [30682] Deleting, pmtPid 259, pmtIndex = 6,
lastPmtScan = 0
May 6 05:18:44 epsilon vdr: [30685] Deleting, pmtPid 261, pmtIndex = 4,
lastPmtScan = 0
May 6 05:18:44 epsilon vdr: [30685] Adding, pmtPid 262, Index = 6, Sid = 385
May 6 05:18:44 epsilon vdr: [30679] Deleting, pmtPid 1145, pmtIndex = 9,
lastPmtScan = 0
May 6 05:18:44 epsilon vdr: [30679] Adding, pmtPid 1146, Index = 11, Sid =
1520
May 6 05:18:44 epsilon vdr: [30688] Deleting, pmtPid 264, pmtIndex = 6,
lastPmtScan = 0
May 6 05:18:44 epsilon vdr: [30688] Adding, pmtPid 266, Index = 8, Sid = 4481
May 6 05:18:44 epsilon vdr: [30682] Adding, pmtPid 258, Index = 1, Sid = 65
May 6 05:18:44 epsilon vdr: [30685] Deleting, pmtPid 262, pmtIndex = 5,
lastPmtScan = 0
May 6 05:18:44 epsilon vdr: [30685] Adding, pmtPid 263, Index = 7, Sid = 369
May 6 05:18:44 epsilon vdr: [30688] Deleting, pmtPid 266, pmtIndex = 7,
lastPmtScan = 0
May 6 05:18:44 epsilon vdr: [30688] Adding, pmtPid 265, Index = 9, Sid = 4433
May 6 05:18:44 epsilon vdr: [30685] Deleting, pmtPid 263, pmtIndex = 6,
lastPmtScan = 0
May 6 05:18:44 epsilon vdr: [30685] Adding, pmtPid 260, Index = 8, Sid = 337
May 6 05:18:44 epsilon vdr: [30688] Deleting, pmtPid 265, pmtIndex = 8,
lastPmtScan = 0
May 6 05:18:44 epsilon vdr: [30688] Adding, pmtPid 263, Index = 10, Sid =
4401
May 6 05:18:44 epsilon vdr: [30679] Deleting, pmtPid 1146, pmtIndex = 10,
lastPmtScan = 0
--
Anssi Hannula
Index: vdr-1.6.0-sechand/pat.c
===
--- vdr-1.6.0-sechand/pat.c
+++ vdr-1.6.0-sechand/pat.c 2008-05-06 05:08:48.0 +0300
@@ -276,6 +276,7 @@
if (Pid == 0x00) {
if (Tid == 0x00) {
if (pmtPid time(NULL) - lastPmtScan PMT_SCAN_TIMEOUT) {
+ dsyslog(Deleting, pmtPid %d, pmtIndex = %d, lastPmtScan = %lu,
pmtPid, pmtIndex, lastPmtScan);
Del(pmtPid, 0x02);
pmtPid = 0;
pmtIndex++;
@@ -292,6 +293,7 @@
if (Index++ = pmtIndex Channels.GetByServiceID(Source(),
Transponder(), assoc.getServiceId())) {
pmtPid = assoc.getPid();
pmtSid = assoc.getServiceId();
+ dsyslog(Adding, pmtPid %d, Index = %d, Sid = %d,
pmtPid, Index, pmtSid);
Add(pmtPid, 0x02);
break;
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Switching recording files
Otto J. Makela wrote: Fedora 8, vdr-1.4.7-6.fc8 and old full-feature Terratec C-card. I've configured vdr to start two minutes before the time of the program, and ten minutes after the recording, in case timing is a bit off. For some reason, when recording the Finnish National broadcaster's (YLE) programs, vdr every time wants to switch files just before the actual program starts. Unfortunately it fails and ends up doing it just slightly too late, causing a few frames of the program to end up at the tail of the two-minute preamble. Quite inconvenient from an editing point of view. What causes this (does YLE send a the-program-starts-now type of signaling?), I haven't found a way to disable this in spite of going through the configuration files? The audio/subtitle pids are updated when a program changes, and that causes VDR to re-tune and switch recording file. I'm not sure if VDR is intelligent enough to not re-tune if only the descriptions change. I guess one could also implement it in a way so that re-tune/fileswitch are not needed. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Watching old recordings with DVB subtitles with 1.6.0
Petri Helin wrote:
Rolf Ahrenberg wrote:
On Sat, 12 Apr 2008, Ville Skyttä wrote:
After figuring out how to access the subtitles menu (my remote.conf was from
1.4.x series so there was no button binding for it), yes, I do see an entry
named 57 there. Selecting it gives me the Finnish subtitles I was looking
for. Thanks for the tip.
You could also map 57 to fin in info.vdr of all those old recordings
and afterwards VDR automatically selects subtitles according to
preferred languages.
Is 57 dependent on the in subtitling language, or is it constant for
all old recordings?
It is constant. 57 is for the first subtitle track, 58 for the second.
If it is constant, could VDR be patched easily to
select 57 in case preferred subtitles are not found?
Yes. Patch attached.
--
Anssi Hannula
Index: vdr-1.6.0-57/device.c
===
--- vdr-1.6.0-57/device.c
+++ vdr-1.6.0-57/device.c 2008-05-04 18:33:18.0 +0300
@@ -1100,7 +1100,9 @@
int LanguagePreference = INT_MAX; // higher than the maximum possible
value
for (int i = ttSubtitleFirst; i = ttSubtitleLast; i++) {
const tTrackId *TrackId = GetTrack(eTrackType(i));
- if (TrackId TrackId-id
I18nIsPreferredLanguage(Setup.SubtitleLanguages, TrackId-language,
LanguagePreference))
+ // Fall back to languageless ttSubtitleFirst+8 track created by old
subtitles patch if present
+ if (TrackId TrackId-id
(I18nIsPreferredLanguage(Setup.SubtitleLanguages, TrackId-language,
LanguagePreference)
+ || ((i == ttSubtitleFirst + 8) !(*TrackId-language)
LanguagePreference == INT_MAX)))
PreferredTrack = eTrackType(i);
}
// Make sure we're set to an available subtitle track:
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE]: osdpip-0.0.9
Andreas Regel wrote: Hi, there is a new version of the osdpip plugin available: http://home.arcor.de/andreas.regel/files/vdr-osdpip-0.0.9.tgz Thanks. BTW, the Latest version available at in README has not been changed and points to the original site, that still has 0.0.8. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] what is cDevice::Receiving() supposed to return?
Andreas Holzhammer - GMX wrote: Hi, Hi! I'm trying to track down a problem with lnbsharing and software decoding, and am stuck at understanding what cDevice::Receiving should actually return. I have two budget dvb-s cards, and use softdevice for output. The patch runs i through 0...numDevices and queries device[i]-Receiving(). But for all 3 devices the call to Receiving() returns 0? Shouldn't at least one of the devices receive the currently viewed channel? vdr tuned to channel 1, channelswitch to channel 2: Apr 24 21:18:02 (none) user.err vdr: [15119] GMBP channel 2 device 0 LNB 1 LNBstate 1 can provide channel 1 prio -1 receiving 0 Apr 24 21:18:02 (none) user.err vdr: [15119] GMBP channel 2 device 1 LNB 1 LNBstate 1 can provide channel 1 prio -1 receiving 0 Apr 24 21:18:02 (none) user.err vdr: [15119] GMBP channel 2 device 2 LNB 1 LNBstate 1 can provide channel 0 prio -1 receiving 0 What is the call to Receiving supposed to return? If it's always returning 0 I have an idea why lnbsharing doesn't work for me :-) I don't know about lnbshare, but Receiving() (without parameter) returns true if there are any receivers on that device with a priority 0 or higher. The live view using transfer mode is using priority -1, so it does not show up. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Hearing-impaired DVB subtitles
Klaus Schmidinger wrote: On 03/09/08 22:09, Kimmo Taskinen wrote: [...] changing pids of channel 8 from 514+514:670=eng:0:2321 to 514+514:670=eng:3028=sve,3027=fin:2321 and info.vdr: C C-0-1-5 YLE FST5 E 471 1205093700 3419 4E 10 T Jools Holland show S Brittiläistä musiikkiviihdettä. Illan vieraat: Arctic Monkeys, CSS, Bryan Ferry, Tinariwen, Henri Salvadore, The Hold Steady. Tuotanto: BBC, 3DD ja Baker Street. X 1 04 fin X 3 11 fin X 3 11 sve X 2 03 eng [...] In the PID settings they have the first audio PID set to sve and the second one to fin, while in the EPG data it's the other way round. In live mode the PID data is used when selecting the audio track, while in replay mode the EPG data takes precedence. s/audio/subtitle/ I guess ;) Hmm, so you are relying on the ordering of component descriptors in event info (AFAICS there is no PID or composition page id there). Are you sure the standard mandates them to be in some specific order? Didn't find any mention of that with a quick look. I just wonder why Petri Helin (see his recent posting in this thread) gets correct behavior. From what I gather from his post, it seems like he has the subtitle streams in different order in the PMT. Maybe he is using a different provider (DVB-C vs. DVB-T or different cable network). -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DXR3 and subtitles in 1.5.x
Luca Olivetti wrote: En/na Sami Sundell ha escrit: On Tue, Mar 04, 2008 at 10:55:53PM +0200, Sami Sundell wrote: E-tobi's experimental VDR branch moved to 1.5.x series, so I did too, but I'm running into some problems. Specifically, this one: ... Some version information might be good, too. VDR 1.5.17, dxr3 plugin 0.2.7, em8300 driver 0.16.4. Two DVB-C budget cards (Terratec 1200), but I guess it doesn't matter in this case. Try the cvs version (I don't remember if the changes for dvb subtitles were in 0.2.7 or are posterior, in any case dvb subtitles work fine here). The dvb subtitle changes are not in 0.2.7, but only in CVS. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR on OpenWRT / embedded system
Jan Willies wrote: Artem Makhutov wrote: has anybody thought of running VDR on OpenWRT? Yes, I think it is possible. I once tried packaging VDR for openwrt but gave eventually up. There are some uClibc patches for VDR floating around, if you are interested I can get you the links. But first you should probably start packaging the dependencies like libcap for example. libcap is not essential for VDR operation, so you could just modify VDR to not use it. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR developer version 1.5.16 - Makefile
[EMAIL PROTECTED] wrote: Hi there, First time i'm using the Makefile to install vdr. Why is it : install-i18n: @mkdir -p $(DESTDIR)$(LOCDIR) @(cd $(LOCALEDIR); cp -r --parents * $(DESTDIR)$(LOCDIR)) and install-plugins: plugins @mkdir -p $(DESTDIR)$(PLUGINLIBDIR) @cp --remove-destination $(PLUGINDIR)/lib/lib*-*.so.$(APIVERSION) $(DESTDIR)$(PLUGINLIBDIR) with DESTDIR ?= PREFIX ?= /usr/local MANDIR = $(PREFIX)/share/man BINDIR = $(PREFIX)/bin LOCDIR = ./locale being the default ? is there a $(PREFIX) missing after $(DESTDIR) in install-i18n and install-plugins ? No. What is the problem, exactly? -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR + FF card under x11.
Jean-Claude Repetto wrote: Albert Gall a écrit : VDR + FF card works under x11 without requiring any plug mpeg decoder ? Yes, just use a V4L application such as xawtv or tvtime to display /dev/dvb/adapter0/dvr0 . You probably meant /dev/video0 :) -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] improved LIRC remote for VDR-1.5.12
Klaus Schmidinger wrote: On 01/09/08 00:44, Reinhard Nissl wrote: #vdr REMOTE=LIRC LIRC_PUSHFREQ=64 # 1/s LIRC_REPEATDELAY=250 # ms LIRC_REPEATFREQ=32 # 1/s #LIRC_REPEATTIMEOUT=500 # ms #LIRC_RECONNECTDELAY=3000 # ms LIRC_PRIORITYBOOST=1 Isn't there a way to have all this done in LIRC itself? I can hardly imagine that all other applications using LIRC do such elaborate parameter fiddling, too. I think most other applications use the lirc library instead of directly parsing the commands. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Fast-forward and subtitles
Klaus Schmidinger wrote: On 11/08/07 23:32, Petri Helin wrote: Hi, Besides DVB subtitle support, version 1.5.10 brought also support for nicer fast forward implementation. From the HISTORY file: - Implemented sending all frames to devices that can handle them in fast forward trick speeds (thansk to Timo Eskola). If I recall correctly, the original patch by Timo Eskola together with the subtitles plugin allowed also subtitles to be shown during fast forward. This nice functionality is missing from the current implementation. So, just to let you know... :) There is no audio during fast forward, so why bother displaying subtitles? Because subtitles can still be read at high speeds, while audio becomes very incomprehensible quite quickly? -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD-TV hardware decoding on motherboard instead of waiting for FF DVB-S2 card
Darren Salt wrote: I demand that Ondrej Wisniewski may or may not have written... With VDR getting ready for HD-TV it seems that today the MPEG4 decoding can only be done on a high end processor or an external decoder card. MPEG-4 (or, more specifically, H.264) != HDTV. Sooner or later, it'll be used for 576p or 576i, if it's not being used for that already somewhere. According to wikipedia, it is: http://en.wikipedia.org/wiki/H264#Applications -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Straw poll: stable version 1.6.0 now?
Klaus Schmidinger wrote: There has been some controversy about my recent decision to move forward and require the multiproto driver for VDR in the developer version. It is also currently rather unclear whether the current PES recording format can be kept to handle HDTV, or whether it would make sense (or even be feasible) to switch to TS (as suggested by the people from RMM). I favor TS due to the greater support by other applications. [...] So, here's the straw poll: 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? Yes or No? No, mostly due to the missing teletext subtitling support. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] no channel 0 in svdrp
Thomas Schmidt wrote: Hi, * Marcel Witte schrieb am 02.01.08, um 19:39 Uhr: why doesn't svdrp support a channel 0 like real vdr? If I press 0 on my remote, I can return to my last channel, but if I try svdrpsend.pl chan 0 I get only 501 Undefined channel 0 Is it possible to add this functionality to svdrp? I guess you should just try the hitk 0 command instead of channel 0. ;-) Probably better: hitk prevchannel -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] avoid inheritance of file descriptors
Deti Fliegl wrote: Klaus Schmidinger wrote: Doesn't SystemExec() (see tools.c) take care of this? Yes you are right - it takes care internally but not for plugins like dvdswitch etc. In order to fix this problem you could patch every single plugin or just set the right file descriptor flag once. I think the latter does not cause any interference and should solves some issues. For the record, the latter creates a small race condition: an external program could be launched before FD_CLOEXEC is set on an fd. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] multiple frontends - [was: HDTV - 2B or not 2B]
[EMAIL PROTECTED] wrote: Alasdair Campbell [EMAIL PROTECTED] writes: Beside all that, I do believe VDR needs to integrate H264 HD recording, along with support built-in for multiple frontends. Hopefully I can lend a hand with the coding (in about 6 years). I'd be happy to do some clean C++ programming (I've haven't done C/C++ for YEARS). But I don't know where to start. Do you think it would be achievable without breaking everything, or would it need to nearly start from scratch ? (so it would be modular enough to smartly handle every needs) Well, quite big changes would have to made. A network interface should be added between backend/frontend, so that a VDR client could connect into a VDR server, and use its data directly (caching implemented where desired), i.e. for EPG, recordings, timers, etc. Quite a bit of work would be needed for that separation. This is further complicated by the need of having to use DVB cards which are located in hosts running separate VDR instances, possibly requiring defining one VDR instance as a master backend server, which handles allocating the devices on different hosts, etc. For a start, I would be happy to know if it is something feasible for vdr 1.5. (and how the difficulty would be) -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PANIC: watchdog timer expired - exiting
Ville Skyttä wrote: On Sunday 02 December 2007, Darren Salt wrote: I demand that Klaus Schmidinger may or may not have written... On 12/02/07 14:34, Darren Salt wrote: I demand that Klaus Schmidinger may or may not have written... I'll make it a 5 ms limit then, to allow default kernels to work. Valid HZ options are 100, 250, 300 and 1000, unless overridden by an arch-specific Kconfig file. (AFAICS, only mips does this, offering 48, 100, 128, 250, 256, 1000 and 1024.) Not that I really know much at all about this, but how would this change behave with NOHZ kernels? Apparently resolution is reported as 1 ns regardless of HZ when NO_HZ is used: $ ./hz cTimeMs: using monotonic clock (resolution is 1 ns) $ zcat /proc/config.gz | grep _HZ= CONFIG_NO_HZ=y CONFIG_HZ=100 -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.8.0 plugin
Reinhard Nissl wrote: Hi, Jörg Knitter schrieb: I'm currently using xineliboutput for my other client (on a standard PC), so this would be my first choice, but I've no problem to switch back to vdr-xine (which I used in the past - with the network patch... I moved to xineliboutput just because I don't want to patch xine-lib everytime anymore..) A nice feature that vdr-xine has over xineliboutput, is that it automatically sets itself as the primary device when a connection comes, and when the connection is closed it restores the previous primary device. This way I can either watch locally with the dxr3-plugin or remotely with vdr-xine. I experienced the same with xineliboutput. A very interesing feature of xinelibout is the ability to control deinterlacing, color settings etc. from within the VDR OSD in the plug-in´s settings. Furthermore, xineliboutput has a function that cuts and scales letterboxed 16:3 to anamorph 16:9, there is an audio equalizer and much more... Well, that's the cleaner approach of suppling an own frontend. I didn't want to write an own frontend. But my xine plugin has to act like a frontend within any other frontend and therefore requires some xine-lib patches to prevent deadlocks. I may have misunderstood what you meant with frontends, but xineliboutput *can* be used with other xine frontends, such as xine-ui, without patching xine-lib. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Convert video clip to .vdr format
Dick Streefland wrote: VDR User [EMAIL PROTECTED] wrote: | I think a better idea is to just install a codec that plays whatever | format your camera videos are in and use the mplayer plugin. But I have a rather underpowered VDR machine with a full-featured DVB-S card, so I really need to use the hardware MPEG decoder. Mplayer can play MPEG files using the hardware MPEG decoder without re-encoding. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.9 and ttxtsubs patch/plugin
Klaus Schmidinger wrote: On 09/04/07 23:45, Luca Olivetti wrote: En/na Klaus Schmidinger ha escrit: I haven't looked into the code of the ttxt subtitle plugin, yet, but currently my idea is to convert the ttxt subtitles into DVB subtitles, so that VDR only needs to handle one type of subtitiles for recording and live viewing. Aren't dvb subtitles just bitmaps? If so, converting the text to a bitmap for recording doesn't seem a good idea to me. Well, in the end they would have to be displayed as bitmaps, anyway. Besides, the DVB subtitle specs also provide a means of having character strings instead of bitmaps. I'm not sure yet how it's going to be, but I'm certainly not going to have two (or three, with Closed Captioning) different subtitling methods throughout VDR. There's _one_ mechanism, based on ETS 300 743, and anything else will be converted to this as early as possible. I don't think converting text to bitmaps is a good idea, you'll lose the ability to format the text at your will, and the ability to export them as .srt or .sub files. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to set German OSD in VDR 1.5.8
Matthias Fechner wrote: Hello Anssi, * Anssi Hannula [EMAIL PROTECTED] [22-08-07 16:33]: Could you try what these commands print in VDR source directory: TEXTDOMAINDIR=./locale TEXTDOMAIN=vdr LANGUAGE=de_DE gettext -s \ 'LanguageName$English' LanguageName$English TEXTDOMAINDIR=./locale TEXTDOMAIN=vdr LANGUAGE=de gettext -s \ 'LanguageName$English' LanguageName$English TEXTDOMAINDIR=./locale TEXTDOMAIN=vdr LANGUAGE=de_XYZ gettext -s \ 'LanguageName$English' LanguageName$English Gettext is version 0.16.1 Same here, so that is not it. Does locale/de_DE/LC_MESSAGES/vdr.mo exist in VDR directory? What distro? Does the localization work in other programs, like ls --help and so on? -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [SOLVED] Re: How to set German OSD in VDR 1.5.8
Matthias Fechner wrote: Hi Klaus, Klaus Schmidinger wrote: I don't really want anything in particular here ;-) :) All I want is that the gettext() calls deliver the right texts. my it is some your your ToDo list. - Fix the problem that a user cannot select a language in VDR if no LANG is defined on the shell - or put a node in the INSTALL file that LANG must be defined in the shell before starting VDR AFAICS that is only needed if the user locale settings are set to C, POSIX or invalid values. This behaviour was added to glibc in 2001, likely to fix something else. http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/intl/dcigettext.c.diff?r1=1.22r2=1.23cvsroot=glibcf=h I've contacted the committer about our issue. If I get no reply, I'll raise it in libc-alpha ml. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to set German OSD in VDR 1.5.8
Matthias Fechner wrote: Hi Luca, Luca Olivetti wrote: That shouldn't be necessary with 1.5.8: I only have 3 locales installed but I can select all languages from the osd setup menu (and see the corresponding translations). hm, that is strange. I have here a vanilla VDR (with some plugins but the sourcecode of VDR is not touched) I compiled it with: make REMOTE=LIRC VFAT=1 NO_KBD=1 But I am not able to select different languages in the menu. Could you try what these commands print in VDR source directory: TEXTDOMAINDIR=./locale TEXTDOMAIN=vdr LANGUAGE=de_DE gettext -s \ 'LanguageName$English' TEXTDOMAINDIR=./locale TEXTDOMAIN=vdr LANGUAGE=de gettext -s \ 'LanguageName$English' TEXTDOMAINDIR=./locale TEXTDOMAIN=vdr LANGUAGE=de_XYZ gettext -s \ 'LanguageName$English' -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
Udo Richter wrote: Klaus Schmidinger wrote: VDR's locale files are named like de_DE (language_COUNTRY). There's no @euro or other stuff added to the names. VDR needs to know which files it actually has at its disposal, in order to present to the user a list of all available languages. It makes no sense to present a language that in the end isn't available. I guess the working way would be to parse (or build) the list of locale -a, as they are definitely the present locales, and then check which one of them matches a VDR translation file. In my case, [EMAIL PROTECTED] uses the existing translation de_DE as fallback, and would be a valid selection. Such a solution still has obstacles, like multiple possible locales for one real translation, and things like 'C' locale for English. Well, AFAIK it doesn't matter which one of the multiple possible locales you select, it won't affect the translation, so this is not a problem :) And for the C locale, I don't see the problem. Actually, I18N_DEFAULT_LOCALE should be C, as en_US is invalid in many systems. Dunno if en_US causes problems somewhere, but it might. AFAICS the solutions to the current problems would be: (1) Put all VDR translation *.mo files in $LOCDIR/xx/LC_MESSAGES, where xx is the language code without territory et al. LOCDIR can be whatever, /usr/share/locale, ~/vdr/locale etc. (2) Check all the directories in $LOCDIR for vdr.mo. (3) (a) Build a list of possible system locales by listing the system locale dir (could be /usr/share/locale, /usr/lib/locale, /usr/lib64/locale, depending on system; note that /usr/share/locale may still contain the translations and they are used even if it is not the system localedir). or (b) Build a list of system locales by running locale -a. or (c) Hardcode a list of locale names to be tried. (4) Of the listed locales, select one that matches xx*, with xx being the language code of the VDR translation. If (3a) or (3c) was used, we need to test if they really work, as not all subdirs in those dirs are valid locales. (5) Use iso-codes as pointed out by Wolfgang for the language name translations. I also sent a message to gettext developers about the issue. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
Klaus Schmidinger wrote: On 08/19/07 10:46, Anssi Hannula wrote: Udo Richter wrote: Klaus Schmidinger wrote: VDR's locale files are named like de_DE (language_COUNTRY). There's no @euro or other stuff added to the names. VDR needs to know which files it actually has at its disposal, in order to present to the user a list of all available languages. It makes no sense to present a language that in the end isn't available. I guess the working way would be to parse (or build) the list of locale -a, as they are definitely the present locales, and then check which one of them matches a VDR translation file. In my case, [EMAIL PROTECTED] uses the existing translation de_DE as fallback, and would be a valid selection. Such a solution still has obstacles, like multiple possible locales for one real translation, and things like 'C' locale for English. Well, AFAIK it doesn't matter which one of the multiple possible locales you select, it won't affect the translation, so this is not a problem :) And for the C locale, I don't see the problem. Actually, I18N_DEFAULT_LOCALE should be C, as en_US is invalid in many systems. Dunno if en_US causes problems somewhere, but it might. AFAICS the solutions to the current problems would be: (1) Put all VDR translation *.mo files in $LOCDIR/xx/LC_MESSAGES, where xx is the language code without territory et al. LOCDIR can be whatever, /usr/share/locale, ~/vdr/locale etc. (2) Check all the directories in $LOCDIR for vdr.mo. (3) (a) Build a list of possible system locales by listing the system locale dir (could be /usr/share/locale, /usr/lib/locale, /usr/lib64/locale, depending on system; note that /usr/share/locale may still contain the translations and they are used even if it is not the system localedir). or (b) Build a list of system locales by running locale -a. or (c) Hardcode a list of locale names to be tried. (4) Of the listed locales, select one that matches xx*, with xx being the language code of the VDR translation. If (3a) or (3c) was used, we need to test if they really work, as not all subdirs in those dirs are valid locales. (5) Use iso-codes as pointed out by Wolfgang for the language name translations. I also sent a message to gettext developers about the issue. From everything I've read in this (unfortunately badly subjected) thread I can only come to one conclusion: setlocale/gettext is *broken*! I can't believe that every program would have to fiddle around with all these different directory localtions and stuff. As much as I like Linux, but I hate the fact that every distribution has its files somewhere else. Couldn't there for once be a *standard*? As said multiple times before, the other programs *do not use* setlocale() to switch languages nor list languages, but rely on environment variables. That is why they do not need to do anything, and thus have not faced this problem. Note that KDE does provide the user a list of languages, but it does not use gettext, but instead uses its own glibc-derived implementation for translation, with file format being the same. And why isn't setlocale() smart enough to try de when the program requests de_DE and there is no de_DE lcoale? It would be the reasonable thing to do, wouldn't it? I think the reverse would be more useful here, i.e. not smart enough to try de_DE when de is called for. I was hoping to make things simpler and easier when going to gettext, but now it looks like I've traded one nightmare for another. Yes. Isn't there perhaps a way to tell gettext *explicitly* which files to use, completely bypassing this whole broken setlocale stuff? In that case VDR could collect it's list of *.mo files and decide by itself which one to use. I'm not aware of such a way. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
Luca Olivetti wrote: En/na Anssi Hannula ha escrit: Note that KDE does provide the user a list of languages, but it does not use gettext, but instead uses its own glibc-derived implementation for translation, with file format being the same. [...] Isn't there perhaps a way to tell gettext *explicitly* which files to use, completely bypassing this whole broken setlocale stuff? In that case VDR could collect it's list of *.mo files and decide by itself which one to use. I'm not aware of such a way. I think that in your message there's the solution: do *not* use gettext but use an own implementation. Maybe borrowing kde implementation (which is already C++) it's easier than translating the pascal class I proposed before (or maybe not ;-). Actually, it seems KDE 4 uses real gettext to do it, and uses the following code: // Point Gettext to new language. setenv(LANGUAGE, language, 1); // Locale directories may differ for different languages of same catalog. bindtextdomain(name, localeDir); Maybe just using 'setenv(LANGUAGE, de, 1);' will do what we want, without need for setlocale()? :) I have to go now so I can't check that yet. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
Anssi Hannula wrote: Luca Olivetti wrote: En/na Anssi Hannula ha escrit: Note that KDE does provide the user a list of languages, but it does not use gettext, but instead uses its own glibc-derived implementation for translation, with file format being the same. [...] Isn't there perhaps a way to tell gettext *explicitly* which files to use, completely bypassing this whole broken setlocale stuff? In that case VDR could collect it's list of *.mo files and decide by itself which one to use. I'm not aware of such a way. I think that in your message there's the solution: do *not* use gettext but use an own implementation. Maybe borrowing kde implementation (which is already C++) it's easier than translating the pascal class I proposed before (or maybe not ;-). Actually, it seems KDE 4 uses real gettext to do it, and uses the following code: // Point Gettext to new language. setenv(LANGUAGE, language, 1); // Locale directories may differ for different languages of same catalog. bindtextdomain(name, localeDir); Maybe just using 'setenv(LANGUAGE, de, 1);' will do what we want, without need for setlocale()? :) I have to go now so I can't check that yet. I tested anyway ;) It seems that it *does* work, i.e. LANGUAGE=de, LANGUAGE=fr, LANGUAGE=fi will work even if there is no such locale at all. I copied a .mo file into /usr/share/locale/testtest/LC_MESSAGES/, which certainly is not a valid locale, and using LANGUAGE=testtest it was correctly used! :) -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] locale names, patch for large localedirs
Hi!
Very nice to see gettext() working, for a while I thought it was going
to be a complete mess :)
IMHO, two simple things could still be done:
Attached is a simple patch that allows using VDR with large localedir
that contains more locales than I18N_MAX_LANGUAGES. AFAICS there is no
reason to stop searching unless I18N_MAX_LANGUAGES vdr locales were
actually found.
Also, it is a convention (all programs in my system follow it) that .po
files (and thus the locale directory name) be without the territory
name, i.e. fi instead of fi_FI. If there would be any additional
translations for some language, they would be named like fi_DE.
--
Anssi Hannula
Index: vdr-1.5.8/i18n.c
===
--- vdr-1.5.8/i18n.c
+++ vdr-1.5.8/i18n.c 2007-08-19 18:38:54.0 +0300
@@ -112,7 +112,7 @@
for (int i = 0; i Locales.Size(); i++) {
cString FileName = cString::sprintf(%s/%s/LC_MESSAGES/vdr.mo, I18nLocaleDir, Locales[i]);
if (access(FileName, F_OK) == 0) { // found a locale with VDR texts
-if (i I18N_MAX_LANGUAGES - 1) {
+if (NumLocales I18N_MAX_LANGUAGES) {
SetEnvLanguage(Locales[i]);
NumLocales++;
if (strstr(OldLocale, Locales[i]) == OldLocale)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.7-1.5.8.diff problems?
Klaus Schmidinger wrote: On 08/19/07 18:07, Anssi Hannula wrote: Udo Richter wrote: 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 files will have lots of changed line numbers. Maybe they should not be regenerated during compiling, but have a separate make target for that? Like this? i18n: $(I18Nmo) @mkdir -p $(LOCALEDIR) for i in $(I18Ndirs); do\ mkdir -p $(LOCALEDIR)/$$i/LC_MESSAGES;\ cp $(PODIR)/$$i.mo $(LOCALEDIR)/$$i/LC_MESSAGES/vdr.mo;\ done ;-) Not really. I mean't a separate target for running xgettext and msgmerge, as they are only needed to be run by developers, and cause patch conflicts as Udo noted. Only msgfmt and the copying of the files needs to be done when the user compiles VDR. I checked few other random projects, and they use a make target update-po for running xgettext and msgmerge, which is not done by default. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Locales not working by default when running from source tree
Before one could just run make and after that you could just run ./vdr. However, now LOCDIR is set to $(PREFIX)/share/vdr/locale by default, which causes localisation to not work unless make install-i18n (or make install which runs it as well) is run, which copies the locale files to LOCDIR. However, almost exactly the opposite is the case with PLUGINLIBDIR, which by default is ./PLUGINS/lib so that it works inside the source-tree, but it is not so good if installed into /usr/local. AFAICS this is inconsistent. I think either VDR should work out-of-the-box (without modifying make variables) inside the source tree *or* out of the source tree. I.e. LOCDIR should be changed to ./locale or PLUGINLIBDIR should be changed $(PREFIX)/lib/vdr or similar. Or make the i18n.c work with locales being either in LOCDIR or ./locale. It doesn't really matter to me, but for some other users the current state might be confusing. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
Klaus Schmidinger wrote: On 08/17/07 15:48, Anssi Hannula wrote: Klaus Schmidinger wrote: - Internationalization is now done with 'gettext' (following a suggestion by Lucian Muresan). Plugin authors may want to use the Perl script 'i18n-to-gettext.pl' to convert their internationalized texts to the gettext format (see the instructions inside that script file). The function cPlugin::RegisterI18n() is still present for compatibility, but doesn't have any more functionality. So plugins that don't convert their texts to the gettext format will only present English texts. See PLUGINS.html, section Internationalization, for instructions on how to make strings in arrays translatable. See README.i18n for information on how to create new or maintain existing translations. I have only Finnish locales installed (locale -a), so only the selections suomi and English work from the plugin menu. The rest What plugin menu? OSD language selection in the setup menu ;) show up as deu,ger etc, and do not work; text shows up in English despite selecting them. Maybe the locales that the user does not have installed on their system should be hidden? I thought that the language codes should always all be there, to allow selecting other preferred languages, even if there is no locale installed. But maybe I'm mistaken there. Well, having those in the OSD language selection menu seems strange, if only two of those actually work, and others do not show up correctly (deu,ger). But indeed, the Audio and EPG language selection menus seem to use the same list. IMHO the Audio and EPG languages should use a separate list, that contains all the language names in the currently selected OSD language. Please try disabling the code after // Prepare any known language codes for which there was no locale: in i18n.c and see whether that would do what you expect. Yes, the languages that have no locales-XX package installed on my system do not show up in the OSD language selection list anymore. However, I cannot select them as EPG nor Audio language either, which should still be possible. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] localedir, plugin text domain names
I believe distribution packagers of VDR (at least myself) will want to
install the VDR locale files into the standard directory under
/usr/share/locale/, where all other locale files are.
However, as that directory may contain lots of other locales that do not
have translation for VDR (or possibly only for some plugin of VDR, which
applies to a custom localedir as well), those show up in the OSD
Language selection menu as LanguageName$English.
Also, it could also be possible that the I18N_MAX_LANGUAGES = 256
constant could be too small for some systems. I guess it could be
modified to limit only the locales that have VDR translation, not the
total locale count in the system.
+void I18nRegister(const char *Plugin)
+{
+ bindtextdomain(Plugin, I18nLocaleDir);
+}
[...]
+ if (Plugin)
+t = dgettext(Plugin, s);
Maybe it would be better to use something like vdr-PLUGIN or
vdr-plugin-PLUGIN?
If the translations are installed into /usr/share/locale, the files of
VDR plugins could conflict with other programs that have the same name,
if the plugin translation files are not prefixed by anything.
--
Anssi Hannula
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] localedir, plugin text domain names
Klaus Schmidinger wrote:
On 08/18/07 11:11, Anssi Hannula wrote:
I believe distribution packagers of VDR (at least myself) will want to
install the VDR locale files into the standard directory under
/usr/share/locale/, where all other locale files are.
However, as that directory may contain lots of other locales that do not
have translation for VDR (or possibly only for some plugin of VDR, which
applies to a custom localedir as well), those show up in the OSD
Language selection menu as LanguageName$English.
Also, it could also be possible that the I18N_MAX_LANGUAGES = 256
constant could be too small for some systems. I guess it could be
modified to limit only the locales that have VDR translation, not the
total locale count in the system.
+void I18nRegister(const char *Plugin)
+{
+ bindtextdomain(Plugin, I18nLocaleDir);
+}
[...]
+ if (Plugin)
+t = dgettext(Plugin, s);
Maybe it would be better to use something like vdr-PLUGIN or
vdr-plugin-PLUGIN?
If the translations are installed into /usr/share/locale, the files of
VDR plugins could conflict with other programs that have the same name,
if the plugin translation files are not prefixed by anything.
Why do you want to make things overly complicated?
Can't we just keep it simple?
Keeping it simple would be dropping the language selection completely
and using environment, as other applications do. But I guess you do not
want do that.
But you mean, use a specific directory for VDR locales, like
/usr/share/vdr/locale?
If you do not wish to use the standard location, fine with me. However,
the LanguageName$English problem still applies, if there is some
directory in the VDR localedir that does not have a VDR translation, but
e.g. only for some plugin.
--
Anssi Hannula
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
Klaus Schmidinger wrote: On 08/18/07 11:38, Anssi Hannula wrote: Klaus Schmidinger wrote: On 08/18/07 10:32, Anssi Hannula wrote: Klaus Schmidinger wrote: On 08/17/07 15:48, Anssi Hannula wrote: ... show up as deu,ger etc, and do not work; text shows up in English despite selecting them. Maybe the locales that the user does not have installed on their system should be hidden? I thought that the language codes should always all be there, to allow selecting other preferred languages, even if there is no locale installed. But maybe I'm mistaken there. Well, having those in the OSD language selection menu seems strange, if only two of those actually work, and others do not show up correctly (deu,ger). But indeed, the Audio and EPG language selection menus seem to use the same list. IMHO the Audio and EPG languages should use a separate list, that contains all the language names in the currently selected OSD language. That would mean that every *.po file would have to contain the name of every other language, and for every new language that's added, all other *.po files would have to be extended. Then they will be extended, I don't see the problem here. Besides, if a user can't read a language name in the language's own writing, he/she probably won't understand that langauge, anyway ;-). A good point. :) However, most languages are currently shown as language codes, not in the language's own writing. Where should that language's own writing come from, if not from a *.mo file for that language? A custom table? (If you do not want to start translating the language names to all languages) Abusing setlocale() and gettext() to grab a language name from other *.mo files seems wrong to me. Please try disabling the code after // Prepare any known language codes for which there was no locale: in i18n.c and see whether that would do what you expect. Yes, the languages that have no locales-XX package installed on my system do not show up in the OSD language selection list anymore. However, I cannot select them as EPG nor Audio language either, which should still be possible. Please try the attached patch. It changes the Setup/OSD/Language menu to only show the languages that actually have a locale. Any other language menus display language names if present, three letter language codes otherwise. Seems to work. However, I don't like the fact that only few languages are shown by their name, while others have only the language codes. Before they were all shown by their name. The *.mo files for VDR's languages are all there - I don't know why setlocale()/gettext() doesn't deliver translations if the locale isn't installed. VDR searches its locale directory for any locales that come with VDR, and calls setlocale() with them. If gettext() then doesn't return any translations, what do you suggest VDR should do? If you want to see all languages, maybe you just have to install all locales? Unreasonable for just the language names. I suggest to use a table. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] localedir, plugin text domain names
Klaus Schmidinger wrote:
On 08/18/07 11:29, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 08/18/07 11:11, Anssi Hannula wrote:
I believe distribution packagers of VDR (at least myself) will want to
install the VDR locale files into the standard directory under
/usr/share/locale/, where all other locale files are.
However, as that directory may contain lots of other locales that do not
have translation for VDR (or possibly only for some plugin of VDR, which
applies to a custom localedir as well), those show up in the OSD
Language selection menu as LanguageName$English.
Also, it could also be possible that the I18N_MAX_LANGUAGES = 256
constant could be too small for some systems. I guess it could be
modified to limit only the locales that have VDR translation, not the
total locale count in the system.
+void I18nRegister(const char *Plugin)
+{
+ bindtextdomain(Plugin, I18nLocaleDir);
+}
[...]
+ if (Plugin)
+t = dgettext(Plugin, s);
Maybe it would be better to use something like vdr-PLUGIN or
vdr-plugin-PLUGIN?
If the translations are installed into /usr/share/locale, the files of
VDR plugins could conflict with other programs that have the same name,
if the plugin translation files are not prefixed by anything.
Why do you want to make things overly complicated?
Can't we just keep it simple?
Keeping it simple would be dropping the language selection completely
and using environment, as other applications do. But I guess you do not
want do that.
VDR allows selecting the OSD language at runtime, so the setting of
the environment is only the default.
But you mean, use a specific directory for VDR locales, like
/usr/share/vdr/locale?
That's how it works at the moment.
If you do not wish to use the standard location, fine with me. However,
the LanguageName$English problem still applies, if there is some
directory in the VDR localedir that does not have a VDR translation, but
e.g. only for some plugin.
What sense does it make to have a translation for a plugin, but
not for VDR itself?
Very little. I guess we could live with that being impossible.
--
Anssi Hannula
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] improving i18n-to-gettext.pl
Klaus Schmidinger wrote: On 08/18/07 13:10, Matthias Schwarzott wrote: On Samstag, 18. August 2007, Klaus Schmidinger wrote: On 08/18/07 12:55, Matthias Schwarzott wrote: On Freitag, 17. August 2007, Klaus Schmidinger wrote: On 08/15/07 15:07, Matthias Schwarzott wrote: On Mittwoch, 15. August 2007, Klaus Schmidinger wrote: This will work, but only if the locale de_AT you set does exist (being in output of locale -a). but it came up with the default English texts. Then I renamed de to de_AT and did the same again, and I got the German texts. I was hoping that gettext would be a little more intelligent and look for - an exact match (de_AT) - a default (de) - any suitable language (de_DE) I think it does this but not doing any suitable language. ... Could you please try the attached patch and see whether this works for you? This should, e.g., select any de* locale in case there is no fully matching one. Not yet tested, but code looks promising. Another way to get list of usable locales is this: Checking the subdirs of /usr/lib/locale/ And then using all, that have associated mo file under vdr's LOCALEDIR. Sadly I don't know if there is a better way than hardcoding that directory. But locale -a command will give the same result - maybe analyzing its code will help (or just calling this external command). Currently VDR has its own directory with all its supported locales. It can quickly collect all locales by going through the entries in that directory. I can even compile my VDR so that it searches for the locales in ./locale inside the source directory. I like the simplicity of this, and wouldn't want to make it any more complex. The directory /usr/lib/locale does NOT contain any translations, but rather a directory for every locale you can set via setlocale. Its meant as a replacement of the setlocale loop. I'm afraid I don't see what you mean. I know that the locale directory doesn't contain translations directly, but rather subdirectories. VDR gathers the names of these subdirectories and does a setlocale() for each of them. Then it tries to get the translation of LanguageName$English in order to build a list of all available languages. How else do you suggest that could be done? I think he meant to traverse the system locales directory to gather the list of potentially valid locales that can be used to call setlocale(). The VDR locale directory names may or may not be valid locale names on the running system. This is what AFAICS locale -a uses (glibc/locale/programs/locale.c). It also checks the existence of the locale identification file and parses locale aliases from locale.alias. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] improving i18n-to-gettext.pl
Matthias Schwarzott wrote: On Samstag, 18. August 2007, Klaus Schmidinger wrote: On 08/18/07 13:10, Matthias Schwarzott wrote: The directory /usr/lib/locale does NOT contain any translations, but rather a directory for every locale you can set via setlocale. Its meant as a replacement of the setlocale loop. I'm afraid I don't see what you mean. I know that the locale directory doesn't contain translations directly, but rather subdirectories. VDR gathers the names of these subdirectories and does a setlocale() for each of them. Then it tries to get the translation of LanguageName$English in order to build a list of all available languages. How else do you suggest that could be done? First: general directory layout: /usr/share/locale/*/LC_MESSAGES/*.mo contains translations the oposite is /usr/lib/locale. This does NOT contain translations (and if you insisit on the difference: nowhere in the subdirs are translations). There are just descriptions of the available locales. There is no /usr/lib/locale on my system. All the files are in /usr/share/locale. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] improving i18n-to-gettext.pl
Matthias Schwarzott wrote: Regarding the english name of the associated language: locale -a -v will not only print the list of locales, but also a lot of detail info. This info should also be available via some API. But searching did not produce any API to query this. nl_langinfo(_NL_IDENTIFICATION_LANGUAGE); nl_langinfo(_NL_IDENTIFICATION_TERRITORY); etc etc But I do not see how these could be used. Some cut out example: # locale -a -v ... locale: de_DE.utf8 directory: /usr/lib/locale/de_DE.utf8 --- title | German locale for Germany source | Free Software Foundation, Inc. address | 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA email | [EMAIL PROTECTED] language | German territory | Germany revision | 1.0 date | 2000-06-24 codeset | UTF-8 locale: en_GB directory: /usr/lib/locale/en_GB --- title | English locale for Britain source | RAP address | Sankt J�rgens Alle 8, DK-1615 K�benhavn V, Danmark contact | Keld Simonsen email | [EMAIL PROTECTED] language | English territory | Great Britain revision | 1.0 date | 2000-06-28 codeset | ISO-8859-1 ... Matthias -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
Udo Richter wrote: 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 picky about what de_DE language variant is installed? Are you sure it's VDR who is picky? Isn't setlocale a little dumb here? In the end, this isn't really important. What matters is that you have to explain lots of users that they need to reconfigure their OS language from german to german in order to pick german as language manually inside VDR. Please try the patch I have posted yesterday under improving i18n-to-gettext.pl (vdr-1.5.7-i18n-matchlocale.diff)? Seems to make no difference. Probably because setlocale only accepts the full [EMAIL PROTECTED] string. There must be some way how this is supposed to work. Even if my locale is set to [EMAIL PROTECTED] and there's no pure de_DE in locale -a, almost all distribution' locales are in /usr/share/locale/de/, and they work. There must be some mapping from [EMAIL PROTECTED] down to de_DE and de. Yes, but the other applications are not listing locales nor using setlocale to change locale to those during runtime, which is the problem here. If there was another app that does it, it could be interesting to see how it manages that. I don't know other way than to use the locale -a way, i.e. traverse /usr/share/locale and parse locale.alias. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
Klaus Schmidinger wrote: On 08/18/07 21:46, Anssi Hannula wrote: Udo Richter wrote: 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 picky about what de_DE language variant is installed? Are you sure it's VDR who is picky? Isn't setlocale a little dumb here? In the end, this isn't really important. What matters is that you have to explain lots of users that they need to reconfigure their OS language from german to german in order to pick german as language manually inside VDR. Please try the patch I have posted yesterday under improving i18n-to-gettext.pl (vdr-1.5.7-i18n-matchlocale.diff)? Seems to make no difference. Probably because setlocale only accepts the full [EMAIL PROTECTED] string. There must be some way how this is supposed to work. Even if my locale is set to [EMAIL PROTECTED] and there's no pure de_DE in locale -a, almost all distribution' locales are in /usr/share/locale/de/, and they work. There must be some mapping from [EMAIL PROTECTED] down to de_DE and de. Yes, but the other applications are not listing locales nor using setlocale to change locale to those during runtime, which is the problem here. If there was another app that does it, it could be interesting to see how it manages that. I don't know other way than to use the locale -a way, i.e. traverse /usr/share/locale and parse locale.alias. Maybe I should have stayed with the old tI18nPhrase method. At least that worked everywhere out of the box... VDR's locale files are named like de_DE (language_COUNTRY). There's no @euro or other stuff added to the names. VDR needs to know which files it actually has at its disposal, in order to present to the user a list of all available languages. It makes no sense to present a language that in the end isn't available. Copying the *.mo files into /usr/share/locale/... could be done. VDR would then have to loop through all directories in /usr/share/locale and test each one for the presence of a vdr.mo file, as in /usr/share/locale/de/LC_MESSAGES/vdr.mo and use the directory name it finds (de in this case) as the value in its call to setlocale(). Unfortunately the de might not be a valid locale for setlocale(), as in Udo's case; only [EMAIL PROTECTED] and [EMAIL PROTECTED] are, even if the files from /de/ are used. I think the valid locales can be identified by having a LC_IDENTIFICATION file in the locale directory, containing the locale identification data (printed by locale -a -v), or if they are contained in /usr/share/locale.alias. Note that apparently Matthias Schwarzott's system (other thread) has the LC_IDENTIFICATION file in /usr/lib/locale instead of /usr/share/locale. The only problem I see is: how to find out what directories to copy VDR's *.mo files into? For example, VDR's German text file is named ./locale/de_DE/LC_MESSAGES/vdr.mo, but should it go into /usr/share/locale/de_DE/LC_MESSAGES/vdr.mo or /usr/share/locale/de/LC_MESSAGES/vdr.mo or even /usr/share/locale/[EMAIL PROTECTED]/LC_MESSAGES/vdr.mo? This decision clearly would have to be made at install time. /de/, as with other programs. If there will be additional territory-specific de translations of VDR, they will go to de_XX. The translations from /de/ are always used when locale is [EMAIL PROTECTED] And if all programs must have their texts in /usr/share/locale/..., why is there even a bindtextdomain() function? So that the locales can be installed into another directory/prefix, like inside the source tree. So, to sum things up: I might go along with copying VDR's *.mo files into /usr/share/locale/... (and prefix the plugin files with vdr- or something alike), if somebody can come up with a Makefile install-i18n target that copies VDR's files from $(LOCALEDIR) to the proper places under /usr/share/locale/... Oh, and of course the whole thing must still work locally in ./locale ;-) Well, changing the locale directory does not really change this issue at all. I guess the easiest and most compatible thing to do now would be to traverse /usr/share/locale dir and if $LOCDIR/xx/LC_MESSAGES/vdr.mo exists, try the names of all existing /usr/share/locale/xx*/ directories as parameter for setlocale(). ($LOCDIR being the VDR localedir, be that /usr/share/locale, /usr/share/vdr/locale, /home/anssi/vdr-1.5.7/locale, or whatever). -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Plugin to play streaming video
Hawes, Mark wrote: I am looking for a plugin to play steaming video from the net, and specifically at the moment NASA TV. I have the MP3/Mplayer plugin installed, and also played with the VOD plugin about a year ago, but still can't work out how to achieve what I want. Any help would be much appreciated. You can make a playlist file that contains the stream URL, and then make your mplayer.sh script call mplayer with -playlist option when that file is opened. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.7
Klaus Schmidinger wrote: - Internationalization is now done with 'gettext' (following a suggestion by Lucian Muresan). Plugin authors may want to use the Perl script 'i18n-to-gettext.pl' to convert their internationalized texts to the gettext format (see the instructions inside that script file). The function cPlugin::RegisterI18n() is still present for compatibility, but doesn't have any more functionality. So plugins that don't convert their texts to the gettext format will only present English texts. See PLUGINS.html, section Internationalization, for instructions on how to make strings in arrays translatable. See README.i18n for information on how to create new or maintain existing translations. I have only Finnish locales installed (locale -a), so only the selections suomi and English work from the plugin menu. The rest show up as deu,ger etc, and do not work; text shows up in English despite selecting them. Maybe the locales that the user does not have installed on their system should be hidden? -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Extension HD PCI from ReelMultimedia in August ?
Lars Bläser wrote: Georg Acher wrote: There was a discussion on that in this list a while ago which ended in fruitless anoyance about one binary only module in the Linux kernel on the HD card. Look for future VDR and NetCeiver OEM from Reelmultimedia and issues about binary only code its not really about the binary if its working its mote the fact that future kernel wont support this binary stuff and its supposed to be a future proof solution As Georg said, this binary module is *inside* the *card*. It may only limit your ability to update/modify the kernel which is running *in* the card. I don't see much of a problem in that (note that the firmware of current DVB full-featured cards is completely closed!), while some others do. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvbtextsubs 0.2
bob321 wrote: On 7/7/07, listnisse [EMAIL PROTECTED] wrote: I have searched the internet (including archive.org) for dvbtextsubs-0.2.tar.gz but haven't found it. I would really appreciate if some friendly soul on this list would like to send me the file or point me to a location. You are lucky or i have lot of old thing in my hd and a problem with del button, or maybe both. http://membres.lycos.fr/kjhii/tmp/ Its not the original package and i don't remember if i modify the code, i just remember i have a problem with french special character, so if i change something its related to charmap (if you have a charmap problem maybe look the file *.OLD) I seem to have the original tarball, so I put it here: http://stuff.onse.fi/dvbtextsubs-0.2.tar.gz -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] setting tv standard in /dev/video0
Stone wrote: On 6/30/07, *Stone* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: vdr: [7841] connect from 127.0.0.1 http://127.0.0.1/, port 49972 - accepted vdr: [7841] grabbing to JPEG 70 384 288 Can I hardcode the default resolution from within VDR or the kernel driver? Best Regards. Does it work if you use the v4lctl method? Are there any FTA NTSC transmissions on Astra 19.2° or Eutelsat 13°? I'd like to do some tests... I have not been able to test the v4lctl method since I do not have X on the machine. Does v4lctl require xawtv? I suppose I could try and install X but I would rather not if possible. Also, I'm not sure about Astra or Eutelsat since my dish is in America. I just went ahead and installed X and xawtv. It appears the v4lctl method does work and the kernel option does not. I wonder what the difference is between the two. AFAIK: The TV-out connectors in the dvb-ttpci board output automatically NTSC if the stream is NTSC. They output automatically PAL when the stream is PAL. When there is no stream (channel switch or the like), they output PAL by default, or NTSC if the tv_standard kernel option is used to select that. The output from /dev/video0 file is PAL all the time, unless it is changed by the proper V4L ioctl, which is done by VLC and v4lctl. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] future VDR and Net??eiver OEM from Reelmultimedia
Georg Acher wrote: On Fri, Jun 29, 2007 at 08:21:45AM -0700, Jeremy Jones wrote: I checked out the latest Reelbox testing svn code and browsed the code to see if it supports this device. I didn't look too thoroughly but it appears the reelbox-0.9.0 plugin does support it. It looks like communication to the kernel space driver is done through shared memory and I did see some kernel space code to create this shared memory device (/dev/hdshmem). I'm sure there is a closed source firmware or kernel module that is also used but since Reelbox is based on vdr this shouldn't be too much of a problem. Actually there's not much closed source that affects the usage. On the PC side there's none, That is great :) on the card side it's only the driver for the HDMI-chip in the kernel (otherwise Silicon Image would shoot us) and of course the firmwares for the internal audio/video-coprocessors (delivered by Micronas). Well, dvb-ttpci microcode is completely closed, so it is no better in this regard. I don't think having non-free microcode is going to be a problem. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.4
Klaus Schmidinger wrote:
On 06/17/07 18:16, Anssi Hannula wrote:
Klaus Schmidinger wrote:
VDR developer version 1.5.4 is now available
- Now using 'fontconfig' to determine which fonts to use (thanks to Anssi Hannula
for code and hints on how to do this).
+ char *s = (char *)FcNameUnparse(fontset-fonts[i]);
+ if (s) {
+// Strip i18n stuff:
+char *p = strchr(s, ',');
+if (p)
+ *p = 0;
Dropping everything after ',' seems correct, but AFAICS it should be
processed separately for the family name and style.
Currently, AFAICS,
DejaVu Sans,DejaVu Sans Condensed:style=Condensed Oblique,Oblique
becomes
DejaVu Sans
while I think it should become
DejaVu Sans:style=Condensed Oblique
Looks like I don't have any font here that has a comma in its name,
so I hope I got this right.
Can you please verify the attached patch?
I don't really use VDR 1.5 yet, but I tried to run the attached test
program. However, it segfaults in *p = 0. I also tested the previous
implementation quoted above, and it segfaults similarly.
--
Anssi Hannula
#include string.h
#include stdio.h
int main() {
char *s = DejaVu Sans,DejaVu Sans Condensed:style=Condensed Oblique,Oblique;
if (s) {
char *c = strchr(s, ':');
if (c) {
char *p = strchr(c+1 , ',');
if (p)
*p = 0;
}
char *p = strchr(s, ',');
if (p) {
if (c)
memmove(p, c, strlen(c) + 1);
else
*p = 0;
}
printf(%s\n, s);
}
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.4
Wolfgang Rohdewald wrote: On Samstag, 23. Juni 2007, Anssi Hannula wrote: I don't really use VDR 1.5 yet, but I tried to run the attached test program. However, it segfaults in *p = 0. I also tested the previous implementation quoted above, and it segfaults similarly. you try to write into a constant string. This would work: char *s; s=strdup(DejaVu Sans,DejaVu Sans Condensed:style=Condensed Oblique,Oblique); Right. It works correctly. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] PiP
Tony Houghton wrote: Has anyone thought about VDR supporting PiP (picture-in-picture)? It would be quite useful, but perhaps not enough to justify the work. Supporting all outputs, FF cards in particular, would require a lot of processing power to decode two streams then encode the superimposed version back to MPEG 2. Having the feature in Xine would be a lor more practical, but of course then Xine would need work done to support it. But I think it would be trivial for it to superimpose two decoded pictures compared to recoding the MPEG. See http://www.magoa.net/linux/ for the osdpip plugin. The latest version is quite old, but it seems to still work at least with VDR 1.4.7. The link seems to be down, but you can download the latest tarball and small patches for it to add support for recent vdr gcc from here: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/vdr-plugin-osdpip/current/SOURCES/ -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
Klaus Schmidinger wrote: On 06/10/07 17:53, Anssi Hannula wrote: + strcpy(FontOsd, arialbd.ttf); + strcpy(FontSml, arial.ttf); + strcpy(FontFix, courbd.ttf); I'd use some free-as-in-freedom font (Vera?) by default, that are more likely installed in systems. Those were the ones suggested in Alexander Riedel's original patch. Which ones would you suggest? If you will decide to go with fontconfig, just for the record, the relevant aliases AFAIK are sans-serif:bold, sans-serif, and monospace:bold, i.e. for the current defaults Arial Bold, Arial and Courier Bold. There probably is another way to specify bold (or query bold capability) using fontconfig functions as well, but :bold seems to work for me. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
Klaus Schmidinger wrote: On 06/15/07 18:07, Anssi Hannula wrote: Klaus Schmidinger wrote: On 06/10/07 17:53, Anssi Hannula wrote: ... Alternatively, you could use the fontconfig library [1] for managing fonts. This would also allow using using the system default fonts via aliases like 'sans-serif' etc, and using a font list instead of having to manually write the font filename via OSD. You can get a quick idea from looking at the patch which added fontconfig support for mplayer [2], though of course you should look in fontconfig documentation instead of copying conventions from mplayer :) [1] http://fontconfig.org/ [2] http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-November/022218.html When I do const char *font_name = sans-serif; FcInit(); FcPattern *fc_pattern = FcNameParse((FcChar8 *)font_name); While fontconfig is usually configured to ignore bitmap fonts anyway, I think you should enforce that by putting this call here: FcPatternAddBool(fc_pattern, FC_SCALABLE, FcTrue); Thanks. Actually, I was wrong here. This won't guarantee anything, as the preference priorities of parameters is predefined, and the family name and, apparently, various other parameters (which are actually left at their defaults) are given a priority over the font being scalable. I was hit with this when trying to select FC_FAMILY Utopia, and it kept returning the non-scalable version, even though a scalable version with the same name is available. Solution is given here: http://lists.freedesktop.org/archives/fontconfig/2006-March/002165.html So it is doable, but you have to use FcFontSort() ( http://www.xemacs.org/Documentation/packages/html/fontconfig_3.html#SEC20 ), which returns a similar FcFontSet as the FcFontList() which is used for the font listing, but this time the fonts are ordered according to the closeness of match, allowing you to pick the first font with FC_SCALABLE being true. [...] I don't know if you have noticed / thought of these already, but few tips: - For the fixed-size font list, you can use a match of FC_SPACING being FC_MONO so that non-monospace fonts are not listed. - Have a default (or system default) font setting in the font list, which causes VDR to use the default aliases instead of user-specified font -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
Klaus Schmidinger wrote: On 06/16/07 15:36, Anssi Hannula wrote: Klaus Schmidinger wrote: On 06/10/07 17:53, Anssi Hannula wrote: + strcpy(FontOsd, arialbd.ttf); + strcpy(FontSml, arial.ttf); + strcpy(FontFix, courbd.ttf); I'd use some free-as-in-freedom font (Vera?) by default, that are more likely installed in systems. Those were the ones suggested in Alexander Riedel's original patch. Which ones would you suggest? If you will decide to go with fontconfig, just for the record, the relevant aliases AFAIK are sans-serif:bold, sans-serif, and monospace:bold, i.e. for the current defaults Arial Bold, Arial and Courier Bold. There probably is another way to specify bold (or query bold capability) using fontconfig functions as well, but :bold seems to work for me. Yes, I'm currently going for fontconfig - looks very promising so far. And your hint is much appreciated - that's exactly what I needed right now :-) About those bolds.. It seems using the :bold suffix isn't reliable, i.e. at least here using monospace:bold and calling FcFontSort returns non-monospace fonts ahead of the wanted monospace fonts. Using this it works correctly, though, and the bold monospace font is returned first: FcPatternAddInteger(fc_pattern, FC_WEIGHT, FC_WEIGHT_BOLD) -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
Anssi Hannula wrote: Klaus Schmidinger wrote: On 06/16/07 15:36, Anssi Hannula wrote: Klaus Schmidinger wrote: On 06/10/07 17:53, Anssi Hannula wrote: + strcpy(FontOsd, arialbd.ttf); + strcpy(FontSml, arial.ttf); + strcpy(FontFix, courbd.ttf); I'd use some free-as-in-freedom font (Vera?) by default, that are more likely installed in systems. Those were the ones suggested in Alexander Riedel's original patch. Which ones would you suggest? If you will decide to go with fontconfig, just for the record, the relevant aliases AFAIK are sans-serif:bold, sans-serif, and monospace:bold, i.e. for the current defaults Arial Bold, Arial and Courier Bold. There probably is another way to specify bold (or query bold capability) using fontconfig functions as well, but :bold seems to work for me. Yes, I'm currently going for fontconfig - looks very promising so far. And your hint is much appreciated - that's exactly what I needed right now :-) About those bolds.. It seems using the :bold suffix isn't reliable, i.e. at least here using monospace:bold and calling FcFontSort returns non-monospace fonts ahead of the wanted monospace fonts. Actually, you can disregard this, these *do* work correctly when used with FcNameParse(). (I first tested by specifically putting these suffixes into the FC_FAMILY field, which does not work) Using this it works correctly, though, and the bold monospace font is returned first: FcPatternAddInteger(fc_pattern, FC_WEIGHT, FC_WEIGHT_BOLD) -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
Klaus Schmidinger wrote:
On 06/16/07 16:29, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 06/15/07 18:07, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 06/10/07 17:53, Anssi Hannula wrote:
...
Alternatively, you could use the fontconfig library [1] for managing
fonts. This would also allow using using the system default fonts via
aliases like 'sans-serif' etc, and using a font list instead of having
to manually write the font filename via OSD.
You can get a quick idea from looking at the patch which added
fontconfig support for mplayer [2], though of course you should look in
fontconfig documentation instead of copying conventions from mplayer :)
[1] http://fontconfig.org/
[2]
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-November/022218.html
When I do
const char *font_name = sans-serif;
FcInit();
FcPattern *fc_pattern = FcNameParse((FcChar8 *)font_name);
While fontconfig is usually configured to ignore bitmap fonts anyway, I
think you should enforce that by putting this call here:
FcPatternAddBool(fc_pattern, FC_SCALABLE, FcTrue);
Thanks.
Actually, I was wrong here. This won't guarantee anything, as the
preference priorities of parameters is predefined, and the family name
and, apparently, various other parameters (which are actually left at
their defaults) are given a priority over the font being scalable. I was
hit with this when trying to select FC_FAMILY Utopia, and it kept
returning the non-scalable version, even though a scalable version with
the same name is available.
Solution is given here:
http://lists.freedesktop.org/archives/fontconfig/2006-March/002165.html
So it is doable, but you have to use FcFontSort() (
http://www.xemacs.org/Documentation/packages/html/fontconfig_3.html#SEC20
), which returns a similar FcFontSet as the FcFontList() which is used
for the font listing, but this time the fonts are ordered according to
the closeness of match, allowing you to pick the first font with
FC_SCALABLE being true.
[...]
I don't know if you have noticed / thought of these already, but few tips:
- For the fixed-size font list, you can use a match of FC_SPACING being
FC_MONO so that non-monospace fonts are not listed.
- Have a default (or system default) font setting in the font list,
which causes VDR to use the default aliases instead of user-specified font
Since you're apparently getting more and more familiar with this,
maybe you could provide a complete code sequence that does this:
- list all available fonts, as in Arial, Verdana, Times New Roman, ...
- optionally list only monospaced fonts
- make sure there are only scalable fonts (i.e. ones that freetype can use)
- if possible, give information on whether a particular font is available
as bold and/or italic
This function prints all the fonts in a format which can be fed back to
FcNameParse(). AFAICS you only need slant+weight or style, use which one
you prefer.
int printfonts(bool only_monospace, bool slant_and_weight_instead_of_style)
{
FcInit();
FcObjectSet *os;
if (slant_and_weight_instead_of_style)
os = FcObjectSetBuild(FC_FAMILY, FC_SLANT, FC_WEIGHT,
NULL);
else
os = FcObjectSetBuild(FC_FAMILY, FC_STYLE, NULL);
FcPattern *pat = FcPatternCreate();
FcPatternAddBool(pat, FC_SCALABLE, FcTrue);
if (only_monospace)
FcPatternAddInteger(pat, FC_SPACING, FC_MONO);
FcFontSet* fontset = FcFontList(NULL, pat, os);
FcObjectSetDestroy(os);
FcPatternDestroy(pat);
for (int i = 0; i fontset-nfont ; i++) {
printf(%s\n, FcNameUnparse(fontset-fonts[i]));
}
FcFontSetDestroy(fontset);
FcFini();
}
Here's a function that prints the font name when inputted with a string
outputted by printfonts(), or NULL if not found:
void getfontfilename(char* identifier, char **filename)
{
FcPattern *pat = FcNameParse((FcChar8*)identifier);
FcPatternAddBool(pat, FC_SCALABLE, FcTrue);
FcConfigSubstitute(NULL, pat, FcMatchPattern);
FcDefaultSubstitute(pat);
FcFontSet* fontset = FcFontSort(NULL, pat, FcFalse, NULL, NULL);
FcPatternDestroy(pat);
FcBool scalable;
*filename = NULL;
for (int i = 0; i fontset-nfont; i++) {
FcPatternGetBool(fontset-fonts[i], FC_SCALABLE, 0,
scalable);
if (scalable) {
FcPatternGetString(fontset-fonts[i], FC_FILE,
0, (FcChar8**)filename);
break;
}
}
FcFontSetDestroy(fontset);
}
From the setup menu I'd like to be able to call a function that delivers
a list of font names (much like it's currently done with the actual font
file names) that looks like
Arial
Arial:bold
Arial:italic
Arial:bold:italic
Verdana
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
Klaus Schmidinger wrote: On 06/16/07 18:28, Anssi Hannula wrote: ... courier:bold Probably monospace:bold instead of courier:bold. I tried both, and courier:bold looks a lot better to me (much more like a typewriter font). Fine then :) -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.3
Klaus Schmidinger wrote: - Implemented support for Freetype fonts (based on a patch from Alexander Riedel). The font names and sizes can be adjusted in the Setup/OSD menu. Note that VDR now requires freetype fonts to be installed in /usr/share/fonts/truetype. In my system there is no /usr/share/fonts/truetype, but the TTF fonts reside in other subdirectories under /usr/share/fonts. + strcpy(FontOsd, arialbd.ttf); + strcpy(FontSml, arial.ttf); + strcpy(FontFix, courbd.ttf); I'd use some free-as-in-freedom font (Vera?) by default, that are more likely installed in systems. Alternatively, you could use the fontconfig library [1] for managing fonts. This would also allow using using the system default fonts via aliases like 'sans-serif' etc, and using a font list instead of having to manually write the font filename via OSD. You can get a quick idea from looking at the patch which added fontconfig support for mplayer [2], though of course you should look in fontconfig documentation instead of copying conventions from mplayer :) [1] http://fontconfig.org/ [2] http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-November/022218.html -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.3 - LANG=[EMAIL PROTECTED] not recognized
Joachim Wilke wrote: Hi everbody, in my system the LANG environment is set to [EMAIL PROTECTED]. VDR did not recognize this character set. After I changed LANG to de_DE.iso-8859-15 umlauts are correctly displayed e.g.in the EPG data. But I still get the following error in syslog: codeset is 'ISO-8859-15' - unknown. What's wrong here? I had a look into vdr.c and found out, that the dot is used delimiter between language and codeset - as [EMAIL PROTECTED] does not contain any dot, vdr fails to recognize this. Is [EMAIL PROTECTED] an invalid value for this variable? It is not. locale -a prints all the installed locales, and any of those values is valid for you to use. I didn't find any info via quick search, but I believe that instead of parsing the localename, VDR should use some external function to get the language/charset of the current locale. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.3 - LANG=[EMAIL PROTECTED] not recognized
Klaus Schmidinger wrote: On 06/10/07 22:22, Anssi Hannula wrote: Joachim Wilke wrote: I had a look into vdr.c and found out, that the dot is used delimiter between language and codeset - as [EMAIL PROTECTED] does not contain any dot, vdr fails to recognize this. Is [EMAIL PROTECTED] an invalid value for this variable? It is not. locale -a prints all the installed locales, and any of those values is valid for you to use. I didn't find any info via quick search, but I believe that instead of parsing the localename, VDR should use some external function to get the language/charset of the current locale. There's getenv(LANG), setlocale(LC_CTYPE, ), and Thomas Günther recently suggested in a PM to use nl_langinfo(CODESET). Quite a few options - which one is the right one? ;-) Somebody with insight please advise exactly how to do this - I personally just set LANG to de_DE.iso8859-1 and live happily ever after ;-) Looking at nl_langinfo manpage, it seems to me that nl_langinfo(CODESET) is the correct one to use: Return a string with the name of the character encoding used in the selected locale, such as UTF-8, ISO-8859-1, or ANSI_X3.4-1968 (better known as US-ASCII). This is the same string that you get with locale charmap. For a list of charac- ter encoding names, try locale -m, cf. locale(1). -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR timer + mplayer = VDR crash. Please fix!
Stefan Huelswitt wrote: On 07 Jun 2007 Anssi Hannula [EMAIL PROTECTED] wrote: Attached is a patch for mplayer plugin which closes file descriptors (except 0, 1, 2) when forking mplayer script. Thanks. I took over that with slight changes. The final patch is attached. Could I please have some feedback if it's working as good as yours? Testing confirms it is closing the file descriptors as well, yes :) -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR timer + mplayer = VDR crash. Please fix!
VDR User wrote: On 6/6/07, Anssi Hannula [EMAIL PROTECTED] wrote: VDR User wrote: If a timer is triggered while the mplayer plugin is in use, VDR crashes. This has happened to me about a zillion times now and I'm hoping somebody will fix this! You can use the mplayer plugin after a timer is started no problem. Correct me if I'm wrong but mplayer should never have to take control of the tuner in the first place since it's not required to play a media file. Free booze to anyone who can fix this incredibly annoying problem once and for all!! This could be related to the fact that when mplayer-plugin forks mplayer from vdr, the /dev/dvb/adapter* file descriptors are copied as well and are not closed. Thanks for such a quick reply Anssi! Is that an easy thing to fix? Attached is a patch for mplayer plugin which closes file descriptors (except 0, 1, 2) when forking mplayer script. -- Anssi Hannula diff -Nurp -x '*~' mp3-0.9.15/player-mplayer.c mp3-0.9.15-c/player-mplayer.c --- mp3-0.9.15/player-mplayer.c 2006-09-19 21:17:50.0 +0300 +++ mp3-0.9.15-c/player-mplayer.c 2007-06-07 23:34:17.0 +0300 @@ -29,6 +29,7 @@ #include sys/ioctl.h #include sys/types.h #include sys/poll.h +#include sys/resource.h #include unistd.h #include signal.h #include wait.h @@ -395,6 +396,11 @@ bool cMPlayerPlayer::Fork(void) close(outpipe[1]); } + rlimit lim; + if(getrlimit(RLIMIT_NOFILE, lim) == 0) +for(int i = lim.rlim_max - 1; i 2; i--) + close(i); + char cmd[64+PATH_MAX*2], aid[20]; char *fname=Quote(file-FullPath()); if(MPlayerAid=0) snprintf(aid,sizeof(aid), AID %d,MPlayerAid); ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
