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
11.09.2012 19:05, Dominic Evans kirjoitti: > On 11 September 2012 10:30, Anssi Hannula 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] [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] 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
29.02.2012 10:30, Tobi kirjoitti: > On 29.02.2012 08:24, Dave wrote: > >> And the Linux distributions will generally only package 'stable' versions. > > For Debian I'm already packaging 1.7.x, because 1.6 became pretty much > useless nowadays. Wheezy is going to freeze in June and I hope that VDR > becomes stable until then. For Mageia (upcoming mga2) I just recently updated the packages to 1.7.x, and Fedora seems to also be shipping 1.7.x already. -- 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] vdr-sxfe and IEC958 audio
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 and "iec958:AES0=0x06" for passthrough. 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); //
[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] [Announce] vdr-streamdev-0.5.0 / 0.4.0
Frank Schmirler kirjoitti tiistai, 20. heinäkuuta 2010 12:06:44: > On Mon, 19 Jul 2010 16:39:00 +0200, Frank Schmirler wrote > > > I finally published new streamdev releases on > > http://streamdev.vdr-developer.org. > > Just updated the archive due to two minor problems with externremux.sh: > - externremux.sh was not executable in the archive > - typo in value for quality parameter: should be wlan54 instead of wlan45 It would be appreciated if in the future you'd mark such a release 0.5.0a or 0.5.1 instead of replacing archives. Its never a good thing that there are multiple similarly named tarballs but with different content floating around, especially for downstream distributors. Thanks for the nice release, anyway :) -- Anssi Hannula ___ 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
Re: [vdr] [Makefile] `-fPIC` not added to externally defined `C[XX]FLAGS` of PLUGINS if `Make.config` not available
On tiistai, 26. tammikuuta 2010 12:09:11 Frank Schmirler wrote: > On Tue, 26 Jan 2010 10:54:00 +0100, Paul Menzel wrote > > > Am Dienstag, den 26.01.2010, 10:34 +0100 schrieb Frank Schmirler: > > > This has already been discussed during the last months, I just didn't > > > take the time yet to propose a fix: > > > > > > http://www.linuxtv.org/pipermail/vdr/2009-July/020977.html > > > http://www.linuxtv.org/pipermail/vdr/2009-December/021807.html > > > > Thank you for the links. I could not figure out what alternativ is > > preferred though. If you tell me, I could prepare a patch. > > Well, there hasn't been much feedback... At first I preferred the "copy > Make.config.template to Make.config if it doesn't exist" approach as it > doesn't require any change in plugin Makefiles and adds just a single line > to VDR's Makefile. But the cleaner solution is clearly "include a > Make.global in plugin plugin and VDR Makefiles before Make.config" as > preferred by Udo Richter. I also prefer this approach. Make.global should contain the necessary stuff and Make.config should contain strictly user-defined optional stuff. > Would be great if you could prepare the patch. -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Applying dxr3 subtitles patch to debian packages
On tiistai, 26. tammikuuta 2010 20:04:28 Ville Skyttä wrote: > On Tuesday 26 January 2010, Emyr Thomas wrote: > > My question is, given the way I've installed VDR, what's the > > best/easiest way for me to apply this patch? Do I have to compile VDR > > from source myself, or can I somehow modify the debian VDR package > > sources on my machine and build them with this patch applied? > > I'm not familiar with Debian packaging, but I suppose the latter would be > possible, and perhaps the maintainers of your Debian VDR package would > consider including the patch in the package's source tree as an optional > one so it'd be easier for people who want to rebuild it. (Or even just > apply it unconditionally by default, that's what we've done in Fedora for > a long time and there have been no complaints.) It forces reduced 2-bit mode in subtitles, not a nice thing to do if you have hardware capable of displaying the original subtitles :/ In Mandriva we have a hack allowing the device plugin to force 2-bit mode: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/vdr-plugin-dxr3/current/SOURCES/dxr3-subtitles.patch?revision=197607&view=markup http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/vdr/current/SOURCES/vdr-1.6.0-dxr3.patch?revision=197494&view=markup -- Anssi Hannula ___ 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
[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] 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] 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] softplay like plugin for vdr-xine w/ vdpau?
Torgeir Veimo wrote: > 2009/9/12 Gregoire Favre : >> 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
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 #include #include -#include #include #include #include @@ -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 #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] [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
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: >>>> 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: > Anssi Hannula wrote: >> Maybe one of these includes in these files is missing? > > as you can see - no, everything is ok Confirm that you looked at the correct files: You should first look under ../s2-liplianin/linux/include/, and if the file in question doesn't exist there, you should look under /usr/include/ (note, not in /usr/src). -- 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: > Hi > > I can't compile vdr 179 > > arvdr:/usr/src/vdr# LANG=C make > g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -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 vdr.c > In file included from dvbdevice.h:14, > from vdr.c:45: > ../s2-liplianin/linux/include/linux/dvb/frontend.h:92: error: '__u8' does not > name a type > ../s2-liplianin/linux/include/linux/dvb/frontend.h:93: error: '__u8' does not > name a type > ../s2-liplianin/linux/include/linux/dvb/frontend.h:98: error: '__u8' does not > name a type > ../s2-liplianin/linux/include/linux/dvb/frontend.h:99: error: '__u8' does not > name a type > ../s2-liplianin/linux/include/linux/dvb/frontend.h:361: error: '__u8' does > not name a type > make: *** [vdr.o] Error 1 Your headers seem broken. What should happen (i.e. in upstream kernel git) is: linux/dvb/frontend.h has: #include linux/types.h has: #include asm/types.h has: #include asm-generic/int-ll64.h has: typedef unsigned char __u8; Maybe one of these includes in these files is missing? -- Anssi Hannula ___ 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 as Tobi recommended > http://e-tobi.net/websvn/filedetails.php?repname=vdr-pkg&path=%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 , which in turn (/usr/include/linux/types.h) #includes . Including from VDR should not be necessary. Could you confirm that your frontend.h file also contains #include and tha tyour /usr/include/linux/types.h #includes ? -- Anssi Hannula ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Newbee questions about HDTV VDR system with TT-budget S2-3200.
Klaus Schmidinger wrote: > http://linuxtv.org/hg/v4l-dvb should work, but you'll still > need the patch from > > ftp://ftp.cadsoft.de/vdr/Developer/v4l-dvb-header-fix.diff > > because the header files apparently are still broken :-( This commit should've fixed them: http://linuxtv.org/hg/v4l-dvb/rev/dba0b6fae413 What error are you getting? -- 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?
VDR User wrote: > On Thu, May 7, 2009 at 11:38 AM, 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. > > 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] 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] 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 2>&1 > > 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 includes appear before the > linux DVB header includes . 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 > +#include > > 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
[vdr] Old subtitles not stopped when switching primary device
Hi!
When switching the primary device, old subtitles are not removed, and
user may get the subtitles of wrong channel or two sets of subtitles at
the same time.
Attached is a hacky patch that doesn't work if MakePrimaryDevice() is
implemented by a plugin device. Unfortunately I haven't currently got
the time to make a proper patch, but this should give you an idea on the
problem.
--
Anssi Hannula
Index: vdr-1.6.0-primdev/device.c
===
--- vdr-1.6.0-primdev/device.c
+++ vdr-1.6.0-primdev/device.c 2008-05-23 22:17:05.0 +0300
@@ -313,6 +313,10 @@
void cDevice::MakePrimaryDevice(bool On)
{
+ if (On == false) {
+ DELETENULL(liveSubtitle);
+ DELETENULL(dvbSubtitleConverter);
+ }
}
bool cDevice::SetPrimaryDevice(int n)
Index: vdr-1.6.0-primdev/dvbdevice.c
===
--- vdr-1.6.0-primdev/dvbdevice.c
+++ vdr-1.6.0-primdev/dvbdevice.c 2008-05-23 22:18:03.0 +0300
@@ -486,6 +486,7 @@
{
if (On && HasDecoder())
new cDvbOsdProvider(fd_osd);
+ cDevice::MakePrimaryDevice(On);
}
bool cDvbDevice::HasDecoder(void) const
___
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: > 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
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: >> 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] 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: > 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] 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=202766&view=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
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 >> tools-dvd.h:#include >> [EMAIL PROTECTED] dvd]# grep inttypes.h * >> ca52.h:#include >> dvdspu.c:#include >> dvdspu.h:#include >> tools-dvd.h:#include 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 and #include 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=202766&view=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: > 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 > or 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 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] 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
[vdr] VDR constantly adding and deleting filters
eting, pmtPid 257, pmtIndex = 1,
> lastPmtScan = 0
> May 6 05:18:43 epsilon vdr: [30688] Adding, pmtPid 259, Index = 3, Sid = 81
> May 6 05:18:43 epsilon vdr: [30685] Adding, pmtPid 256, Index = 1, Sid = 225
> May 6 05:18:43 epsilon vdr: [30682] Deleting, pmtPid 257, pmtIndex = 2,
> lastPmtScan = 0
> May 6 05:18:43 epsilon vdr: [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] 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
[EMAIL PROTECTED] wrote: >> I believe JJussi is mixing things up a bit. What he describes is >> audio subtitling, which YLE has chosen to send labelled as a Dutch >> audio track. It seems that they have started to use Dutch also for >> Finnish subtitling for Finnish spoken programs. > > They would have selected some African language :) ... that are not selectable in many boxes, I think :) -- 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
Ville Skyttä wrote: > On Thursday 06 March 2008, Luca Olivetti wrote: > >> Yes, it should be in cvs, the only thing missing is calling the cOsd >> constructor with Level instead of 0 > > That's right - all patches posted for the DXR3 plugin are now in CVS, thanks > again to everyone involved. > > However, Luca and Ville A, you seem to be using different patches to VDR's > dvbsubtitle.c - looks like Luca's contains all the changes in Ville A's, but > comments those out and uses something else instead. > > Unless a better fix emerges, I'm quite interested in including one of these > in > the upcoming VDR 1.6.x package for Fedora and also ship it in the DXR3 plugin > tarball (possibly modified so that it's only enabled if the primary device is > a DXR3 if possible), but I don't quite follow which would be the preferred > one. > > Could you compare and comment (off-list is fine, this may be getting a bit > off > topic for the general VDR public)? Preferably on-list, as I'm planning a similar conditional patch for Mandriva VDR 1.6.x packages. That is, unless something better emerges. > http://article.gmane.org/gmane.linux.vdr/35860 > http://article.gmane.org/gmane.linux.vdr/35881 -- 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] 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] [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] 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] translation context handling in vdr >= 1.5.7
Klaus Schmidinger wrote:
> On 08/23/07 13:48, Christian Wieninger wrote:
>> Hi,
>>
>> I just noticed a small change in the context handling of translations
>> since vdr-1.5.7. Till now it was possible to have e.g.
>>
>> const char AllowedChars[] = trNOOP("$
>> abcdefghijklmnopqrstuvwxyz0123456789-.,#~\\^$[]|()*+?{}/:%@&");
>>
>> Note the 2 '$'. The first one only helps to have the second one in the
>> translation and not to be interpreted as context.
>>
>> Previous implementations of I18nTranslate did only cut the context of
>> the english version. So the translation could look like this in i18n.c
>> or the po-files:
>>
>>// The allowed characters in strings:
>>{ "$ abcdefghijklmnopqrstuvwxyz0123456789-.,#~\\^$[]|()*+?{}/:%@&",
>> " aäbcdefghijklmnoöpqrsßtuüvwxyz0123456789-.,#~\\^$[]|()*+?{}/:%@&",
>> " abcdefghijklmnopqrstuvwxyz0123456789-.,#~\\^$[]|()*+?{}/:%@&",
>> ...
>>
>> The current implementation cuts the translations too which results in
>>
>> "[]|()*+?{}/:%@&"
>>
>> Is this intended? If so, one could add the dummy '$' also at the
>> beginning of the translation, but has to handle this again for backwards
>> compatibility.
>>
>> If it's not intended the following patch should give the previous behaviour:
[...]
>
> gettext() may or may not return the original string, so if no translation
> is found, the context needs to be stripped.
[...]
For the record, gettext also has context support:
http://www.gnu.org/software/gettext/manual/gettext.html#Contexts
But if it needs too many changes, maybe it is not worth it.
--
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.22&r2=1.23&cvsroot=glibc&f=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 Anssi, > > Anssi Hannula wrote: >> What is the output of "locale"? > > it says: > LANG= > LC_CTYPE="POSIX" > LC_NUMERIC="POSIX" > LC_TIME="POSIX" > LC_COLLATE="POSIX" > LC_MONETARY="POSIX" > LC_MESSAGES="POSIX" > LC_PAPER="POSIX" > LC_NAME="POSIX" > LC_ADDRESS="POSIX" > LC_TELEPHONE="POSIX" > LC_MEASUREMENT="POSIX" > LC_IDENTIFICATION="POSIX" > LC_ALL= LANGUAGE variable that VDR uses is ignored when LC_MESSAGES or LC_ALL is set to "POSIX" or "C". -- 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 Anssi, > > Anssi Hannula wrote: >> What is the output of "locale"? > > it says: > LANG= > LC_CTYPE="POSIX" > LC_NUMERIC="POSIX" > LC_TIME="POSIX" > LC_COLLATE="POSIX" > LC_MONETARY="POSIX" > LC_MESSAGES="POSIX" > LC_PAPER="POSIX" > LC_NAME="POSIX" > LC_ADDRESS="POSIX" > LC_TELEPHONE="POSIX" > LC_MEASUREMENT="POSIX" > LC_IDENTIFICATION="POSIX" > LC_ALL= Hmm, what about: LC_ALL=en_US LANGUAGE=de_DE ls --help Which language is the message displayed in? > I checked the manpage of locale and it says that I can set the following > variables: > LANG > LC_ALL > LC_CTYPE > LC_MESSAGES > NLSPATH > > I checked then the homepage of gettext and it says: > "Then, users only have to set the LANG environment variable to the > appropriate `ll_CC' combination prior to using the programs in the > package. See Matrix. For example, let's presume a German site. At the > shell prompt, users merely have to execute `setenv LANG de_DE' (in csh) > or `export LANG; LANG=de_DE' (in sh). They could even do this from their > .login or .profile file." > > see here: > http://www.gnu.org/software/gettext/manual/gettext.html#End-Users LANGUAGE variable is described as the method to use by software wishing to provide an option to change language: http://www.gnu.org/software/gettext/manual/gettext.html#gettext-grok > I checked also the version of gettext and it seems that the current > version of gettext is 0.16 which I have installed. > Are you using an older version of gettext? Nope, latest is in use. -- 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]> [23-08-07 16:14]: >> And when using LANGUAGE=de_DE instead of LANG=de_DE? > > that does not work, ls --help keeps english with LANGUAGE=de_DE only > LANG=de_DE works. What is the output of "locale"? -- 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]> [23-08-07 14:56]: >> Does the localization work in other programs, like "ls --help" and so on? > > yes, LANG=de_DE ls --help gives german help and ls --help gives > english help. And when using LANGUAGE=de_DE instead of LANG=de_DE? -- 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] 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
[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] 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
Re: [vdr] vdr-1.5.7-1.5.8.diff problems?
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? -- 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] [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
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
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
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/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] [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
Wolfgang Rohdewald wrote:
> On Samstag, 18. August 2007, Klaus Schmidinger wrote:
>> 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.
>
> the debian package iso-codes contains all ISO 639 language codes
> with translations, so you could use those.
And an URL:
http://pkg-isocodes.alioth.debian.org/
> The muggle plugin uses this to display the language of the audio file in
> the vdr OSD language.
>
> You should use at least version iso-codes 0.47-2 (Aug 2005), older
> versions were missing german translations for most european languages.
>
> from muggle, vdr_actions.c:
>
> dgettext("iso_639",item->value().c_str())
>
> where the 2nd arg is the english language name AFAIR
Seems like a good solution to me.
--
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] 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
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] [ANNOUNCE] VDR developer version 1.5.7
Klaus Schmidinger wrote:
> On 08/18/07 12:28, Anssi Hannula wrote:
>> 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.
>
> That would mean that there is again something in VDR's core code that
> has to be maintained by various translators - I'm glad I got the i18n
> stuff out of the core code, and I wouldn't want to go back again.
I don't consider maintaining a single table for language names (either
native, or English with translations to all langs in .mo files) a problem.
> If you want to see all languages in their native wording, I guess
> that means you'll have to install all locales. Or, suggest a way
> to allow VDR to use setlocale/gettext without the need for the locales
> to actually be installed. VDR has all its text files available and
> only needs a way to have gettext() use them. This is currently done
> by calling setlocale() - maybe there's an other way?
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] 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] [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] [ANNOUNCE] VDR developer version 1.5.7
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.
>>> 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.
--
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
[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] [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
