Re: [vdr] vdr 1.7.23: patch for handling symlinks in recordings directory as earlier

[Lucian Muresan]

On 01/27/2012 01:04 PM, Oliver Endriss wrote:

On Thursday 26 January 2012 11:07:18 Klaus Schmidinger wrote:

On 25.01.2012 14:11, Oliver Endriss wrote:

On Wednesday 25 January 2012 10:29:16 Klaus Schmidinger wrote:

On 17.01.2012 14:26, sundararaj reel wrote:

Hi,

I am attaching a patch for vdr 1.7.23 for the problem described here:
http://www.vdr-portal.de/board1-news/board2-vdr-news/p1047199-announce-vdr-developer-version-1-7-23/#post1047199

There appears to be a problem in listing recordings due to a bug fix
in vdr 1.7.23. "Fixed handling symbolic links in
cRecordings::ScanVideoDir()"

The attached patch just disables the translation of symbolic links to
"real" paths. So that all recordings appear to be under the same
(recordings) directory tree, as it was earlier.

Please reply with your results.


Can somebody who has actually this use case please confirm
whether this patch fixes the problem?


Confirmed.

Without this patch, symbolic links are not displayed
correctly on my machine.

Oliver


Thanks.

I believe the second call to stat() is now superfluous.
Can you please confirm that the following patch still works
as expected?

--- recording.c 2012/01/25 09:32:39 2.45
+++ recording.c 2012/01/26 10:02:29
@@ -1120,11 +1120,6 @@
   continue;
   }sundararaj reel
Link = 1;
- buffer = ReadLink(buffer);
- if (!*buffer)
-continue;
- if (stat(buffer,&st) != 0)
-continue;
}
 if (S_ISDIR(st.st_mode)) {
if (endswith(buffer, deleted ? DELEXT : RECEXT)) {


Yes, it does not make any difference here.


Well, with this patch, symbolic links are not displayed at all on my VDR 
machine, whereas with sundararaj reel's fix they are displayed correctly.


Cheers,
Lucian


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr 1.7.23: patch for handling symlinks in recordings directory as earlier

[Lucian Muresan]

On 13.02.2012 10:43, Klaus Schmidinger wrote:

On 01/27/2012 01:04 PM, Oliver Endriss wrote:

On Thursday 26 January 2012 11:07:18 Klaus Schmidinger wrote:

On 25.01.2012 14:11, Oliver Endriss wrote:

On Wednesday 25 January 2012 10:29:16 Klaus Schmidinger wrote:

On 17.01.2012 14:26, sundararaj reel wrote:


[...]


Well, with this patch, symbolic links are not displayed at all on my
VDR machine, whereas with sundararaj reel's fix they are displayed
correctly.


So what you're saying it that this...

--

--- a/recording.c
+++ b/recording.c
@@ -1120,9 +1120,13 @@ void cRecordings::ScanVideoDir(const char
*DirName, bool Foreground, int LinkLev
continue;
}
Link = 1;
+#if 0
+ // do not resolve the symbolic links in paths to real path
+ // thereby keeping all the recordings under one directory
buffer = ReadLink(buffer);
if (!*buffer)
continue;
+#endif
if (stat(buffer, &st) != 0)
continue;
}
--


...works, while this...

--

--- recording.c 2012/01/25 09:32:39 2.45
+++ recording.c 2012/01/26 10:02:29
@@ -1120,11 +1120,6 @@
continue;
}
Link = 1;
- buffer = ReadLink(buffer);
- if (!*buffer)
- continue;
- if (stat(buffer, &st) != 0)
- continue;
}
if (S_ISDIR(st.st_mode)) {
if (endswith(buffer, deleted ? DELEXT : RECEXT)) {
--


...doesn't?

I find that hard to believe, because the only difference here is that
the second version removes the stat() call, which is superfluous if
'buffer' is no longer modified.


Haven't really looked at the code, until now, and I also do not exactly 
know what the call to stat does and also didn't try to understand the 
whole picture now, but your patch does not simply remove just the call 
to stat, but also a *continue* statement from the *while* loop, this 
could have strong implications, so just please consider analyzing the 
issue with respect to that.


Regards,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr 1.7.23: patch for handling symlinks in recordings directory as earlier

[Lucian Muresan]

On 13.02.2012 12:00, Klaus Schmidinger wrote:

On 13.02.2012 11:44, Lucian Muresan wrote:

On 13.02.2012 10:43, Klaus Schmidinger wrote:

On 01/27/2012 01:04 PM, Oliver Endriss wrote:

On Thursday 26 January 2012 11:07:18 Klaus Schmidinger wrote:

On 25.01.2012 14:11, Oliver Endriss wrote:

On Wednesday 25 January 2012 10:29:16 Klaus Schmidinger wrote:

On 17.01.2012 14:26, sundararaj reel wrote:


[...]


Well, with this patch, symbolic links are not displayed at all on my
VDR machine, whereas with sundararaj reel's fix they are displayed
correctly.


So what you're saying it that this...

--


--- a/recording.c
+++ b/recording.c
@@ -1120,9 +1120,13 @@ void cRecordings::ScanVideoDir(const char
*DirName, bool Foreground, int LinkLev
continue;
}
Link = 1;
+#if 0
+ // do not resolve the symbolic links in paths to real path
+ // thereby keeping all the recordings under one directory
buffer = ReadLink(buffer);
if (!*buffer)
continue;
+#endif
if (stat(buffer, &st) != 0)
continue;
}
--



...works, while this...

--


--- recording.c 2012/01/25 09:32:39 2.45
+++ recording.c 2012/01/26 10:02:29
@@ -1120,11 +1120,6 @@
continue;
}
Link = 1;
- buffer = ReadLink(buffer);
- if (!*buffer)
- continue;
- if (stat(buffer, &st) != 0)
- continue;
}
if (S_ISDIR(st.st_mode)) {
if (endswith(buffer, deleted ? DELEXT : RECEXT)) {
--



...doesn't?

I find that hard to believe, because the only difference here is that
the second version removes the stat() call, which is superfluous if
'buffer' is no longer modified.


Haven't really looked at the code, until now, and I also do not
exactly know what the call to stat does and also didn't try to
understand the whole picture now, but your patch does not simply
remove just the call to stat, but also a *continue* statement from the
*while* loop, this could have strong
implications, so just please consider analyzing the issue with respect
to that.


The original code was

--

if (stat(buffer, &st) == 0) {
int Link = 0;
if (S_ISLNK(st.st_mode)) {
if (LinkLevel > MAX_LINK_LEVEL) {
isyslog("max link level exceeded - not scanning %s", *buffer);
continue;
}
Link = 1;
buffer = ReadLink(buffer);
if (!*buffer)
continue;
if (stat(buffer, &st) != 0)
continue;
}
...
}
--


After Sundararaj's patch it looked like this (just leaving out the lines
that his '#if 0' disabled):

--

if (stat(buffer, &st) == 0) {
int Link = 0;
if (S_ISLNK(st.st_mode)) {
if (LinkLevel > MAX_LINK_LEVEL) {
isyslog("max link level exceeded - not scanning %s", *buffer);
continue;
}
if (stat(buffer, &st) != 0)
continue;
}
...
}
--


Reducing this to the stat() calls results in

--

if (stat(buffer, &st) == 0) {
...
if (stat(buffer, &st) != 0)
continue;
}
...
}
--


As you can see, 'buffer' is no longer modified between the two calls, so
they
will both return the same value. The code sequence is only entered if
the first
stat() call returns 0, so the second call will also return 0, and thus the
'continue' statement will never be executed.


Now I looked a bit closer, and noticed that the "first" call to stat is 
actually not to *stat*, but to *lstat* in vanilla vdr-1.7.23, so if you 
remove the call to the second one, could it be that you're not really 
cutting redundancy, maybe it actually makes a difference?


Lucian


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr 1.7.23: patch for handling symlinks in recordings directory as earlier

[Lucian Muresan]

On 13.02.2012 12:54, Klaus Schmidinger wrote:

On 13.02.2012 12:27, Lucian Muresan wrote:

On 13.02.2012 12:00, Klaus Schmidinger wrote:

[...]

Now I looked a bit closer, and noticed that the "first" call to stat
is actually not to *stat*, but to *lstat* in vanilla vdr-1.7.23, so if
you remove the call to the second one, could it be that you're not
really cutting redundancy, maybe it actually makes a difference?


Now you got me ;-)
I had switched back to 'stat()' instead of 'lstat()' and forgotten to
reintroduce
the 'lstat()'. Therefore I saw two identical calls to stat().
With the first call being lstat(), the second call to stat() is of
course necessary
for the following S_ISDIR() check.

Sorry for the confusion, and thanks for clarifying this.
So now this whole code sequence looks like this:

--

if (lstat(buffer, &st) == 0) {
int Link = 0;
if (S_ISLNK(st.st_mode)) {
if (LinkLevel > MAX_LINK_LEVEL) {
isyslog("max link level exceeded - not scanning %s", *buffer);
continue;
}
Link = 1;
if (stat(buffer, &st) != 0)
continue;
}


No problem at all, I'm glad it's now sorted out for the next developer 
version.


Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Channel 4 HD on Freesat

[Lucian Muresan]

Hi,

On 12.03.2012 00:41, Tony Houghton wrote:
> I can't get Channel 4 HD on Freesat with VDR 1.7.23-1. It just stays
> silent with the picture frozen on the previous channel, or "No signal".
> Any ideas?
> 
> This is my channels.conf entry:
> 
> Channel 4 
> HD;Freesat:11126:VC23M2O0S1:S28.2E:22000:2305=2:2307=NAR@4;2306=eng@106:2309:0:21200:2:2068:0

Works apparently well here with
Channel 4
HD;BSkyB:11126:VC23M5O35S1:S28.2E:22000:2305=27:2307=NAR@4;2306=eng@106:2309;2308=eng:0:21200:2:2068:0

received with a rather problematic TechnoTrend Budget S2-3200 with CI.


> Not much going on in syslog:

[...]

> Mar 11 23:33:38 htpc vdr: [2537] PMT scan idle
> Mar 11 23:33:38 htpc vdr: [2537] EEPG: FreeView Extended EPG detected on pid 
> f02.
> Mar 11 23:33:38 htpc vdr: [2537] Loading table 1 Filename 
> 
> Mar 11 23:33:38 htpc vdr: [2537] Loading table 2 Filename 
> 

Please forgive me for going off-topic, are you actually successfully
using the EEPG plugin without segfaults? If so, which version, what
sources? I dropped using it because it crashed my VDR every now and
then, therefore I missed to record Episode 6/7 of the Top Gear Series 18
which just ended this weekend on BBC HD... On this 6th episode the BBC
folks also surprisingly (for me) rescheduled the repeat on Thursday,
I've always thought they are on Mondays or Wednesdays...

Do you British folks, or more generally, Freesat viewers know of any
working alternatives to the EEPG plugin for the channels on S28.2E?

Regards,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] HDMI-CEC dvbhddevice - TV switches itself on continuously

[Lucian Muresan]

On 19.04.2012 14:50, Pim Zandbergen wrote:
[..]
> BTW, it would be cool if "shut down" VDR could be interpreted as
> shutdown just
> the hardware decoder part on the dvbhddevice, but leave the tuners running.
> I don't want my VDR box to be shut down for any reason, but stopping the
> hardware
> decoder when not viewing could possibly save some power and heat
> dissipation.

BTW, since power consumption and heat seems to concern you, just curious
if you have measured or happen to know how much power your AV receiver
and TV consumes when in standby since you set them up on HDMI-CEC.
AFAIK, most AV receivers suck more than 30-40W just because the HDMI
electronics has to be powered all times in order to have CEC working...

Regards,
Lucian


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] HDMI-CEC power consumption

[Lucian Muresan]

On 20.04.2012 00:42, Pim Zandbergen wrote:
> On 04/19/2012 11:39 PM, Lucian Muresan wrote:
>>
>> BTW, since power consumption and heat seems to concern you, just curious
>> if you have measured or happen to know how much power your AV receiver
>> and TV consumes when in standby since you set them up on HDMI-CEC.
>> AFAIK, most AV receivers suck more than 30-40W just because the HDMI
>> electronics has to be powered all times in order to have CEC working...
>>
>> Regards,
>> Lucian
>>
> 
> Good point. The IR receivers on the AV receiver and TV are also always on.
> Does HDMI-CEC in standby cause so much more power consumption?

Well, seems it does in most AV receiver makes, because the manufacturers
provide them mostly with one single power(ful) supply, there are some
Yamaha models with a separate (low) power supply just for the video
(HDMI-related) circuitry, they can achieve just 2-3W in standby with
HDMI-CEC... Anyway, it's an issue one shouldn't take for granted and
meet with decent skepticism, rather measure at the power outlet in the
given situation. The manufacturers are not likely to specify this in
their data sheets or manuals. Some models allow you to setup HDMI-CEC
only for the ARC from the TV and let power control or HDMI passthrough
disabled. But the latter two are also nice to have, unfortunately they
come at such cost...

Regards,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] ScaleVideo Discussion: API extension or custom service?

[Lucian Muresan]

Hi there,

let me start with the background of this, in the last few weeks, a very 
promising new true color skin raised some attention on the german 
speaking VDR-Portal, namely "nOpacity" ([1] and [2]). The layout of some 
of the screens quickly brought up the idea that it would be nice to have 
the video properly scaled to the available size (smaller than the actual 
screen), which I tried to already patch with some (but only some) 
success ([3]). The patch is based on an old hack, called "YaEPG patch", 
which introduces a member of type tArea in cOsd, which then can be 
filled with geometry information, whose "bpp" member is abused as a hint 
weather or not to scale by some skin or plugin which wants to scale down 
the video material, and you got it, it's as ugly as can be. The problems 
which we encountered where that the output plugin (in this case 
softhddevice) knows much more about the video material (like if it is 
for example 4:3 letterboxed, if the user selected some zooming, some 
cropping, and so on) than a skin or any other plugin can cope with, in 
order to get the video scaled right, and there are cases where the 
scaling is simply wrong. It is and should remain the job of the output 
plugin to do this right with all the information it has access to, other 
plugins should only have to ask them to "properly" scale inside an 
available rectangle, possibly with the hint to just scale (back) 
full-size of the output device (which could also be an X window).
Now, my question, is this issue worth an API extension in cDevice, for 
example something like


bool ScaleVideo(tArea availableRectangle);
bool ScaleVideoFullScreen();

which could return true only if the output plugin is capable of doing 
this, or should plugin developers rather agree upon a custom service 
which output plugins may provide and skins or other plugins may ask for?


Regards,
Lucian





[1]: 
http://www.vdr-portal.de/board1-news/board2-vdr-news/115810-announce-skin-nopacity/


[2]: 
http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/115977-nopacity-0-0-3/


[3]: 
http://www.vdr-portal.de/board1-news/board2-vdr-news/p1106087-announce-skin-nopacity/#post1106087


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] ScaleVideo Discussion: API extension or custom service?

[Lucian Muresan]

Hi Klaus,

On 28.11.2012 11:18, Klaus Schmidinger wrote:

On 28.11.2012 10:41, Lucian Muresan wrote:


[...]


I think this should be done by cDevice and not by some obscure "service"
plugin developers
happen to agree upon.

The interface I would suggest looks like this:

   virtual cRect cDevice::CanScaleVideo(const cRect &Rect,
eTextAlignment Alignment = taCenter) { return cRect::Null; }
   ///< Asks the output device whether it can scale the currently
shown video in such a way that
   ///< it fits into the given Rect. If the scaled video doesn't
exactly fit into Rect,
   ///< Alignment is used to determine how to align the actual
rectangle with the requested one.
   ///< The actual rectangle can be smaller, larger or the same size
as the given Rect.
   ///< Returns the rectangle that can actually be used when scaling
the video. A skin plugin
   ///< using this function should rearrange its content according
to the rectangle returned
   ///< from calling this function, and should especially be
prepared for cases where the
   ///< returned rectangle is way off the requested Rect, or even
Null. In such cases, the skin
   ///< may want to fall back to working with full screen video.
   ///< If this device can't scale the video, a Null rectangle is
returned (this is also the
   ///< default implementation).
   virtual void cDevice::ScaleVideo(const cRect &Rect = cRect::Null) {}
   ///< Scales the currently shown video in such a way that it fits
into the given Rect.
   ///< Rect must have been retrieved through a previous call to
CanScaleVideo().
   ///< If this device can't scale the video, nothing happens.
   ///< To restore full screen video, call this function with a Null
rectangle.

eTextAlignment is somewhat abused here, maybe we should rename that to a
more general eAlignment.
Since this API extension doesn't have any further impact on any existing
VDR functions, I would
be willing to add it even before version 2.0.


this is just, what can I say, great! Kudos for the proposals you made 
(they make A LOT of sense), and also for willing to quickly introduce it 
before 2.0!


Thank you,
Lucian


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [PATCH] vdr-xine-0.9.4 vdr-1.7.33 video scaling API (YAEPG-Hack now obsolete)

[Lucian Muresan]

Hi,

attached you'll find a patch against vdr-xine-0.9.4 that makes use of
the new video scaling API introduced in vdr-1.7.33, yielding correct
aspect ratio when scaling.

How can it be used? Well, have a look at yaepg-hd patched with [1], but
even more exciting when the video output plugin supports true color OSD
(unfortunately vdr-xine can do this only in non-X11-overlay mode) is the
new true color skin nOpacity [2].

BTW, Reinhard, do you still plan on maintaining vdr-xine? I was
wondering because the homepage of the plugin is no longer accessible...


[1]
https://github.com/lucianm/gen2ovl-googoo2/tree/master/media-plugins/vdr-yaepghd/files

[2]
http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/p1112090-nopacity-0-0-4/#post1112090


Regards & Happy Christmas,
Lucian

P.S. Just for convenience, I also attached the obligatory PmtParser Patch.
diff -Naur xine-0.9.4_orig/xineDevice.c xine-0.9.4/xineDevice.c
--- xine-0.9.4_orig/xineDevice.c2011-02-27 19:14:19.0 +0100
+++ xine-0.9.4/xineDevice.c 2012-12-22 18:42:36.389557075 +0100
@@ -1200,7 +1200,11 @@
   int pid = TsPid(Data);
   if (pid == 0)
 patPmtParser.ParsePat(Data, TS_SIZE);
+#if APIVERSNUM >= 10732
+  else if (patPmtParser.IsPmtPid(pid))
+#else
   else if (pid == patPmtParser.PmtPid())
+#endif
 patPmtParser.ParsePmt(Data, TS_SIZE);
   else if (pid == patPmtParser.Vpid())
   {
diff -Naur xine-0.9.4_orig/xineDevice.c xine-0.9.4/xineDevice.c
--- xine-0.9.4_orig/xineDevice.c2011-02-27 19:14:19.0 +0100
+++ xine-0.9.4/xineDevice.c 2012-12-23 22:06:02.578457473 +0100
@@ -4405,5 +4405,84 @@
   {
 return theXineDevice;
   }
+#if APIVERSNUM >= 10733
+  ///< Asks the output device whether it can scale the currently shown video in
+  ///< such a way that it fits into the given Rect, while retaining its proper
+  ///< aspect ratio. If the scaled video doesn't exactly fit into Rect, 
Alignment
+  ///< is used to determine how to align the actual rectangle with the 
requested
+  ///< one. The actual rectangle can be smaller, larger or the same size as the
+  ///< given Rect, and its location may differ, depending on the capabilities 
of
+  ///< the output device, which may not be able to display a scaled video at
+  ///< arbitrary sizes and locations. The device shall, however, do its best to
+  ///< match the requested Rect as closely as possible, preferring a size and
+  ///< location that fits completely into the requested Rect if possible.
+  ///< Returns the rectangle that can actually be used when scaling the video.
+  ///< A skin plugin using this function should rearrange its content according
+  ///< to the rectangle returned from calling this function, and should 
especially
+  ///< be prepared for cases where the returned rectangle is way off the 
requested
+  ///< Rect, or even Null. In such cases, the skin may want to fall back to
+  ///< working with full screen video.
+  ///< If this device can't scale the video, a Null rectangle is returned (this
+  ///< is also the default implementation).
+  cRect cXineDevice::CanScaleVideo(const cRect &Rect, int Alignment/* = 
taCenter*/)
+  {
+// first implementation: we can always scale, we're a soft device ;-), 
ignore alignment for now
+
+// so let's just remember what the next call to ScaleVideo should actually 
use as a rectangle
+// argument if called with cRect(-1,-1,-1,-1)
+vidWinRect = Rect;
+return vidWinRect;
+  }
 
+  ///< Scales the currently shown video in such a way that it fits into the 
given
+  ///< Rect. Rect should be one retrieved through a previous call to
+  ///< CanScaleVideo() (otherwise results may be undefined).
+  ///< Even if video output is scaled, the functions GetVideoSize() and
+  ///< GetOsdSize() must still return the same values as if in full screen 
mode!
+  ///< If this device can't scale the video, nothing happens.
+  ///< To restore full screen video, call this function with a Null rectangle.
+  void cXineDevice::ScaleVideo(const cRect &Rect/* = cRect::Null*/)
+  {
+const cRect * actualRect = &Rect;
+if (Rect == cRect(-1,-1,-1,-1)) {
+  // actual rectangle was stored here by the previous call to CanScaleVideo
+  actualRect = &vidWinRect;
+} else {
+  actualRect = &Rect;
+  // remember the value, just for the case we were called explicitly with 
a real value
+  vidWinRect = *actualRect;
+}
+// let our specialized code do the actual resizing / repositioning, get 
accurate parameters first
+int videoLeft, videoTop, videoWidth, videoHeight, videoZoomX, videoZoomY, 
osdWidth, osdHeight;
+double videoAspect, pixelAspect;
+m_xineLib.execFuncVideoSize(videoLeft, videoTop, videoWidth, videoHeight, 
videoZoomX, videoZoomY, &videoAspect);
+GetOsdSize(osdWidth, osdHeight, pixelAspect);
+tArea vidWinArea;
+vidWinArea.x1 = actualRect->X();
+vidWinArea.y1 = actualRect->Y();
+vidWinArea.x2 =

Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35

[Lucian Muresan]

On 12/29/2012 01:14 PM, Helmut Auer wrote:


If there is really a need for that special unsupported plugin, then
the best way
to go would be that at least one of all those distributions, who
currently
maintains that plugin, "republishes" it somewhere (AFAIR
projects.vdr-developer.org was invented for that?).

First step could be to apply all those patches that are required to
get the
plugin to work with current VDR *developer* versions.

If a plugin really is still needed by a bigger group of people, then it
definitively needs to be maintained at some *central* place. It
doesn't help if
every distribution creates their own patches. It's much better to
cooperate!


We are talking about > 100 Plugins. Maybe we can drop the half of these
but > 50 will be remaining ...



Nevertheless, hosting them on vdr-developer.org seems to be the best 
solution. If of those remaining, let's say, just the most wanted 10 to 
30% of the plugins would find some "adoptive parents" we would have a 
"win" situation. Those maintainers do not have to commit themselves 
alone to keep the pace with vdr developer versions, rather several 
skilled users even, who are able to contribute patches now and then and 
also are interested in the specific plugins may jointly try to maintain 
the plugins they are interested in and would be otherwise orphaned, in 
that central place. Of course, distribution maintainers can join them 
too, but really, the central place is really important here, and the 
fact that such a plugin may be adapted to new API changes not just by 
one single person who might not be available for that at some point.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35

[Lucian Muresan]

On 12/29/2012 01:07 PM, Manuel Reimer wrote:
[..]

In context of a plugin, VDR should be something like a "backend
library". It has to be installed, but the plugin should be compilable
from *everywhere* as long as the "backend library" is there.

This is why pkg-config was invented and this is how all other software
projects out there work.

VDR, so far, had a *very* special Makefile system. Running "make", even
if VDR is installed, just failed and the lack of "make install" causes
the need that plugin authors have to document how to *manually* complete
the installation as the Makefile won't do it and can't do it.

So nearly every plugin needs its own way to compile it from outside of a
VDR source (that most distributions don't even install, as they only
install the "include-directory") and even more plugins need special
handling to get it equipped with all those additional files, they need
to operate (images, stillpictures, ...).

With the new system, anything should work with two commands:

make

followed by

make DESTDIR=... install


This is actually more or less the scenario vdr and all of its plugins 
have always been *installed* on Gentoo, which in a certain way shifts 
the actual execution of the actions the package maintainer defined, to 
the user's machine, by compiling from a plugin source directory (sort of 
transparently, when the user actually "installs" with the help of the 
package manager). Maintainers only had a great deal of work to override 
what the native VDR build system did (or in most cases, simply omitted 
to do) mainly on installation. So yes, being able to just issue the 
commands mentioned above by Manuel, would simplify things a lot...


[..]



So why not freeze VDR development at all?

Or maybe, the people, that so much like the current status of VDR 1.7.33
(or maybe 1.7.31?) just roll their own fork and do whatever with it, so
innovation in the core VDR project can go on?

Just remember: "Nobody likes change except a wet baby"


So, +1 from me, to switch to the new system, which should make everyone 
happy, those building like Klaus everything from one big source tree and 
not even installing, and those wanting to be able to build from the 
plugin source only. Since you mentioned the wet baby, c'mon folks, let's 
cut this baby shit whining and just get over it, let Klaus do the 
change, isn't it wonderful enough he's willing to listen to opinions?


Just my 2 cents,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35

[Lucian Muresan]

On 01/01/2013 09:52 PM, Lars Hanisch wrote:
[...]

  I must confess that normally threads at a forum are easier to read and 
understand as mailing list threads in any
mail-archive. First you have to found such an archive (or have to know that 
something like that even exists) and then
it's complicated to search or even browse the archive (monthly indexes etc.).


Just FYI, even if many ML readers may do something similar already. One 
can actually disable email delivery of this ML and read it through nntp 
at news.gmane.org, this way one can more easily have an overview of 
threads, and even with email delivery disabled, still post directly to 
the ML instead of nntp.


Lucian


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [PATCH] (v2) vdr-xine-0.9.4 vdr-1.7.33 video scaling API (YAEPG-Hack now obsolete)

[Lucian Muresan]

Hello,

On 12/25/2012 09:02 PM, Reinhard Nissl wrote:

Hi,


[..]


I appreciate your patches and will have a look at it during the next days.


after some clarifications of the new API, thanks to Klaus and "Johns" 
the author of the softhddevice output device plugin, here is a new 
version of the scaling API patch for vdr-xine.


Regards,
Lucian
diff -Naur xine-0.9.4_orig/xineDevice.c xine-0.9.4/xineDevice.c
--- xine-0.9.4_orig/xineDevice.c	2011-02-27 19:14:19.0 +0100
+++ xine-0.9.4/xineDevice.c	2013-01-03 21:54:57.585874032 +0100
@@ -4405,5 +4405,83 @@
   {
 return theXineDevice;
   }
+#if APIVERSNUM >= 10733
+  ///< Asks the output device whether it can scale the currently shown video in
+  ///< such a way that it fits into the given Rect, while retaining its proper
+  ///< aspect ratio. If the scaled video doesn't exactly fit into Rect, Alignment
+  ///< is used to determine how to align the actual rectangle with the requested
+  ///< one. The actual rectangle can be smaller, larger or the same size as the
+  ///< given Rect, and its location may differ, depending on the capabilities of
+  ///< the output device, which may not be able to display a scaled video at
+  ///< arbitrary sizes and locations. The device shall, however, do its best to
+  ///< match the requested Rect as closely as possible, preferring a size and
+  ///< location that fits completely into the requested Rect if possible.
+  ///< Returns the rectangle that can actually be used when scaling the video.
+  ///< A skin plugin using this function should rearrange its content according
+  ///< to the rectangle returned from calling this function, and should especially
+  ///< be prepared for cases where the returned rectangle is way off the requested
+  ///< Rect, or even Null. In such cases, the skin may want to fall back to
+  ///< working with full screen video.
+  ///< If this device can't scale the video, a Null rectangle is returned (this
+  ///< is also the default implementation).
+  cRect cXineDevice::CanScaleVideo(const cRect &Rect, int Alignment/* = taCenter*/)
+  {
+// first implementation: we can always scale, we're a soft device ;-), ignore alignment for now
+
+// we need to store the value for the case we have to call ScaleVideo ourselves in vdr-xine
+vidWinRect = Rect;
+return vidWinRect;
+  }
+
+  ///< Scales the currently shown video in such a way that it fits into the given
+  ///< Rect. Rect should be one retrieved through a previous call to
+  ///< CanScaleVideo() (otherwise results may be undefined).
+  ///< Even if video output is scaled, the functions GetVideoSize() and
+  ///< GetOsdSize() must still return the same values as if in full screen mode!
+  ///< If this device can't scale the video, nothing happens.
+  ///< To restore full screen video, call this function with a Null rectangle.
+  void cXineDevice::ScaleVideo(const cRect &Rect/* = cRect::Null*/)
+  {
+// refresh stored value
+vidWinRect = Rect;
+// let our specialized code do the actual resizing / repositioning, get accurate parameters first
+int videoLeft, videoTop, videoWidth, videoHeight, videoZoomX, videoZoomY, osdWidth, osdHeight;
+double videoAspect, pixelAspect;
+m_xineLib.execFuncVideoSize(videoLeft, videoTop, videoWidth, videoHeight, videoZoomX, videoZoomY, &videoAspect);
+GetOsdSize(osdWidth, osdHeight, pixelAspect);
+tArea vidWinArea;
+vidWinArea.x1 = vidWinRect.X();
+vidWinArea.y1 = vidWinRect.Y();
+vidWinArea.x2 = vidWinRect.X() + vidWinRect.Width();
+vidWinArea.y2 = vidWinRect.Y() + vidWinRect.Height();
+if (vidWinRect == cRect::Null) {
+// will just resize to full size
+vidWinArea.bpp = 0;
+} else {
+vidWinArea.bpp = 12;
+// make corrections
+double aspectFactor = (double(osdWidth) / double(osdHeight)) / videoAspect;
+int output_width = vidWinRect.Height() * (videoAspect * aspectFactor);
+int output_height = vidWinRect.Width() / (videoAspect * aspectFactor);
+if (double(vidWinRect.Width())/double(vidWinRect.Height()) > videoAspect * aspectFactor) {
+output_height = vidWinRect.Height();
+vidWinArea.x1 += (vidWinRect.Width() - output_width) / 2;
+}
+else if (double(vidWinRect.Width())/double(vidWinRect.Height()) < videoAspect * aspectFactor) {
+output_width = vidWinRect.Width();
+vidWinArea.y1 += (vidWinRect.Height() - output_height) / 2;
+}
+vidWinArea.x2 = vidWinArea.x1 + output_width;
+vidWinArea.y2 = vidWinArea.y1 + output_height;
+}
+m_xineLib.SetVideoWindow(videoWidth, videoHeight, vidWinArea);
+  }
+
+  const cRect & cXineDevice::GetScaleRect()
+  {
+// just return the stored value
+return vidWinRect;
+  }
 
+#endif // APIVERSNUM >= 10733
 };
diff -Naur xine-0.9.4_orig/xineDevice.h xine-0.9.4/xineDevice.h
--- xine-0.9.4_orig/xineDevice.h	2011-02-27 15:28:58.0 +0100
+++ xine-

[vdr] updated ro_RO.po [was: Call for translations for VDR version 2.0.0]

[Lucian Muresan]

Hi Klaus,

On 09.02.2013 15:35, Klaus Schmidinger wrote:
> VDR is now approaching version 2.0.0, so this might be a good time
> for translators to complete the internationalized texts.
[...]
> Please base your work on the latest version of these files in VDR 1.7.37
> and send me proper patches.

this is really good news. Attached you'll find the updated Romanian
translation.

Thank _you_ for the VDR!
Lucian
diff -Naur vdr-1.7.37_orig/po/ro_RO.po vdr-1.7.37/po/ro_RO.po
--- vdr-1.7.37_orig/po/ro_RO.po 2013-02-09 14:56:59.0 +0100
+++ vdr-1.7.37/po/ro_RO.po  2013-02-09 23:01:24.0 +0100
@@ -2,22 +2,21 @@
 # Copyright (C) 2008 Klaus Schmidinger 
 # This file is distributed under the same license as the VDR package.
 # Paul Lacatus , 2002
-# Lucian Muresan , 2004, 2005, 2006, 2008, 
2010, 2011, 2012
+# Lucian Muresan , 2004 - 2006, 2008, 2010 - 
2013
 #
 msgid ""
 msgstr ""
-"Project-Id-Version: VDR 1.7.12\n"
+"Project-Id-Version: VDR 1.7.37\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2013-02-03 16:46+0100\n"
-"PO-Revision-Date: 2012-11-05 01:28+0100\n"
-"Last-Translator: Lucian Muresan \n"
+"PO-Revision-Date: 2013-02-09 23:01+0100\n"
+"Last-Translator: Lucian Muresan \n"
 "Language-Team: Romanian \n"
 "Language: ro\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"X-Poedit-Language: Romanian\n"
-"X-Poedit-Country: ROMANIA\n"
+"X-Generator: Poedit 1.5.5\n"
 
 msgid "*** Invalid Channel ***"
 msgstr "*** Canal invalid ***"
@@ -414,7 +413,7 @@
 msgstr "Info"
 
 msgid "Key$Play/Pause"
-msgstr ""
+msgstr "Redare/Pauză"
 
 msgid "Key$Play"
 msgstr "Redare"
@@ -682,7 +681,7 @@
 msgstr "Timer"
 
 msgid "Button$Record"
-msgstr "Înregistr."
+msgstr "Înregistrează"
 
 msgid "Button$Switch"
 msgstr "Comută"
@@ -733,7 +732,7 @@
 msgstr "Redare"
 
 msgid "Button$Rewind"
-msgstr "Înapoi"
+msgstr "De la capăt"
 
 msgid "Recordings"
 msgstr "Înregistrări"
@@ -760,7 +759,7 @@
 msgstr "niciodată"
 
 msgid "skin dependent"
-msgstr "dep. de skin"
+msgstr "dependent de skin"
 
 msgid "always"
 msgstr "întotdeauna"
@@ -1105,10 +1104,10 @@
 msgstr "Arată timpul rămas"
 
 msgid "Setup.Replay$Progress display time (s)"
-msgstr ""
+msgstr "Durata afișării indicatorului de progres (s) "
 
 msgid "Setup.Replay$Pause replay when setting mark"
-msgstr ""
+msgstr "Pauză la punerea marcajului de montaj"
 
 msgid "Setup.Replay$Resume ID"
 msgstr "Identificator continuare"
@@ -1132,10 +1131,10 @@
 msgstr "Timeout la introducerea canalului (ms)"
 
 msgid "Setup.Miscellaneous$Remote control repeat delay (ms)"
-msgstr ""
+msgstr "Întârzierea repetării semnaluilui telecomenzii (ms)"
 
 msgid "Setup.Miscellaneous$Remote control repeat delta (ms)"
-msgstr ""
+msgstr "Diferența repetării semnaluilui telecomenzii (ms)"
 
 msgid "Setup.Miscellaneous$Initial channel"
 msgstr "Canalul de pornire"
@@ -1188,7 +1187,7 @@
 msgstr "Stop"
 
 msgid "Button$Resume"
-msgstr "Continuare"
+msgstr "Continuă redarea"
 
 #. TRANSLATORS: note the leading blank!
 msgid " Cancel editing"
@@ -1216,7 +1215,7 @@
 msgstr "Nu mai sunt receptoare DVB disponibile pentru înregistrare!"
 
 msgid "Pausing live video..."
-msgstr "Trec în pauză emisiunea transmisă..."
+msgstr "Înregistrez emisiunea transmisă..."
 
 msgid "Delete timeshift recording?"
 msgstr "Şterg înregistrarea pentru vizionare decalată?"
@@ -1229,7 +1228,7 @@
 msgstr "Nu s-au pus marcaje de montaj pentru această înregistrare"
 
 msgid "No editing sequences defined!"
-msgstr ""
+msgstr "Nu s-au definit secvențe pentru montaj!"
 
 msgid "Can't start editing process!"
 msgstr "Nu pot porni montajul înregistrării!"
@@ -1240,11 +1239,16 @@
 msgid "Editing process already active!"
 msgstr "Montajul înregistrării este deja activ!"
 
-msgid "FileNameChars$ 
abcdefghijklmnopqrstuvwxyz0123456789-.,#~\\^$[]|()*+?{}/:%@&"
+msgid ""
+"FileNameChars$ abcdefghijklmnopqrstuvwxyz0123456789-.,#~\\^$[]|()*+?{}/:%@&"
 msgstr " aăâbcdefghiîjklmnopqrsştţuvwxyz0123456789-.,#~\\^$[]|()*+?{}/:%@&"
 
-msgid "CharMap$ 
0\t-.,1#~\\^$[]|()*+?{}/:%@&\tabc2\tdef3\tghi4\tjkl5\tmno6\tpqrs7\ttuv8\twxyz9"
-msgstr " 
0\t-.,1#~\\^$[]|()*+?{}/:%@&\taăâbc2\tdef3\tghiî4\tjkl5\tmno6\tpqrsş7\ttţuv8\twxyz9"
+msgid ""
+"CharMap$ 0\t-.,1#~\\^$[]|()*+?{}/:%@&"
+"\tabc2\tdef3\tghi4\tjkl5\tmno6\tpqrs7\ttuv8\twxyz9"
+msgstr ""
+" 0\t-.,1#~\\^$[]|()*+?{}/:%@&"
+"\taăâbc2\tdef3\tghiî4\tjkl5\tmno6\tpqrsş7\ttţuv8\twxyz9"
 
 msgid "Button$ABC/abc"
 msgstr "ABC/abc"
@@ -1256,7 +1260,7 @@
 msgstr "Inserează"
 
 msgid "Plugin"
-msgstr "Plugin (modul adiţional)"
+msgstr "Plugin"
 
 msgid "Up/Dn for new location - OK to move"
 msgstr "Sus/Jos pentru noua locaţie - OK pentru a muta"
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Request to translate cdplayer-plugin

[Lucian Muresan]

Hi Uli,

On 17.02.2013 16:43, Ulrich Eckhardt wrote:
[...]
> ro_RO: 41 translated messages, 6 untranslated messages.
[...]

attached you'll find an update to the romanian translation.

Regards, Lucian

diff -Naur cdplayer_orig/po/ro_RO.po cdplayer/po/ro_RO.po
--- cdplayer-1.1.7_orig/po/ro_RO.po 2013-02-17 16:24:59.0 +0100
+++ cdplayer-1.1.7/po/ro_RO.po  2013-02-17 17:56:09.0 +0100
@@ -7,11 +7,10 @@
 msgstr ""
 "Project-Id-Version: VDR 1.7.x\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2013-02-17 16:18+0100\n"
-"PO-Revision-Date: 2013-02-16 23:07+0100\n"
+"POT-Creation-Date: 2013-02-12 13:53+0100\n"
+"PO-Revision-Date: 2013-02-17 17:56+0100\n"
 "Last-Translator: Lucian Muresan \n"
 "Language-Team: Romanian\n"
-"Language: \n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
@@ -24,7 +23,7 @@
 msgstr "Compozitor"
 
 msgid "Disk ID"
-msgstr ""
+msgstr "Identificator disc"
 
 msgid "Genre"
 msgstr "Gen"
@@ -33,7 +32,7 @@
 msgstr "Mesaj"
 
 msgid "Isrc"
-msgstr ""
+msgstr "Cod ISRC"
 
 msgid "Performer"
 msgstr "Interpret"
@@ -45,7 +44,7 @@
 msgstr "Titlu"
 
 msgid "Upc Ean"
-msgstr ""
+msgstr "Cod UPC / EAN"
 
 msgid "Invalid"
 msgstr "Invalid"
@@ -54,10 +53,10 @@
 msgstr "Info mărime"
 
 msgid "Info1"
-msgstr ""
+msgstr "Info1"
 
 msgid "Info2"
-msgstr ""
+msgstr "Info2"
 
 msgid "Can not open"
 msgstr "Nu pot deschide device-ul"
@@ -87,7 +86,7 @@
 msgstr "Informații disc"
 
 msgid "Song Information"
-msgstr "Informații cântec"
+msgstr "Informații piesă"
 
 msgid "random"
 msgstr "aleator"
@@ -129,7 +128,7 @@
 msgstr "Ieșire"
 
 msgid "CD-Player"
-msgstr ""
+msgstr "CD Player"
 
 msgid "Max CD speed"
 msgstr "Viteza CD maximă"
@@ -153,7 +152,7 @@
 msgstr "Utilizează simboluri GraphTFT"
 
 msgid "Back Key"
-msgstr "Tasta \"ÃŽnapoi\""
+msgstr "Tasta 'ÃŽnapoi'"
 
 msgid "OK Key"
-msgstr "Tasta \"OK\""
+msgstr "Tasta 'OK'"
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Call for translations for VDR version 2.0.0: one more string needed

[Lucian Muresan]

Hi Klaus,

On 04.03.2013 15:30, Klaus Schmidinger wrote:
> While implementing an option to turn on/off sorting folders first in the
> Recordings
> menu, one more string was necessary and needs to be translated:
> 
>   "Always sort folders first"
> 
> The patch for this new option can be found at
> 
>  
> http://www.vdr-portal.de/board17-developer/board97-vdr-core/p1130105-feature-request-sortierreihenfolge-verzeichnisse-zuerst-im-osd-unter-aufnahmen/#post1130105
> 
> 
> but it would suffice if you could just send me (or post here) the
> translation of the string shown above.

this is the romanian translation:

"Sortează întotdeauna directoarele la început"

Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [PATCH] MaxThemeName and MaxSkinName limit

[Lucian Muresan]

Hi,

thank you Klaus for holding up your release plan for 2.0!
However, I hope this minor patch won't be too much trouble for you, as
it only increases the limit of 16 to theme and skin names, letting them
be NAME_MAX as almost any files, since these names can also be involved
in file names.
Was there a good reason to limit them at 16 only, perhaps the fear that
the name won't fit on the OSD? I don't really think someone would really
make use of as many as 255 characters for this. On the other hand, users
just encountered crashes with plugins which (unfortunately, yet) have
themes of their own, when just adding a new theme with a name longer
than 16 and at the same time the original plugin author relied on
MaxThemeName when allocating the string length.
So, what do you think, easy to adopt?

Regards,
Lucian
diff -Naur vdr-1.7.42_orig/config.h vdr-1.7.42/config.h
--- vdr-1.7.42_orig/config.h2013-03-16 16:12:14.0 +0100
+++ vdr-1.7.42/config.h 2013-03-23 16:57:48.378701000 +0100
@@ -53,8 +53,8 @@
 #define MAXOSDHEIGHT 1200
 
 #define MaxFileName NAME_MAX // obsolete - use NAME_MAX directly instead!
-#define MaxSkinName 16
-#define MaxThemeName 16
+#define MaxSkinName NAME_MAX // obsolete - use NAME_MAX directly instead!
+#define MaxThemeName NAME_MAX // obsolete - use NAME_MAX directly instead!
 
 // Basically VDR works according to the DVB standard, but there are 
countries/providers
 // that use other standards, which in some details deviate from the DVB 
standard.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] NVOD feeds

[Lucian Muresan]

Hi,

recently I started to give some maintenance to a plugin [1] which seemed
to be orphaned for a while and needed by several, as I knew from the
German VDR-Portal, subscribers of Sky Germany. The plugin was called
Arghdirector, it is a fork of an even older one, called "director",
possibly because of the marketing name used by Sky Germany and former
Premiere for their NVOD feeds at that time.
Nowadays they call this "Sky select", so that's for now the new name of
the plugin. We even had some discussion on vdr-portal on the new name,
someone even suggested NVOD [2], others emphasized this would be only
usable to german Sky subscribers, and I only recently found out that
NVOD is actually established terminology [3].
Just by chance, I discovered that the plugin actually also triggers on
several of the plethora of channels called "NVOD" which seems to be
mostly  if not all from Sky UK, so the plugin might even work with them,
allowing to find on which of the feeds what show is just about to start.
So my question to Sky UK subscribers, would you care to give it a try,
would this plugin be of any use for you? Well, I do not know of any
alternatives (in terms of VDR plugins) you might be using, please
mention them if that's the case. If you find the plugin useful also for
you, I'm considering yet again renaming it to something more generic,
like "NVOD Feeds" and the german translation can still sound "Sky
Select" as that's the current name of this feature at Sky DE...

Regards,
Lucian


[1] http://linuxtv.org/vdrwiki/index.php/SkySelectFeeds-plugin
[2]
http://www.vdr-portal.de/board17-developer/board21-vdr-plugins/p1132335-arghdirector-noch-gepflegt/#post1132335
[3] http://en.wikipedia.org/wiki/Video_on_demand

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [PATCH] MaxThemeName and MaxSkinName limit

[Lucian Muresan]

On 23.03.2013 22:50, Klaus Schmidinger wrote:
> On 23.03.2013 17:14, Lucian Muresan wrote:
>> Hi,
>>
>> thank you Klaus for holding up your release plan for 2.0!
>> However, I hope this minor patch won't be too much trouble for you, as
>> it only increases the limit of 16 to theme and skin names, letting them
>> be NAME_MAX as almost any files, since these names can also be involved
>> in file names.
>> Was there a good reason to limit them at 16 only, perhaps the fear that
>> the name won't fit on the OSD? I don't really think someone would really
>> make use of as many as 255 characters for this. On the other hand, users
>> just encountered crashes with plugins which (unfortunately, yet) have
>> themes of their own, when just adding a new theme with a name longer
>> than 16 and at the same time the original plugin author relied on
>> MaxThemeName when allocating the string length.
> 
> Those are bugs in the plugins and should be fixed there.
> Or is this something that can also happen in the core VDR?

So be it, it's quite easy for plugins to ignore MaxThemeName or allocate
such a string length, say 4*MaxThemeName as long as they mange their own
themes...
I did not test how VDR reacts when it is fed with a theme or a skin with
a name longer than 16 (seems those are the only 2 places in VDR where
you use those, on statically allocating the strings holding the theme
and the skin, which you store to and load from setup...

>> So, what do you think, easy to adopt?
> 
> Well, for one, now is definitely not the right time for a change like this!
> And furthermore, skin and theme names should be short. What sense does it
> make to call a theme something like "This is the theme that implements a
> range
> of colors from 400 nanometers to 700 nanometers", when you could just plain
> simple call it "rainbow"? ;-)

Not necessary to exaggerate with such an hilarious example, you're
getting near to sarcastic and missing the point, let's just take your
short example in a more realistic scenario:

rainbow_1920x1080.theme
rainbow_1280x768.theme

just because there still are plugins having to use skins which are
resolution-dependent, so those names aren't at all that uncommonly long
like your example, yet they try to carry some little useful information.
And still, one of them is already violating the limit (if we do not
consider the file extension). Of course, you might say, take out the
'_', or the 'x', I could answer I'd rather take out some letter out of
"rainbow", and so on, you see what I'm trying to point out, it's hitting
a limit difficult to argue...

> So I'd say the limit is there for a reason, and should stay there.

Could you at least please, name it?

Regards,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [PATCH] MaxThemeName and MaxSkinName limit

[Lucian Muresan]

Hi,

On 24.03.2013 11:00, Klaus Schmidinger wrote:
[...]
>> rainbow_1920x1080.theme
>> rainbow_1280x768.theme
> 
> Themes are all about colors - why do they even need to mention resolutions?
> 
> Besides, skins should react dynamically on the current OSD size.

as mentioned right after giving the example, that's the way some of the
themes unfortunately work, but that's due to the technology they use
(they are displaying background images and the like, which are
pre-generated for that exact resolution, possibly a dynamic scaling
won't look right in those cases). On the other hand, I'm completely with
you, they should behave better, but they are not my skins, nor do I
particularly use them, I was only trying to help the users a bit, which
add such skins without touching any code...

>> just because there still are plugins having to use skins which are
>> resolution-dependent, so those names aren't at all that uncommonly long
>> like your example, yet they try to carry some little useful information.
>> And still, one of them is already violating the limit (if we do not
>> consider the file extension). Of course, you might say, take out the
>> '_', or the 'x', I could answer I'd rather take out some letter out of
>> "rainbow", and so on, you see what I'm trying to point out, it's hitting
>> a limit difficult to argue...
>>
>>> So I'd say the limit is there for a reason, and should stay there.
>>
>> Could you at least please, name it?
> 
> Keeping the names *short* ;-)

Seriously ;) ?

> This limit has been in there for almost ten years and has apparently
> never been a problem (at least not to my knowledge). I can't change that
> so close before the release of a major new version - even if it might
> look like it won't break anything. You can get back to me with this after
> version 2.0.0 is out. Version 2.1.x can pick up such changes again...

That's fair enough and also ok with me, thanks.

Regards,
Lucian


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] New Makefile system

[Lucian Muresan]

Hi,

On 24.03.2013 13:24, Helmut Auer wrote:
[...]
>>> There's nothing to find anymore, I had to debug crashes of a plugin
>>> (not my own) which were caused by migrating to the new makefile,
>>> because cflags and c++flags were differnet.
>>
>> I can't imagine, that this is caused by a changed Makefile.
>>
> There are lots of things that you can't imagine ;)
> 
>> Which plugin are you refering to?
>>
> softhddevice and live Plugin.
> There was a mismatch between c an c++ flags and this was surely caused
> by the new makefile system :)
> 
> 
>>> I searched for the segfault in the code but the reason was the make,
>>> and that costs me some days.

I could give you another example, Christopher, of which Makefile was
migrated by yourself, with exactly the consequence pointed out by
Helmut, I only don't think we're allowed to mention that plugin here, so
just remember, 3 months ago, "Issue #18" of that Plugin on Github...

Regards, Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] New Makefile system

[Lucian Muresan]

On 24.03.2013 14:10, Christopher Reimer wrote:
> Am 24.03.2013 13:51, schrieb Lucian Muresan:
>> Hi,
>>
>> On 24.03.2013 13:24, Helmut Auer wrote:
>> [...]
>>>>> There's nothing to find anymore, I had to debug crashes of a plugin
>>>>> (not my own) which were caused by migrating to the new makefile,
>>>>> because cflags and c++flags were differnet.
>>>>
>>>> I can't imagine, that this is caused by a changed Makefile.
>>>>
>>> There are lots of things that you can't imagine ;)
>>>
>>>> Which plugin are you refering to?
>>>>
>>> softhddevice and live Plugin.
>>> There was a mismatch between c an c++ flags and this was surely
>>> caused
>>> by the new makefile system :)
>>>
>>>
>>>>> I searched for the segfault in the code but the reason was the
>>>>> make,
>>>>> and that costs me some days.
>>
>> I could give you another example, Christopher, of which Makefile was
>> migrated by yourself, with exactly the consequence pointed out by
>> Helmut, I only don't think we're allowed to mention that plugin here,
>> so
>> just remember, 3 months ago, "Issue #18" of that Plugin on Github...
>>
>> Regards, Lucian
>>
> 
> Even before Issue 18 was fixed it worked flawlessly on Archlinux.

Well, and therefore you concluded it ought to work on any system, but
that's not necessarily true.
I wonder, do you use vanilla VDR or a patched VDR on Archlinux? Gentoo
uses the extended patch, it's just the way it is, users are just glad
that this is possible for them, and when doing so it is absolutely
necessary that all of the plugins are built with the exact same DEFINES
introduced by the patches, and that happens to well, happen or not, in
the plugin Makefile.
Ignoring them, just because of thinking "plugin A does not use any of
the patches X, Y or Z, so I don't need the DEFINES" is likely to give
you a working plugin only if you are _very_ lucky, otherwise unexpected
crashes will bite you.
To take this out of the fortune domain one would have to either analyze
with some true coverage techniques that absolutely no patched code is
called in a specific plugin (and by that I mean, VDR internal code is
also calling itself, so that's why an analysis is not trivial), or to
just make sure, give the DEFINES to all of the plugins. So it turns out
that the new Makefiles are just adopted in a different way by people,
and also there was no clear directive where to store the DEFINES in case
of patches, in /usr/include/vdr/Make.conf (or how it should be called
lately), or right into the cxxflags and cxflags in vdr.pc...

So you see, the whole process caused also a lot of confusion, also
because each Makefile contains the whole logic, I would have placed the
logic in a central, pseudo-Makefile shipped with the vdr sources, and
generated some kind of Makefile stubs for the plugins, including the
central one for the logic, and providing plugin-specifics (even custom,
additional targets) through a well defined interface. That way, once the
interface would have been established, the central logic could have been
adapted fromtime to time without having to ever touch plugin Makefiles
again. Unfortunatley, for me it just wasn't the right time to interfere
in the makefile discussions when they were elaborated. I might come back
with a drop-in proposal by the the time of the next developent series,
quite possible that having only a few lines makefiles would be
interesting for someone...

Regards, Lucian


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] New Makefile system

[Lucian Muresan]

On 24.03.2013 14:15, Tobi wrote:
> On 24.03.2013 13:51, Lucian Muresan wrote:
> 
>>>>> I searched for the segfault in the code but the reason was the make,
>>>>> and that costs me some days.
> 
> There's not very much which go wrong. As long as the plugins are
> compiled with -fPIC and -D_FILE_OFFSET_BITS=64 there should be no ABI
> incompatibilities.
> 
> I can understand your frustration - changing a myriad of packages is an
> annoying task (been there - done that! :-)
> 
> But after all I think the new Makefile is much better and for the first
> time works out of the box with the standard Debian packaging tools
> (which require *FLAGS, DESTDIR, PREFIX and so on).
> 
> Packaging is much easier right now as you basically only have to do:
> 
> make all PREFIX=/ ...
> make install DESTDIR=...
> 
> And for plugins that haven't migrated to the new Makefile the only
> change I had to do was:
> 
> export CXXFLAGS += $(shell pkg-config vdr --variable=cxxflags)
> 
> The only thing I'm missing is a CPPFLAG in the Makefiles, which I hope
> gets added in 2.0+X.
> 
> But I'm talking from the Debian/Ubuntu perspective only - things might
> be slighty more complicated in Gentoo.

Well, see my other answer to Christopher, where I explained what can go
wrong (which of course, doesn't have to happen if using plain vanilla VDR).

Regards,
Lucian


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] New Makefile system

[Lucian Muresan]

On 25.03.2013 17:36, Manuel Reimer wrote:
> The best way to resolve this would be to switch to separate patches as
> soon as possible. The extension patch is broken by design, as it causes
> the VDR to place header files with conditional compiling expressions. So
> the API changes based on the DEFINES even after installation!

Quite possible that it is broken by design, but if used carefully (i.E.
giving all of these DEFINES to all of the plugins built against that
specific patched VDR version, should give all of them the same API) it
works.

> The extension patch already patches *many* files in the VDR source, so
> as it requires the DEFINES to be exported, it should also patch the
> Makefile to export them in the cflags variable in vdr.pc.

So it does on Gentoo, but the problem was with various plugin makefiles
actually, which claimed to be "new style" but for whatever reason the
persons who adapted them to the new style removed including $(PLGCFG) or
circumvented it by mistake. That is also due to some acrobatic
conditional constructs in some desperate tries to keep the same
makefiles also backwards compatible with a whole lot of older VDR
series, instead of just providing the old makefile under another name
just as it was.

So it takes two to tango, plugin Makefiles also have to use those
DEFINES, it's not enough that they are provided in some place everyone
has agreed upon. That was my point actually, while Klaus is doing a
great job, some of the plugin authors failed to do so, which is also
only human, I only would have given them less opportunity to fail...

Regards,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] New Makefile system

[Lucian Muresan]

On 26.03.2013 17:19, Manuel Reimer wrote:
> Lucian Muresan wrote:
>> So it does on Gentoo, but the problem was with various plugin makefiles
>> actually, which claimed to be "new style" but for whatever reason the
>> persons who adapted them to the new style removed including $(PLGCFG) or
>> circumvented it by mistake.
> 
> *Wrong way* to fix this! If the "extension patch" requires plugins to
> get the DEFINES, then it should patch the VDR Makefile to forcefully add
> them to vdr.pc, so Plugin-Makefiles get them even if no "PLGCFG" is used.

The Gentoo Gentoo VDR maintainer eventually fixed it in _some_ way
achieving this (don't think there is only *your* solution to the
problem, by fixing the makefile), namely have the DEFINES listed in the
flags in vdr.pc.

Your definition of *wrong way* holds only in the unfortunately now
already established scenario that everyone is free to use the template
plugin makefile generated by the newplugin script solely as an
orientation, and omit anything which doesn't *seem* to break things in
his own use case, and of course, the use case "make LCLBLD=1". So while
the new makefile system as a whole (with vdr.pc and so) _is indeed
better_ than the old one, it just still allows too many possibilities
for the plugin developer to break things for others [1], or even to get
himself into some trouble [2], or just be lazy and not provide complete
install targets [3].

So I just want to fight this fake belief which some people (I do not
mean Klaus by that, who did not make this up by himself, but responded
to and consulted people) try to establish, that the new makefile system
is near to perfect and covers everything. I'm also not with those people
who denigrate it entirely, just wanted to say it has some flaws, it
should be allowed to do so without being slapped by every second reply,
and can only re-iterate that I'm sorry I did not have the time to tell
my opinion earlier.

Best regards, looking forward for the 2.1 series...
Lucian


[1] the already discussed DEFINES situation;

[2] for example, an empty LIBS variable, also used in the correct order
(after OBJS) in the final link statement, just for the case that a
plugin have use them, it could have spared some authors of putting it in
wrong order and then wonder about unresolved symbols;

[3] completely missing usage of RESDIR which also can be read out of
vdr.pc and any sample commented out target using it, that way many
plugin authors continue just to ignore it even if their plugin actually
comes with lots of non-program files we all call resources, which have
to be installed under a certain pattern, only modifiable by the RESDIR
variable. Could continue with CACHEDIR, but that applies to less
plugins... You will say this is up to packagers, but actually since
there are these modifiable variables, and also some files have to comply
to a certain directory pattern, this can be well prepared by the plugin
author, it's only about his plugin, and the packagers just have to
divert those variables specific to their distribution and the plugin
would still work without further modifications, and not fight with doing
missing targets for so many plugins...


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] New Makefile system

[Lucian Muresan]

On 27.03.2013 23:07, Lars Hanisch wrote:
>> Could continue with CACHEDIR, but that applies to less
>> > plugins...
>  I understand CACHEDIR as a location for runtime generated data which doesn't 
> necessarily survive reboots of the vdr. I
> don't think it should be the target of any installation files. Or am I wrong?

You are not wrong at all, but I actually mean less installing files into
CACHEDIR but rather creating the subdirectory structure there, as it is
expected by that plugin (sometimes it involves the plugin name,
sometimes it's more generic, like for example several plugins sharing
so-called epg-images which are fetched by some script and can be used
for displaying by different plugins, so they would rather use a
directory name not necessarily bound to some plugin name...). But then,
again, I can agree it's arguable if that's not better a runtime option
anyway...

Regards,
Lucian


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR Power Button Daemon 0.0.1

[Lucian Muresan]

On 28.03.2013 09:44, YUP wrote:
> OK, thanks, it's good to know such a thing before installing on
> Archlinux. Did you mean set "PowerKeyIgnoreInhibited" to "yes" in
> /etc/systemd/logind.conf ? BTW, could you post a link to your bug report
> on systemd?

What about using this with non-systemd init, does it just work by
actually deactivating or rather replacing acpid? If that's the case, I
could give it a try, but have few more questions:

- I just had a quick look in the git repository, could not find a config
file sample, how should that look like?

- Could the command trigger pattern (the 4 presses on the power button
within a certain time) also be configurable in that config file?

- Is it feasible to extend the functionality to one or two more patterns
to be able to issue different shutdown commands (like a custom
hibernation script for example)?

Regards,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [PATCH] TT6400 dvbhddevice ScaleVideo aspect ratio correction

[Lucian Muresan]

Hi,

I wrote a patch for the ScaleVideo implementation in the dvbhddevice,
for keeping the actual aspect ratio of the video material when scaling.
It was tested by users at vdr-portal.de which also reported the
distortions (I don't own such a device), and they said it works [1]. You
can test it with the nOpacity skin and/or with the upcoming
yaepghd-0.0.4 plugin [2].

Regards,
Lucian


[1]
http://www.vdr-portal.de/board1-news/board2-vdr-news/p1137059-announce-nopacity-0-1-0/#post1137059
[2] http://sourceforge.net/projects/vdryaepghd/files/

>From 1591c4cdc50dda35c52902ce46851ab57291351c Mon Sep 17 00:00:00 2001
From: Lucian Muresan 
Date: Fri, 5 Apr 2013 11:21:25 +0200
Subject: [PATCH] vdr-2.0.0 dvbhdffdevice ScaleVideo Aspect v3

---
 PLUGINS/src/dvbhddevice/dvbhdffdevice.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/PLUGINS/src/dvbhddevice/dvbhdffdevice.c 
b/PLUGINS/src/dvbhddevice/dvbhdffdevice.c
index dd7ace5..7a05ccb 100644
--- a/PLUGINS/src/dvbhddevice/dvbhdffdevice.c
+++ b/PLUGINS/src/dvbhddevice/dvbhdffdevice.c
@@ -579,9 +579,24 @@ void cDvbHdFfDevice::ScaleVideo(const cRect &Rect)
 double osdPixelAspect;
 
 GetOsdSize(osdWidth, osdHeight, osdPixelAspect);
+
+// make corrections
+double osdAspect = double(osdWidth) / double(osdHeight);
+cRect corRect(Rect);
+corRect.SetWidth(Rect.Height() * osdAspect);
+corRect.SetHeight(Rect.Width() / osdAspect);
+if (double(Rect.Width())/double(Rect.Height()) > osdAspect) {
+corRect.SetHeight(Rect.Height());
+corRect.SetX(Rect.X() + (Rect.Width() - corRect.Width()) / 2);
+}
+else if (double(Rect.Width())/double(Rect.Height()) < osdAspect) {
+corRect.SetWidth(Rect.Width());
+corRect.SetY(Rect.Y() + (Rect.Height() - corRect.Height()) / 2);
+}
+
 mHdffCmdIf->CmdAvSetVideoWindow(0, true,
-Rect.X() * 1000 / osdWidth, Rect.Y() * 1000 / osdHeight,
-Rect.Width() * 1000 / osdWidth, Rect.Height() * 1000 / osdHeight);
+corRect.X() * 1000 / osdWidth, corRect.Y() * 1000 / osdHeight,
+corRect.Width() * 1000 / osdWidth, corRect.Height() * 1000 / 
osdHeight);
 }
 }
 
-- 
1.8.1.msysgit.1

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [PATCH] TT6400 dvbhddevice ScaleVideo aspect ratio correction

[Lucian Muresan]

On 08.04.2013 10:36, Klaus Schmidinger wrote:
> Am I getting this right? cDvbHdFfDevice::ScaleVideo() apparently sets the
> video window in units of 1/1000 of the OSD width and height, respectively.
> Since this resolution is less than the possible acual OSD width or height,
> the rectangle actually used in this function might be different from the
> one given in the Rect parameter. While this is, of course, allowed,
> shouldn't
> the same calculations also be done in cDvbHdFfDevice::CanScaleVideo(),
> to return
> the correct rectangle to the skin?

I think if the actual cDvbHdFfDevice::CanScaleVideo implementation would
have really calculated something, it should have only converted
internally to whatever needed (1/1000 in this case), and back to Osd
pixel dimensions before returning the value. Since it doesn't (as it
just returns the input rectangle, possibly because the device "is" able
to handle any size within the limits, maybe nothing should be changed.
Or maybe checking against the limits could be done, changed the size to
a reasonable default (like Null for full size) and log an error if the
input size wasn't within the Osd limits.
Udo's variant looks well, but for all this maybe Andreas Regel should
also be consulted. Btw, I sent him a PM on vdr-portal.de, he did not
react so far.

Regards,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Which epg for Sky UK

[Lucian Muresan]

On 14.04.2013 00:17, Tony Houghton wrote:
> On Sat, 13 Apr 2013 23:06:58 +0200
> "dplu (free)"  wrote:
> 
>> Le samedi 13 avril 2013 21:48:44 Tony Houghton a écrit :
>>>
>>> Has eepg been updated to support Freeview HD and fix the memory leak?
>>
>> Good question, eepg create it's own file on conf directory , not seen memory 
>> leak but did not spend my life on Freesat channels 
>> I report it works even for channels like ITV HD, Channel 4 HD or BBC HD on 
>> 28.2E, it is more simple than patching vdr itself (even with internal 
>> huffman 
>> coded tables)
> 
> Yes, it worked well enough apart from the problems I mentioned above.
> But the original maintainer hasn't commented on those and apparently the
> code isn't in a very good state for someone else to take over.
> 
> Someone raised the possibility of rewriting the patch as a plugin, which
> I would like, but I don't know how to write VDR plugins.

The current git version of eepg tends to crash on me at least one if not
twice a day with vdr-2.0.0, after it used to work well for several
weeks. I do not know what changed the behaviour, since I cannot find any
useful crash dump...
BTW, where is the most current freeview patch?

Cheers,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [ANNOUNCE] yaepghd-0.0.4

[Lucian Muresan]

Hello all,

version 0.0.4 of yaepghd is available, see the links at the end of the
message. These are the changes since the last community edition version
published in the vdr-portal.de forum:

2013-04-14: Version 0.0.4

- at least for now, this version is no longer hosted at
vdr-developer.org  as the old project (after ver. 0.0.1) still seems to
be abandoned, check the README file for the links
- switched to ScaleVideo API introduced with vdr-1.7.33 and dropped old
patch
- switched MAkefile to new style introduced with vdr-1.7.34
- integrated extra plugin themes found in the community edition thread
at vdr-portal.de
- updated anthra_1280 theme with the one from "pc_medusa" at vdr-portal.de
- added romanian translation
- added nOpacity_1920_darkblue theme contributed by "Saman" at vdr-portal.de
- added setup option to simulate returning back to the menu position
where yaepghd was entered from, adapted from a patch contributed by
"Saman" at vdr-portal.de



For now, the code is hosted here:
https://github.com/lucianm/vdr-plugin-yaepghd

Release tarball:
http://sourceforge.net/projects/vdryaepghd/files/0.0.4/vdr-yaepghd-0.0.4.tgz/download

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Which epg for Sky UK

[Lucian Muresan]

On 14.04.2013 00:46, VDR User wrote:
> I use eepg as well, although for a different provider. It's been very
> stable for me without any crashes since git from Dec 2012. I also
> haven't noticed any memory leak. The only downtime I've had has been
> when updating VDR every time a new version is released.
> 
> If you do know of a real problem with the current git of eepg, why not
> contact the author?

Well, the only indications that the plugin might have a problem is that
the crash is gone when no longer loading the plugin, and a log entry
before the crash, that a Sky.DE channel is renamed to something, and the
next crash if I remember well, back "from something" to the other name.
And I actually do not watch Sky.DE as I don't have a subscription, I'm
using the eepg plugin for the BBC and other FTA british channels I
occasionaly watch, but I also have 2 tuner cards, seems that it happens
while one of them switches channels in the background. I will try to get
the log entries again and then open a ticket...

Regards,
Lucian


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr and raspberry pi

[Lucian Muresan]

On 30.05.2013 15:36, Torgeir Veimo wrote:
> There's now experimental support for libxine, so you can use
> xineliboutput with vdr-sxfe. See here;
> http://www.vdr-portal.de/board18-vdr-hardware/board98-arm-co/118588-rasperry-pi-xine-plugin/
> 
> Google translate should let get the gist of details required to try it out.

FYI, a note before bothering to try to translate the information:
So far, the author didn't care to release any sources, so if you do not
use the "right" distribution with exact matching libxine and libc on
your raspberry, you're out of luck at this moment.
However, he sort of promised to release sources at some point, but doing
the way he does, feedback will be limited to those who can effectively
try his blob, and he denies himself help from developer-skilled users,
which means it can take some long time until his sources will be in
shape so he accepts to release them...

Lucian


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] converting ts to mkv

[Lucian Muresan]

On 26.05.2014 13:41, Tony Houghton wrote:
[...]
> It's better to use mkvmerge (or ffmpeg etc for mpeg2) to remultiplex
> properly. You still don't have to transcode the streams so it doesn't
> take much longer. Players can't tell how long (in terms of time) TS
> files are, or how any point in the file corresponds to time for seeking
> etc.

Also, mkvmerge removes NALUs from h264 if there are any, on the fly with
no noticeable overhead.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [PATCH] vdr-2.1.7 Romanian translation update

[Lucian Muresan]

Hello Klaus,

here is a patch with the updated Romanian translation for vdr-2.1.7.

Best regards,
Lucian
From 08cad82c45a466cac1db25346353f0accd0f0f90 Mon Sep 17 00:00:00 2001
From: Lucian Muresan 
Date: Sun, 12 Oct 2014 23:21:48 +0200
Subject: [PATCH] vdr 2.1.7 Romanian translation update

---
 po/ro_RO.po | 112 ++--
 1 file changed, 56 insertions(+), 56 deletions(-)

diff --git a/po/ro_RO.po b/po/ro_RO.po
index 5616348..f4cbab8 100644
--- a/po/ro_RO.po
+++ b/po/ro_RO.po
@@ -9,14 +9,14 @@ msgstr ""
 "Project-Id-Version: VDR 2.0.0\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2015-01-12 15:40+0100\n"
-"PO-Revision-Date: 2013-02-09 23:01+0100\n"
-"Last-Translator: Lucian Muresan \n"
+"PO-Revision-Date: 2015-01-21 22:34+0100\n"
+"Last-Translator: Lucian Muresan \n"
 "Language-Team: Romanian \n"
 "Language: ro\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"X-Generator: Poedit 1.5.5\n"
+"X-Generator: Poedit 1.6.9\n"
 
 msgid "*** Invalid Channel ***"
 msgstr "*** Canal invalid ***"
@@ -79,13 +79,13 @@ msgid "StreamId"
 msgstr "Identificator Stream"
 
 msgid "Pilot"
-msgstr ""
+msgstr "Pilot"
 
 msgid "T2SystemId"
-msgstr ""
+msgstr "ID sistem T2"
 
 msgid "SISO/MISO"
-msgstr ""
+msgstr "SISO/MISO"
 
 msgid "Starting EPG scan"
 msgstr "Pornesc achiziţia EPG"
@@ -575,10 +575,10 @@ msgid "Sid"
 msgstr "Sid"
 
 msgid "Nid"
-msgstr ""
+msgstr "Nid"
 
 msgid "Tid"
-msgstr ""
+msgstr "Tid"
 
 msgid "Channel settings are not unique!"
 msgstr "Parametrii canalului nu sunt univoci!"
@@ -741,71 +741,71 @@ msgid "CAM not responding!"
 msgstr "CAM-ul nu reacţionează!"
 
 msgid "Edit path"
-msgstr ""
+msgstr "Editează calea"
 
 msgid "Folder"
-msgstr ""
+msgstr "Director"
 
 msgid "This folder is currently in use - no changes are possible!"
-msgstr ""
+msgstr "Acest director tocmai este accesat - nu sunt posibile modificări!"
 
 #, c-format
 msgid "Move entire folder containing %d recordings?"
-msgstr ""
+msgstr "Mut întregul director conținând %d înregistrări?"
 
 msgid "Error while moving folder!"
-msgstr ""
+msgstr "Eroare la mutarea directorului!"
 
 msgid "Edit recording"
-msgstr ""
+msgstr "Editează înregistrarea"
 
 msgid "This recording is currently in use - no changes are possible!"
-msgstr ""
+msgstr "Această înregistrare tocmai este accesată - nu sunt posibile 
modificări!"
 
 msgid "Button$Cancel cutting"
-msgstr ""
+msgstr "Anulează tăierea"
 
 msgid "Button$Stop cutting"
-msgstr ""
+msgstr "Oprește tăierea"
 
 msgid "Button$Cancel moving"
-msgstr ""
+msgstr "Anuleaza mutarea"
 
 msgid "Button$Stop moving"
-msgstr ""
+msgstr "Oprește mutarea"
 
 msgid "Button$Cancel copying"
-msgstr ""
+msgstr "Anulează copierea"
 
 msgid "Button$Stop copying"
-msgstr ""
+msgstr "Oprește copierea"
 
 msgid "Button$Cut"
-msgstr ""
+msgstr "Taie"
 
 msgid "Button$Delete marks"
-msgstr ""
+msgstr "Șterge marcajele"
 
 msgid "Recording vanished!"
-msgstr ""
+msgstr "Înregistrarea a dispărut!"
 
 msgid "Edited version already exists - overwrite?"
-msgstr ""
+msgstr "Deja există o versiune editată - o suprascriu?"
 
 msgid "Error while queueing recording for cutting!"
-msgstr ""
+msgstr "Eroare la punerea în coada pentru tăiere!"
 
 msgid "Delete editing marks for this recording?"
-msgstr ""
+msgstr "Șterg marcajele de editare pentru această înregistrare?"
 
 msgid "Error while deleting editing marks!"
-msgstr ""
+msgstr "Eroare la ștergerea marcajelor de editare!"
 
 msgid "Error while changing priority/lifetime!"
-msgstr ""
+msgstr "Eroare la schimbarea priorității/timpului de păstrare!"
 
 msgid "Error while changing folder/name!"
-msgstr ""
+msgstr "Eroare la schimbarea directorului/numelui!"
 
 msgid "Recording info"
 msgstr "Detaliile înregistrării"
@@ -826,7 +826,7 @@ msgid "Dele

[vdr] [PATCH] vdr-2.1.7 Romanian translation update

[Lucian Muresan]

Hello Klaus,

good to hear about the plans on releasing a new stable version on the
15th anniversary of VDR. Congratulations, keep up this this wonderful
piece of work!
Here is a patch with the updated Romanian translation for vdr-2.1.8.

Best regards,
Lucian
From ce27d9abcdeaeeab2f5db53b57b568456cea59bf Mon Sep 17 00:00:00 2001
From: Lucian Muresan 
Date: Sun, 1 Feb 2015 22:59:36 +0100
Subject: [PATCH] vdr 2.1.8 Romanian translation update

---
 po/ro_RO.po | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/po/ro_RO.po b/po/ro_RO.po
index 25766cf..f9a2d37 100644
--- a/po/ro_RO.po
+++ b/po/ro_RO.po
@@ -9,7 +9,7 @@ msgstr ""
 "Project-Id-Version: VDR 2.0.0\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2015-01-30 13:14+0100\n"
-"PO-Revision-Date: 2015-01-21 22:34+0100\n"
+"PO-Revision-Date: 2015-02-01 22:55+0100\n"
 "Last-Translator: Lucian Muresan \n"
 "Language-Team: Romanian \n"
 "Language: ro\n"
@@ -22,7 +22,7 @@ msgid "*** Invalid Channel ***"
 msgstr "*** Canal invalid ***"
 
 msgid "CAM activated!"
-msgstr ""
+msgstr "CAM activat!"
 
 msgid "Channel not available!"
 msgstr "Canal indisponibil"
@@ -1115,16 +1115,16 @@ msgstr "CAM pregătit"
 
 #. TRANSLATORS: note the leading blank!
 msgid " (activating)"
-msgstr ""
+msgstr " (activez)"
 
 msgid "CAM"
 msgstr "CAM"
 
 msgid "Button$Cancel activation"
-msgstr ""
+msgstr "Anulează activarea"
 
 msgid "Button$Activate"
-msgstr ""
+msgstr "Activează"
 
 msgid "Button$Menu"
 msgstr "Meniu"
@@ -1139,7 +1139,7 @@ msgid "Can't open CAM menu!"
 msgstr "Nu pot deschide meniul CAM"
 
 msgid "Can't activate CAM!"
-msgstr ""
+msgstr "Nu pot activa CAM-ul!"
 
 msgid "CAM is in use - really reset?"
 msgstr "CAM-ul este in folosinţă - totuşi resetez?"
@@ -1235,19 +1235,19 @@ msgid "Setup.Replay$Pause replay when setting mark"
 msgstr "Pauză la punerea marcajului de editare"
 
 msgid "Setup.Replay$Pause replay when jumping to a mark"
-msgstr ""
+msgstr "Pauză după săritura la marcaj"
 
 msgid "Setup.Replay$Skip edited parts"
-msgstr ""
+msgstr "Săritură peste părțile editate"
 
 msgid "Setup.Replay$Pause replay at last mark"
-msgstr ""
+msgstr "Pauză la ultimul marcaj"
 
 msgid "Setup.Replay$Binary skip initial value (s)"
-msgstr ""
+msgstr "Valoarea inițială (s) pentru săritul \"binar\" al marcajelor"
 
 msgid "Setup.Replay$Binary skip timeout (s)"
-msgstr ""
+msgstr "Timeout (s) pentru săritul \"binar\" al marcajelor"
 
 msgid "Setup.Replay$Resume ID"
 msgstr "Identificator continuare"
-- 
1.9.4.msysgit.0

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restart of frontend

[Lucian Muresan]

On 14.02.2015 19:53, VDR User wrote:
>>  At yavdr we use this feature to start X and vdr in parallel and attach 
>> softhddevice when X is ready.
>>  And you can restart X when softhddevice is detached.
> 
> Do you happen to know approx. how much startup time is saved doing this?

Another case where one would want to use that way to start softhddevice
is to be able to leave VDR running even when detaching softhddevice
output to switch to xbmc/kodi or anything else, to be able to let VDR do
recordings if necessary, or quickly switch back (of course, on a HTPC
setup all from the remote control).

Regards,
Lucian


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Which DVB-S / DVB-S2 cards are recommended?

[Lucian Muresan]

Hello,

On 12.08.2015 09:28, jori.hamalai...@teliasonera.com wrote:
> My recommendation hardware-wise would be Vuplus Duo2 or similar
> Linux/'Enigma' set-top box (STB). I think VDR is ported to Vuplus (and
> similar STBs platforms) if you want to run VDR. But the information of this
> seems to be in German.

This sounds very interesting, can you please give some links to good
information on this, even in German? Is it rather some WIP status (you
stated you "think" VDR is ported), or does it actually work?

Best regards,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [PATCH] sorted sources.conf by continous azimuth

[Lucian Muresan]

Hello,

while trying to setup DiseqC and scanning to my new Wetek Play OpenELEC
edition which uses VDR as a backend, I found out that the order of
satellites which is read from VDR's sources.conf is a bit weird.

This might not be too obvious when one is used to only look at that file
when editing a customized diseqc.conf for example, but it shows clearly
when the list read out of this file is displayed in a graphical,
scrollable control in which you look for a certain satellite (no
comments or groups lilke Europe, Atlantic, Asia, America displayed in
that case).
While the list starts with ascending "E" positions from Europe over to
Asia, ending the Asia part with "S177W   NSS 9", it then turns back to
Western Europe, S0.8W in order to continue again with ascending "W"
positions towards Atlantic and America groups.

In my patch I'm proposing a re-ordering of "W" positions in descending
degree order, that way also the groups "Atlantic" and "America" can be
swapped and the result is a list ordered by continous azimuth, I think
it's more intuitive when scrolling through such a list with the remote
control.
The patch is done against vdr-2.2.0, but I think it would apply to 2.3.1
as well, but haven't tried myself.


Best regards,
Lucian
From 6174e3ca547958437db8771c1eba09d1d49d4efe Mon Sep 17 00:00:00 2001
From: Lucian Muresan 
Date: Sat, 12 Dec 2015 17:36:40 +0100
Subject: [PATCH] sources.conf sorted by continuous azimuth

---
 sources.conf | 140 +--
 1 file changed, 70 insertions(+), 70 deletions(-)

diff --git a/sources.conf b/sources.conf
index ad4131c..1af174f 100644
--- a/sources.conf
+++ b/sources.conf
@@ -109,80 +109,80 @@ S172E   Eutelsat 172A
 S180E   Intelsat 18
 S177W   NSS 9
 
-# Atlantic
-
-S0.8W   Intelsat 10-02
-S1W Thor 5/6
-S4W Amos 2/3
-S5W Eutelsat 5 West A
-S7W Nilesat 101/201 & Eutelsat 7 West A
-S8W Eutelsat 8 West A/C
-S11WExpress AM44
-S12.5W  Eutelsat 12 West A
-S14WExpress A4
-S15WTelstar 12
-S18WIntelsat 901
-S20WNSS 7
-S22WSES 4
-S24.5W  Intelsat 905
-S27.5W  Intelsat 907
-S30WHispasat 1D/1E
-S31.5W  Intelsat 25
-S34.5W  Intelsat 903
-S37.5W  NSS 10 & Telstar 11N
-S40.5W  SES 6
-S43WIntelsat 11
-S45WIntelsat 14
-S50WIntelsat 1R
-S53WIntelsat 23
-S55.5W  Intelsat 805
-S58WIntelsat 21
-S61WAmazonas 2/3
-
 # America
 
-S61.5W  Echostar 16
-S63WTelstar 14R
-S65WStar One C1
-S67WAMC 4
-S70WStar One C2
-S72WAMC 6
-S72.7W  Nimiq 5
-S75WStar One C3
-S77WQuetzSat 1
-S82WNimiq 4
-S83WAMC 9
-S84WBrasilsat B4
+S139W   AMC 8
+S137W   AMC 7
+S135W   AMC 10
+S133W   Galaxy 15
+S131W   AMC 11
+S129W   Ciel 2
+S127W   Galaxy 13/Horizons 1
+S125W   Galaxy 14 & AMC 21
+S123W   Galaxy 18
+S121W   Echostar 9/Galaxy 23
+S119W   Echostar 14 & DirecTV 7S
+S118.8W Anik F3
+S116.8W SatMex 8
+S114.9W SatMex 5
+S113W   SatMex 6
+S111.1W Anik F2
+S110W   DirecTV 5 & Echostar 10/11
+S107.3W Anik F1R/G1
+S105W   AMC 15/18
+S103W   AMC 1
+S101W   DirecTV 4S/8 & SES 1
+S99.2W  Galaxy 16
+S97WGalaxy 19
+S95WGalaxy 3C
+S93.1W  Galaxy 25
+S91WGalaxy 17 & Nimiq 6
+S89WGalaxy 28
+S87WSES 2
 S85WAMC 16
 S85.1W  XM 3
-S87WSES 2
-S89WGalaxy 28
-S91WGalaxy 17 & Nimiq 6
-S93.1W  Galaxy 25
-S95WGalaxy 3C
-S97WGalaxy 19
-S99.2W  Galaxy 16
-S101W   DirecTV 4S/8 & SES 1
-S103W   AMC 1
-S105W   AMC 15/18
-S107.3W Anik F1R/G1
-S110W   DirecTV 5 & Echostar 10/11
-S111.1W Anik F2
-S113W   SatMex 6
-S114.9W SatMex 5
-S116.8W SatMex 8
-S118.8W Anik F3
-S119W   Echostar 14 & DirecTV 7S
-S121W   Echostar 9/Galaxy 23
-S123W   Galaxy 18
-S125W   Galaxy 14 & AMC 21
-S127W   Galaxy 13/Horizons 1
-S129W   Ciel 2
-S131W   AMC 11
-S133W   Galaxy 15
-S135W   AMC 10
-S137W   AMC 7
-S139W   AMC 8
+S84WBrasilsat B4
+S83WAMC 9
+S82WNimiq 4
+S77WQuetzSat 1
+S75WStar One C3
+S72WAMC 6
+S72.7W  Nimiq 5
+S70WStar One C2
+S67WAMC 4
+S65WStar One C1
+S63WTelstar 14R
+S61.5W  Echostar 16
+
+# Atlantic
+
+S61WAmazonas 2/3
+S58WIntelsat 21
+S55.5W  Intelsat 805
+S53WIntelsat 23
+S50WIntelsat 1R
+S45WIntelsat 14
+S43WIntelsat 11
+S40.5W  SES 6
+S37.5W  NSS 10 & Telstar 11N
+S34.5W  Intelsat 903
+S31.5W  Intelsat 25
+S30WHispasat 1D/1E
+S27.5W  Intelsat 907
+S24.5W  Intelsat 905
+S22WSES 4
+S20WNSS 7
+S18WIntelsat 901
+S15WTelstar 12
+S14WExpress A4
+S12.5W  Eutelsat 12 West A
+S11WExpress AM44
+S8W Eutelsat 8 West A/C
+S7W Nilesat 101/201 & Eutelsat 7 West A
+S5W Eutelsat 5 West A
+S4W Amos 2/3
+S1W Thor 5/6
+S0.8W   Intelsat 10-02
 
 S360E   Any satellite
 
-- 
1.9.5.msysgit.0

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [ANNOUNCE] vdrcm-0.0.2 - interactive console dialogs script for managing VDR configuration files

[Lucian Muresan]

Hi all,

vdrcm-0.0.2 - the VDR Config Manager for managing VDR configuration
files is now available at [1].

What is this all about? You may remember the ARGSDIR feature introduced
in VDR last year, which allows to store all the CLI parameters supplied
to VDR and its plugins spread over several files with the extension
*.conf in INI style, located for example in the /etc/vdr/conf.d
directory. They only need to contain INI sections named like [vdr] or
[plugin-name], followed by one option per line, then vdr launched with
no CLI-parameters at all will read these files in their file name order.

Just like other implementations (for example vdrctl used by yaVDR),
vdrcm will actually symlink config files from a pool directory
/etc/vdr/conf.avail to ARGSDIR, when it enables a plugin, or delete the
symlink only, when disabling it. It also lets you define the explicit
order of the plugins, by prefixing the symlinks with a number, or fires
up the text editor defined in the EDITOR environment variable, and all
this interactivlely in a CLI console, by using whiptail or dialog, see
sreenshots at [2]. Note that the screenshots are from version 0.0.1,
running with dialog, now I noticed that whiptail looks a lot better and
is now preferred if both are present on the system.

There is also a non-interactive pure CLI-mode supporting enabling or
disabling a plugin by its name, and promoting the order of a plugin
before another one, by the index before re-ordering. These CLI-options
should be suitable for writing a true vdr Plugin for managing plugins,
which should need to call these commands with setuid in order to be able
to execute them, and scan the directories for refreshing the list of
available/active/inactive plugins in the OSD. There were such type of
plugins in the past, but they were too distribution-specific. The
ARGSDIR-feature would allow any distribution to use this type of
VDR/plugins configuration, therefore also the usage of the same
management tools for them. I'm planning to write such a plugin in the
near future, as spare time will permit it.

The runtime dependencies of vdrcm are quite basic:
- which
- coreutils
- util-linux
- grep
- pkg-config (optional, see README for a workaround when missing)
- whiptail or dialog (optional if only the CLI-mode is used).

For more information and a short visual usage summary, check the
README.md at the homepage.

Have fun,
Lucian





[1](Homepage) https://github.com/lucianm/vdrcm
[2](Screenshots)
https://github.com/lucianm/vdrcm/wiki/Short-visual-usage-summary
[3](Releases) https://github.com/lucianm/vdrcm/releases


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Upnp plugin

[Lucian Muresan]

On 29.09.2016 14:59, Peer Oliver Schmidt wrote:
> Isn't the UPnP plugin solely for the purpose to use UPnP renderes with
> VDR recordings and stuff, and not outside media files?!

The UPnP Plugin also has a "sub-plugin" for other media files, but I
never got that one working, maybe it isn't even finished. Accessing live
TV and recordings used to work, but I do not use it anymore due to
insanely heavy load it puts on my VDR machine...

Greetings,
Lucian


___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Supertennis HD on 13°E, is it gone?

[Lucian Muresan]

Hello folks,

I thought I'd try to ask here, is it only me having problems to receive
the italian FTA channel Supertennis HD from Hotbird 13°E, or did they
just ceased broadcasting over sattelite lately?
According to the Lyngsat list they should still be there:
http://www.lyngsat.com/tvchannels/it/Super-Tennis.html
They also seem to broadcast a SD variant on 12,5°W, for which I would
have to redo the entire setup of my multifeed antenna, but first I would
like to know if it's really worth trying that.
Anybody knows something on what happened to them?

Best regards,
Lucian

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Re: VDRAdmin-AM with UTF-8 support?

[Lucian Muresan]

Jose Alberto Reguero wrote:

El Martes, 27 de Marzo de 2007, Harald Milz escribió:

Hi,

is anyone working on a UTF-8 version of VDRadmin-AM? I'm using vdr with the
UTF8 patch (de and ru) and need to always select UTF8 manually in the
browser to avoid seeing the à stuff. Looking at the html files in
template/default/, I see everything is hardcoded in iso-8859-1, but that
should be a configuration option. Setting LANG=de_DE.utf8 doesn't help, it
is silently ignored.

Anyone?

THX.


I run:

sed -i -e s/ISO-8859-1/UTF-8/g *.html

in the template/default/ directory.


Andreas Mair already adopted my UTF-8 patch for the vdradmin locales, 
months and versions ago. It patches the makefile and adds targets for 
generating the UTF-8 locales out of the stock ones. For more info, check 
this thread: http://www.linuxtv.org/pipermail/vdr/2006-July/010116.html


Regards,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] OT: "Pop around the clock" concerts all day on 3sat

[Lucian Muresan]

Hello folks,

did some of you, which can receive "3sat" also forgot, like me, they're 
broadcasting lots of good concerts today, all day?
Well, I just remembered during the Chris Rea concert and started to 
record, I guess I'll schedule all of the remaining ones. They're listed 
in order of broadcasting here: 
http://www.3sat.de/3sat.php?http://www.3sat.de/poparoundtheclock_index.html 
right now "Cyndi Lauper & Friends" is recording...
Now, is it legal or not, to exchange records which where broadcasted FTA 
and everyone COULD record?

Anyone recorded the ones in the morning?
Is this all some matter for VIDEGOR (haven't used it, but I guess I 
could set it up after finishing...)?


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Re: A few observations on the vdr project

[Lucian Muresan]

Klaus Schmidinger wrote:
> On 05/11/2007 09:25 AM, Ludwig Nussel wrote:
>> Klaus Schmidinger wrote:
>>> On 05/10/07 20:04, Udo Richter wrote:
 ...
 VDR development would speed up, if Klaus would delegate more work to
 other talented coders, and doing more review instead of coding most of
 it himself.
>>> Well, right now I'm dealing with the UTF-8 stuff, which is something
>>> I myself don't need at all. But unfortunately the patch(es) for this
>>> can't just be applied as it, because from what I've seen so far there
>>> it is assumed that the whole program is totally going UTF-8 - which it
>>> is *not*. I still want to be able to run it on a pure and clean iso8859-1
>>> system. So I have to painstakingly go through the whole thing and take care
>>> that it only does UTF-8 if so requested - and that's a lot more work than 
>>> just
>>> applying a patch...
>> What's wrong with vdr using UTF-8 internally if it makes the code simpler?
>> Offhand I could only imagine two places where using a different external
>> encoding would be required and that's file names and tty i/o. Stuff like
>> epg.data and svdrp should better use UTF-8 as you don't need to add extra 
>> meta
>> data options to specify the encoding.
> 
> It's very simple: I don't like it!
> The two languages I can handle can be perfectly well represented with 
> iso8859-1,
> so I just don't want to have to go through all the hassle with UTF-8.
> To me, a character is a character is a byte is a byte. Period.
> 
> Now, I do see that there are people out there who can't represent their
> language with single byte character sets, or want to be able to handle
> more languages than a single character set can cope with, so I am going
> to make VDR able to handle UTF-8. But only in a way that allows (at least)
> me to completely turn this stuff off. Whenever I install a new version

Isn't that constraint going to add too much unnecessary overhead to the
code? I guess you'd be then forced to take care of handling both
requirements forever, with every future version. Is that really what you
want, only to satisfy the "I don't like it" reason? I mean, you're
already doing a compromise at least, and a lot of us salute this, I'm
only wondering if it wouldn't actually make your life easier if
supporting just one of 2 things you want to support anyway, the
complicated one, UTF-8, and the hassle-free one, non-utf-8. Since you're
willing to support UTF-8, the other one is in my opinion, just extra
work from now on, slowing down development (God beware, I'm not tryin'
to push you)...

> of SUSE Linux, the first this I always do is turn off UTF-8. I just don't
> want it and don't need it.
> 
> Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] softdevice with menu&audio but no video

[Lucian Muresan]

Stefan Lucke wrote:
> Quoting Darren Wilkinson:
> 
>> Torgeir Veimo wrote:
>>> On 27 Jun 2007, at 18:32, Darren Wilkinson wrote:
>>>
>>>> The problem
>>>> is that although I can hear the channel playing and I can see and use
>>>> the vdr menus using softdevice I can't view the actual program wether or
>>>> not it's live or recorded.
>>> Ae you using Xv output? It's prob the wrong colour key used for the
>>> overlay. Search the softdevice devel for a fix.
>>>
>>> --Torgeir Veimo
>>> [EMAIL PROTECTED]
>>>
>> I forgot to mention that I'm using DirectFB only.
>>
> 
> And you forgot to mention which hardware you are using.
> With DirectFB we need hardware YUV -> RGB conversion support.
> 
> Plain fb output mode should run on any hw, but requires some
> more CPU power.
> 
> Stefan Lucke

This looks so very similar to the problem which occured to me some 2 
months ago (similar hardware and video output method): 
http://lists.berlios.de/pipermail/softdevice-devel/2007q2/002841.html
As I didn't have too much time to look for the cause, I'm still at 
vdr-1.4.6 and using xineliboutput (working well), but now that I've 
catched up with reading few things on the ML which seems interesting to 
me, I'll soon try the latest vdr-1.5 as it now supports UTF8.

Lucian Muresan

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] gettext in 1.5.x (was: vdr-1.5.3 - issue with translations out of plugins)

[Lucian Muresan]

Hi Klaus,

Klaus Schmidinger wrote:
> On 06/13/07 00:21, [EMAIL PROTECTED] wrote:
>> unfortunately this patches do not fix Transtation problems complete.
>> i still have segmentation faults for example with softdevice plugin.
>> maybe this help: vdr has translation "none". softdevice as also
>> "none".
>> at this translation "none" have i core dumps...
> 
> Well, it was just a quick shot.
> I'll look into it over the weekened.
> 
>> Klaus what about gettext? This ist better alternative to "Home-made"
>> converting.
> 
> In the long run this is the plan, but as a first step I wanted to
> do the freetype and UTF-8 stuff separately.
> 
>> Or minimaly without on the fly converting of i18n strings,  these string
>> use from the begin as utf8 strings.

If you remeber the thread almost 2 years ago, "OSD language settings 
stored as language code (was: i18n.c sorted)" 
http://linvdr.org/mailinglists/vdr/2005/11/msg00646.html at that time 
you first found it a good idea, then postponed it for 1.5.x. Right after 
that I also developed a working gettext patch based on this one, and of 
course, Alexander Riedel's UTF8-patch as it looked like at that time.
Now you integrated utf8/freetype in vanilla VDR yourself, and from what 
I've read (haven't tried or looked at the code yet) it seems you used at 
least parts of that UTF8 ideas. What plans do you have about gettext, 
how long would that run be? Would it make sense if I'd rework my gettext 
patch based on the current VDR developer version in the near future (I 
developed it exactly having in mind your sketched ideas fom that time

"There would be one file for each language in VDR itself, and each
plugin would also have its own set of language files. There will
also be a way of converting the exiting i18n files into the new
format." ). Interested (in the next weeks, not right now...)?

Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] gentoo + vdr-1.5.12 + VDR_LOCAL_PATCHES_DIR

[Lucian Muresan]

Theunis Potgieter wrote:
> zzam logged on 15min after you posted :)
> 
> On 19/02/2008, *JJussi* <[EMAIL PROTECTED] 
> > wrote:
> 
> On Monday, 18. Februaryta 2008 13:06:35 Theunis Potgieter wrote:
>  > ask your question on irc
>  >
>  > irc://irc.freenode.net
>  >
>  > #gentoo-vdr
>  >
>  > ask for nicknames:  zzam or hd_brummy.
> 
> 
> Yeah, channel have quite many users logged in.. But nobody writes
> anything or
> answers to questions..
> 
> Dead channel?

Best chances are in the evening (western European time).

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] ro_RO (was: [ANNOUNCE] VDR developer version 1.5.16 - release candidate)

[Lucian Muresan]

Hi Klaus,

Klaus Schmidinger wrote:

VDR developer version 1.5.16 is now available at

ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.16.tar.bz2

A 'diff' against the previous developer version is available at

ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.15-1.5.16.diff


NOTE:
=

This is the final step towards a stable version 1.6.0.
Please report any bugs as soon as possible.

If nothing unexpected happens, I plan to release version 1.6.0 on March 2.

The following translation files still have untranslated texts:

  ca_ES.po
  cs_CZ.po
  el_GR.po
  es_ES.po
  fr_FR.po
  hr_HR.po
  nl_NL.po
  nn_NO.po
  pl_PL.po
  pt_PT.po
  ro_RO.po
  sl_SI.po
  sv_SE.po
  tr_TR.po
  uk_UA.po

It would be nice if somebody could finish these before the 1.6.0 release.
To avoid duplicate work, please announce your activity here in this thread.


attached you'll find updated romanian strings. Normally I don't use them 
myself, but now as I wanted to check them out, I noticed that on my 
Gentoo VDR I can't switch to any language, although all VDR locales are 
installed, and also "locale -a" lists those I'd be interested in from 
time to time. The log says "found 0 locales in /usr/share/vdr/locale" 
and then for every 3-letters language code "no locale found for language 
code '...'.
The Gentoo launch scripts do not modify the locale path parameter, it's 
the default one and the locales are all there. If I set LANG to any 
desired locale, I still get english...


Greets,
Lucian
diff -Naur vdr-1.5.16_orig/po/ro_RO.po vdr-1.5.16/po/ro_RO.po
--- vdr-1.5.16_orig/po/ro_RO.po	2008-02-24 11:18:14.0 +0100
+++ vdr-1.5.16/po/ro_RO.po	2008-02-25 00:39:32.0 +0100
@@ -1,20 +1,22 @@
 # VDR language source file.
-# Copyright (C) 2007 Klaus Schmidinger <[EMAIL PROTECTED]>
+# Copyright (C) 2008 Klaus Schmidinger <[EMAIL PROTECTED]>
 # This file is distributed under the same license as the VDR package.
 # Paul Lacatus <[EMAIL PROTECTED]>, 2002
-# Lucian Muresan <[EMAIL PROTECTED]>, 2004
+# Lucian Muresan <[EMAIL PROTECTED]>, 2008
 #
 msgid ""
 msgstr ""
-"Project-Id-Version: VDR 1.5.7\n"
+"Project-Id-Version: VDR 1.5.16\n"
 "Report-Msgid-Bugs-To: <[EMAIL PROTECTED]>\n"
 "POT-Creation-Date: 2008-02-10 12:22+0100\n"
-"PO-Revision-Date: 2007-08-12 14:17+0200\n"
+"PO-Revision-Date: 2008-02-25 00:39+0100\n"
 "Last-Translator: Lucian Muresan <[EMAIL PROTECTED]>\n"
-"Language-Team: \n"
+"Language-Team:  \n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=ISO-8859-2\n"
 "Content-Transfer-Encoding: 8bit\n"
+"X-Poedit-Language: Romanian\n"
+"X-Poedit-Country: ROMANIA\n"
 
 msgid "*** Invalid Channel ***"
 msgstr "*** Canal invalid ***"
@@ -167,7 +169,7 @@
 msgstr "Sunet"
 
 msgid "Key$Subtitles"
-msgstr ""
+msgstr "Subtitrare"
 
 msgid "Key$Schedule"
 msgstr "Program (EPG)"
@@ -188,31 +190,31 @@
 msgstr "Comenzi"
 
 msgid "Key$User1"
-msgstr ""
+msgstr "Utilizator1"
 
 msgid "Key$User2"
-msgstr ""
+msgstr "Utilizator2"
 
 msgid "Key$User3"
-msgstr ""
+msgstr "Utilizator3"
 
 msgid "Key$User4"
-msgstr ""
+msgstr "Utilizator4"
 
 msgid "Key$User5"
-msgstr ""
+msgstr "Utilizator5"
 
 msgid "Key$User6"
-msgstr ""
+msgstr "Utilizator6"
 
 msgid "Key$User7"
-msgstr ""
+msgstr "Utilizator7"
 
 msgid "Key$User8"
-msgstr ""
+msgstr "Utilizator8"
 
 msgid "Key$User9"
-msgstr ""
+msgstr "Utilizator9"
 
 msgid "Disk"
 msgstr "Disc"
@@ -260,10 +262,10 @@
 msgstr "PID AC3 (2)"
 
 msgid "Spid1"
-msgstr ""
+msgstr "Spid1"
 
 msgid "Spid2"
-msgstr ""
+msgstr "Spid2"
 
 msgid "Tpid"
 msgstr "PID Teletext"
@@ -431,7 +433,7 @@
 msgstr "Vã rog introduceþi %d cifre!"
 
 msgid "CAM not responding!"
-msgstr ""
+msgstr "CAM-ul nu reacþioneazã!"
 
 msgid "Recording info"
 msgstr "Detaliile înregistrãrii"
@@ -503,25 +505,25 @@
 msgstr "Utilizare fonturi mici"
 
 msgid "Setup.OSD$Anti-alias"
-msgstr ""
+msgstr "Antialiere"
 
 msgid "Setup.OSD$Default font"
-msgstr ""
+msgstr "Font implicit"
 
 msgid "Setup.OSD$Small font"
-msgstr ""
+msgstr "Font mic"
 
 msgid "Setup.OSD$Fixed font"
-msgstr ""
+msgstr "Font cu lãþime fixã"
 
 msgid 

Re: [vdr] wrong characters in EPG (vdr-1.5.18)

[Lucian Muresan]

Éric Laly wrote:
> Klaus Schmidinger a écrit :
>> On 03/20/08 09:46, Éric Laly wrote:
>>> Klaus Schmidinger a écrit :
>>>
>>> ...
>>>
 Please do this

 --- libsi/si.c  2008/03/05 17:00:55 1.25
 +++ libsi/si.c  2008/03/19 21:30:47
 @@ -416,6 +416,10 @@
  // FIXME Need to make this UTF-8 aware (different control codes).
  // However, there's yet to be found a broadcaster that actually
  // uses UTF-8 for the SI data... (kls 2007-06-10)
 +   if (size > 20) {
 +  to = stpcpy(to, cs);
 +  to = stpcpy(to, "@");
 +  }
  for (int i = 0; i < len; i++) {
 if (*from == 0)
break;

 and check which encodings are listed in EPG strings for ARTE and
 direct8.
>>> I'm not at home now but I've just tried via network and get results via 
>>> SVDRP.
>>> See joined files.
>>>
>>> It seems that EPG that are correctly displayed are in 8859-9 and the 
>>> others in ISO6937.
>>>
 Have you set VDR_CHARSET_OVERRIDE?
>>> No.
>> Please try setting VDR_CHARSET_OVERRIDE=ISO-8859-9 before starting
>> VDR. This should fix it.
> 
> This is fixed !
> 
> Thank you.

Looks like this is set globally, for all of the epg data, right? What 
about mixed charsets from different providers (I know for sure there 
are, and there are also the "external" data sources like tvmovie2vdr and 
the like fetching some xmltv listings and injecting the data via SVDRP)?

Cheers,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] wrong characters in EPG (vdr-1.5.18)

[Lucian Muresan]

Klaus Schmidinger wrote:
[..]
 Please try setting VDR_CHARSET_OVERRIDE=ISO-8859-9 before starting
 VDR. This should fix it.
>>> This is fixed !
>>>
>>> Thank you.
>> Looks like this is set globally, for all of the epg data, right? What 
>> about mixed charsets from different providers (I know for sure there 
>> are, and there are also the "external" data sources like tvmovie2vdr and 
>> the like fetching some xmltv listings and injecting the data via SVDRP)?
> 
> The DVB standard provides for a way to mark text strings, so that
> applications can correctly determine the actual encoding. The
> VDR_CHARSET_OVERRIDE is just a workaround in case your "main"
> provider fails to correctly encode their strings.

Am I missing something, is there a way to mark a provider as being my 
"main" one? Or is the workaround rather replacing the character set for 
all incorrectly recognized ones (assuming that the application 
determines the fact that it is incorrect)? If the latter case occures, 
what if there are several providers not marking the encoding right, but 
their epg content actually need different encodings, will they all use 
the same encoding specified in VDR_CHARSET_OVERRIDE? (This reminds me of 
the early UTF-8 patch which required setting the encoding for every 
channel in channels.conf, which of course is ugly, but could handle 
different EPG encoding needs in case of multiple providers failing to 
mark this correctly).

> External data source simply need to provide the strings in the
> encoding used on your local system (presumably UTF-8).

So it should work in the case of correctly handling external data, thanks.

BTW, OSD then stays unaffected by VDR_CHARSET_OVERRIDE? It might be 
worth renaming this to something more clearly specifying that it only 
affects EPG.

Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] wrong characters in EPG (vdr-1.5.18)

[Lucian Muresan]

Füley István wrote:
>> External data source simply need to provide the strings in the
>> encoding used on your local system (presumably UTF-8).
>>
>> Klaus
> 
> This is what I did in my xmltv grab process:
> 
> iconv --silent --from-code=ISO-8859-2 --to-code=UTF-8 
> --output=/opt/tigervdr/xmltv/hu-utf.xml /opt/tigervdr/xmltv/all.xml
> 
> And this provides vdr the correct encoding for epg.

Looks like you might be using www.port.hu / www.port.ro as your data 
source. I used to use the romanian version some time ago, now I would 
like to set the whole thing up again. If you're really using that, could 
you please provide some relevant config snippets, scripts and requirements?

Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] wrong characters in EPG (vdr-1.5.18)

[Lucian Muresan]

Klaus Schmidinger wrote:
> On 03/26/08 13:39, Lucian Muresan wrote:
>> Klaus Schmidinger wrote:
>> [..]
>>>>>> Please try setting VDR_CHARSET_OVERRIDE=ISO-8859-9 before starting
>>>>>> VDR. This should fix it.
>>>>> This is fixed !
>>>>>
>>>>> Thank you.
>>>> Looks like this is set globally, for all of the epg data, right? What 
>>>> about mixed charsets from different providers (I know for sure there 
>>>> are, and there are also the "external" data sources like tvmovie2vdr and 
>>>> the like fetching some xmltv listings and injecting the data via SVDRP)?
>>> The DVB standard provides for a way to mark text strings, so that
>>> applications can correctly determine the actual encoding. The
>>> VDR_CHARSET_OVERRIDE is just a workaround in case your "main"
>>> provider fails to correctly encode their strings.
>> Am I missing something, is there a way to mark a provider as being my 
>> "main" one? Or is the workaround rather replacing the character set for 
>> all incorrectly recognized ones (assuming that the application 
>> determines the fact that it is incorrect)? If the latter case occures, 
>> what if there are several providers not marking the encoding right, but 
>> their epg content actually need different encodings, will they all use 
>> the same encoding specified in VDR_CHARSET_OVERRIDE? (This reminds me of 
>> the early UTF-8 patch which required setting the encoding for every 
>> channel in channels.conf, which of course is ugly, but could handle 
>> different EPG encoding needs in case of multiple providers failing to 
>> mark this correctly).
> 
> Well, first and foremost providers should actually do their homework
> and encode their stuff according to the standard.
> 
> The problem is with providers who don't add a codeset marker to their
> strings. This is ok as long as they actually encode in ISO6937.
> Unfortunately some providers use ISO-8859-9 instead (or maybe even
> others). With VDR_CHARSET_OVERRIDE set, all strings that are not
> explicitly marked as using a specific codeset are assumed to be
> encoded in the way given by VDR_CHARSET_OVERRIDE.
> 
>>> External data source simply need to provide the strings in the
>>> encoding used on your local system (presumably UTF-8).
>> So it should work in the case of correctly handling external data, thanks.
>>
>> BTW, OSD then stays unaffected by VDR_CHARSET_OVERRIDE? It might be 
>> worth renaming this to something more clearly specifying that it only 
>> affects EPG.
> 
> This was just a last minute quick workaround (initially this was hardcoded),
> since some (esp. Czech) providers actually do encode their strings in
> ISO6937, and I didn't want to cause problems with those who do adhere to
> the standard.
> 
> An elaborate workaround would probably require a separare file
> in which transponders can be marked as using a specific default
> codeset (and then VDR_CHARSET_OVERRIDE would vanish again).
> 
> But it would be so much better if these providers would just follow
> the standard! Yes, I know, these are multi million dollar enterprises,
> so they can't be bothered with "standards" - oh well...

You're so right about these providers :-). Thanks for enlightening on 
the current state of this workaround. Maybe, if proven necessary, the 
extra file concept will be not too difficult or "unclean" to implement 
(possibly as a patch by someone else, myself not excluded).

Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Vdr-xine OSD question

[Lucian Muresan]

Antti Seppälä wrote:
> 2008/7/11 Todd Luliak <[EMAIL PROTECTED]>:
>> I am running vdr + vdr-xine plugin + coreavc + xine being output at 1080i to
>> an HDTV as the only display. Is there a simple way to lock the OSD to the
>> resolution of the output device such that the OSD is not rescaled when
>> switching between SD and HD sources? I played with X-overlay, but that was
>> not what I was after. If not, could it be done in the source somewhere or is
>> the OSD anti-aliased and overlayed on the video before being sent to the
>> output device (xine, in my case)? I've looked around quite a bit on the net
>> but I guess my google-foo is failing me on this one. I just miss the
>> rock-solid OSD of the FF card setup...
>> Thanks!
>>
> 
> In an effort to create something to solve such issues with
> xineliboutput plugin I came up with an idea of this HUD type OSD.
> Basically it means that OSD is rendered to a separate transparent
> surface on top of video and then these are blended together by the
> display hardware. This way the size of the OSD is bound to the size of
> the used window rather than the size of the video stream. In other
> words no OSD scaling will be necessary even though the video size
> changes.
> 
> The HUD implementation has been integrated into the CVS of
> xineliboutput plugin. To operate it requires support for xorg render
> extension and presence of composite display manager such as xcompmgr.
> It also requires powerful display adapter and drivers with support for
> these modern extensions. Maybe you can try it to see if it produces
> results that you are hoping for?

This sounds very good for HDTV setups which apparently all imply xorg, 
but what about DirectFB, does this HUD implementation also work there? 
Even if I still have a plain old PAL TV at the moment, when I switch to 
some "SD" channels having only 544x576 (which are then stretched to 
720x576), the OSD suffers from the same problem, it's ugly stretched 
horizontally, and when the channel is 16:9, even worse, compressed 
vertically.

Regards,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] directFB with 1080i (was - Vdr-xine OSD question)

[Lucian Muresan]

Goga777 wrote:
>>> This sounds very good for HDTV setups which apparently all imply xorg,
>>> but what about DirectFB, does this HUD implementation also work there?
> 
> 
> have you good experience with HD video 1080i video from satellites and 
> DirectFB ?
> is it better than X- Window solution ?

Sorry, my only HDTV capable hardware a.t.m. would be the Lenovo L220x 
monitor, (no TV, no DVB-S2 card, I can only try to receive what's still 
broadcasted on DVB-S, which again is already h264 - even my desktop PC 
is to weak for this), so I can't tell.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Vdr-xine OSD question

[Lucian Muresan]

Antti Seppälä wrote:

[...]

> Unfortunately HUD is very dependent on xorg and will not work with
> DirectFB. I'm not even sure whether DirectFB contains support for
> similar operations without resorting to CPU intensive software
> blending of the OSD.

AFAIK, it does, at least for certain graphics cards (also depending on 
the configuration), there are so-called "layers" and the device 
capabilities can be queried in the API. Even if there is no good enough 
support for separate layers to do this, DirectFB further supports 
"surfaces" whithin a layer, AFAIK that's how softdevice implements the 
OSD, and it's not at all CPU-intense, in fact I guess those operations 
are also accelerated, and the OSD shows up all the time at the same, 
correct, native display resolution, regardless of the video resolution 
(i.e. it also uses the black top/bottom bars when the video is 16:9 
letterboxed on my 4:3 TV, or it is drawn still at 720x576 even when the 
broadcast is only 544x764).



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] OT question (was: WinTV USB CI-Module and recommended distribution for VDR?)

[Lucian Muresan]

Sascha Vogt wrote:
> Hi Lauri,
> 
> Lauri Tischler schrieb:
>> Sascha Vogt wrote:
>>> as my hardware is shipping (went for the ASUS M2N78Pro, GeForce 8300
>>> with an Athlon X2 4850e, hopefully that'll work with VDPAU and HD
>>> videos)
>> Couldn't find M2N78Pro, do you mean M3N78PRO ?
> Sorry, you're right, meant the M3N78Pro.

Does this board have at least headers for a parallel printer port? I
can't find a hi-res picture of it, and docs do not mention it, so I fear
I couldn't use my graphical VFD if I where to decide on this board in
favour of some 8200-based still in ATX form factor.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] HTPC IR Einschalter Bausatz od. fertig 20 EUR

[Lucian Muresan]

http://www.atric.de/IR-Einschalter/index.php
http://www.atric.de/IR-Einschalter/com.html
http://www.atric.de/IR-Einschalter/download/manual_en_rev4.pdf


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] HTPC IR Einschalter Bausatz od. fertig 20 EUR

[Lucian Muresan]

Sorry about this message, please ignore it, it was just meant for later
reading at home...

Lucian Muresan wrote:
> http://www.atric.de/IR-Einschalter/index.php
> http://www.atric.de/IR-Einschalter/com.html
> http://www.atric.de/IR-Einschalter/download/manual_en_rev4.pdf


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-xine-0.9.2 plugin does not support cutting.

[Lucian Muresan]

Maybe it is not related to the vdr-xine plugin, could be with the VDR
version, more specifically TS format? I'm having the same problem as
described by Carsten with the xineliboutput plugin, on vdr-1.7.4.

d...@free.fr wrote:
> Hi
> 
> Same problem here, was thinking it was my setup who was wrong.
> 
> By the way I saw also a big latency when you stop the replay of recordings to
> live TV , whatever was the button used (Blue button or Menu Back) , the live
> video freeze for 2-3 seconds , VDR is inoperative (no access to menu) during
> this time
> 
> Hope this help to debug
> 
> Have a nice day
> 
> 
> Selon Carsten Koch :
> 
>> Reinhard, you have done an amazing job with the xine plugin.
>> It works very well and considering xine's complexity,
>> I can appreciate the hard work that must have been required
>> to get both the infrastructure in xine and the plugin itself
>> working as well as it does today.
>>
>> I noticed, however, that it is extremely hard to use VDRs
>> cutting function with it.
>>
>> For example, when I use the '7' and '9' keys to jump to the
>> previous/next cut mark, or when I use the '4' and '6' keys to
>> fine-position a cut mark, the video image is not updated, so I
>> am basically forced to navigate in complete darkness.
>>
>> Is that a known bug?
>> Does it happen only in my setup (TT-budget S2-3200,
>> GeForce 9500GT with VDPAU)?
>> Is there a configuration option I can tweak to fix it?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] softdevice-0.5.0.20090218 and CVS: AC3 passthrough mode no longer working

[Lucian Muresan]

Hi there,

well, I haven't used softdevice anymore for a long time, because I had some
strange video issues (only black screen with OSD, no video), and after I
decided to start with a fresh new system on my VDR machine, now I'm giving
vdr-1.7.7 a try, with the plugins that work already with it, softdevice
being one of them.
I tried this with softdevice-0.5.0.20090218 (as packaged in gentoo) and
CVS,
and my problem is that my external amplifier hooked up via optical SPDIF
detects no signal when switching to AC3 audio tracks of channels or
recordings. This works however when playing a video file with an AC3 track
in fbxine for example. I mostly copied over the settings from my old
system,
where even this ac3 passtrhrough with softdevice used to work. Here are
some
settings and outputs that might be relevant:


In /etc/vdr/setup.conf, I have:
CurrentDolby = 1
DolbyTransferFix = 0  # don't know what this does, there is no difference
UseDolbyDigital = 1
UseDolbyInRecordings = 1
softdevice.AC3Mode = 1 # should be passthrough, right?


'aplay -l' shows:
 List of PLAYBACK Hardware Devices 
card 0: CMI8738 [C-Media CMI8738], device 0: CMI8738-MC6 [C-Media PCI
DAC/ADC]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: CMI8738 [C-Media CMI8738], device 1: CMI8738-MC6 [C-Media PCI 2nd
DAC]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: CMI8738 [C-Media CMI8738], device 2: CMI8738-MC6 [C-Media PCI
IEC958]
  Subdevices: 1/1
  Subdevice #0: subdevice #0


'aplay -L' shows:
front:CARD=CMI8738,DEV=0
C-Media CMI8738, C-Media PCI DAC/ADC
Front speakers
rear:CARD=CMI8738,DEV=0
C-Media CMI8738, C-Media PCI 2nd DAC
Rear speakers
surround40:CARD=CMI8738,DEV=0
C-Media CMI8738, C-Media PCI 2nd DAC
4.0 Surround output to Front and Rear speakers
surround41:CARD=CMI8738,DEV=0
C-Media CMI8738, C-Media PCI 2nd DAC
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=CMI8738,DEV=0
C-Media CMI8738, C-Media PCI 2nd DAC
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=CMI8738,DEV=0
C-Media CMI8738, C-Media PCI 2nd DAC
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
iec958:CARD=CMI8738,DEV=0
C-Media CMI8738, C-Media PCI DAC/ADC
IEC958 (S/PDIF) Digital Audio Output
null
Discard all samples (playback) or generate zero samples (capture)



And the most important, the parameters given to the softdevice plugin:
'--plugin=softdevice -vo dfb:mgatv -ao alsa:pcm=default#ac3=hw:0,2#'

I have to mention that normal mpeg audio is decoded and sent as PCM to the
SPDIF, only AC3 and only with vdr softdevice is the problem. I tried hw:0,0
and hw:0,1 as well, but no sound. How to deal with this, did I miss
something?

Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] femon - stream information

[Lucian Muresan]

Hi there,

Rolf Ahrenberg wrote:
> On Fri, 24 Jul 2009, Torgeir Veimo wrote:
> 
>> Would it be hard to enhance the femon plugin to show some stream
>> information, eg progressive v interlaced and stream resolution, eg
>> 480p, 576p, 1080i etc? It already does some stream parsing as is, to
>> determine mpeg2 vs h.264?
> 
> Nope - most of the code is already there: only a simple ts2pes buffering 
> class is missing as all required data doesn't fit into a one TS packet 
> with H.264. I don't have access to any H.264 channels, so I won't 
> implement any further. Also I'm waiting Klaus' decision about enchanhing 
> the cDevice API as certain information are quite useful i.e. for skins.


this might be slightly OT, but I thought it would be worth pointing out
if talking about future releases of the femon plugin. Would you like to
take a look at my quick hack which makes the femon OSD width adaptive
and consistent to the global OSD width (for HD displays):
http://www.vdr-portal.de/board/thread.php?postid=829287#post829287
As mentioned, maybe it's a hack, but it looks quite well on my FullHD
OSD (even if right now I'm only able to receive SD video yet). For vdr
>= 1.7.8 maybe the OSD width value can be obtained via the new API call
Klaus introduced, but I only did it for a patched vdr-1.7.7, but you get
the idea...

Cheers,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] femon - stream information

[Lucian Muresan]

Rolf Ahrenberg wrote:
> On Fri, 24 Jul 2009, Lucian Muresan wrote:
> 
>> this might be slightly OT, but I thought it would be worth pointing out
>> if talking about future releases of the femon plugin. Would you like to
>> take a look at my quick hack which makes the femon OSD width adaptive
>> and consistent to the global OSD width (for HD displays):
> 
> The similar feature is already implemented in the git repository, so it 
> will be available in the next public release.

Cool, good to hear that. Is the git repository publicly accessible (for
a gentoo ebuild for example)?

Regards,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] vdr-webvideo 0.2.0 - little patch to makefile of libwebvi

[Lucian Muresan]

Hi,

On 24.01.2010 16:46, Aimo Parru wrote:
> On Sunday 24 January 2010 15:34:59 Antti Ajanki wrote:
>> Does it work if you first run
>>
>> /sbin/ldconfig /usr/local/lib
>>
>> as root and then restart VDR?
>>
> 
> Yes. It started now. Ldconfig gave a warning or something:
> /sbin/ldconfig.real: /usr/local/lib/libwebvi.so.0 is not a symbolic link  

This I think can be fixed when applying the attached patch, (which also
makes libwebvi installable by a Gentoo ebuild I wrote for it in the
default gentoo prefix /usr). I noticed that in the build directory,
libwebvi.so.0 is generated as symlink, but when running the install
target, it ends up installing 3 copies of the same file instead of only
one and 2 symlinks. The patch also applies to version 0.2.1.

Btw, I wrote 3 ebuilds for this plugin (media-video/rtmptdump-yle,
media-video/webvi and media-plugins/vdr-webvi) and already sent them to
Joerg from the Gentoo vdr team...

Cheers,
Lucian


diff -Naur webvideo-0.2.0_orig/src/libwebvi/Makefile 
webvideo-0.2.0/src/libwebvi/Makefile
--- webvideo-0.2.0_orig/src/libwebvi/Makefile   2010-01-17 17:57:27.0 
+0100
+++ webvideo-0.2.0/src/libwebvi/Makefile2010-01-21 11:28:28.0 
+0100
@@ -1,4 +1,4 @@
-PREFIX=/usr/local
+PREFIX ?= /usr/local
 
 LIBNAME=libwebvi.so
 LIBSONAME=$(LIBNAME).0
@@ -21,6 +21,6 @@
rm -f *.o *~ libwebvi.so* libwebvi.a
 
 install: $(LIBMINOR)
-   cp --remove-destination libwebvi.so* $(PREFIX)/lib
+   cp --remove-destination --archive libwebvi.so* $(PREFIX)/lib
 
 .PHONY: clean install

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] vdr-webvideo 0.2.0 - little patch to makefile of libwebvi

[Lucian Muresan]

On 26.01.2010 14:33, Rene wrote:
> Lucian Muresan wrote:
> 
>> Btw, I wrote 3 ebuilds for this plugin (media-video/rtmptdump-yle,
>> media-video/webvi and media-plugins/vdr-webvi) and already sent them to
>> Joerg from the Gentoo vdr team...
> 
> Hi Lucian!
> 
> Do you happen to have these ebuilds somewhere to download, cause i can't
> wait to test them :-)

Here you go!

Just put them in the right categories as mentioned above, and don't
forget  to place the confd to the plugin's ${FILESDIR} and the makefile
patch to that of the webvi library ${FILESDIR} before generating the
manifests...

Of course, these are just quick shots, who knows, maybe dependencies are
still not correct, but as of version 0.2.1 they work in my vdr-1.7.11.

I also have some other feedback to the author:

How could other sites like http://plus7.arte.tv or the "Mediathek" of
ZDF or 3sat be added to the templates?

Is it possible to to implement that the plugin's OSD "remembers" where
it was left when last accessed in the current VDR "session"? It's a bit
tedious to navigate through all menus again and again.

If a search did not give the desired results, it would be useful if a
new attempt would still hold the old search keywords to be able to
slightly modify them instead of "typing" them again.

Otherwise, really nice and interesting plugin which actually works with
youtube, unlike the ones I've tried with XBMC where they crash all the
time...
BTW, how does it handle multiple quality versions of youtube videos,
does it pick "HD" or "HQ" by itself?

Cheers,
Lucian
# /etc/conf.d/vdr.webwideo:

# Global config file for vdr rc-scripts

# -d dir, --downloaddir=dir  Save downloaded files to dir. The default
#path is the VDR video directory.
# -t dir, --templatedir=dir  Read video site templates from DIR (default
#/usr/local/share/webvi/templates)

_EXTRAOPTS="--templatedir=/usr/share/webvi/templates"
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

#EAPI=0

inherit eutils

DESCRIPTION="CLI program for downloading vidos from YLE Areena"

HOMEPAGE="http://users.tkk.fi/~aajanki/${PN}/index-en.html";

IUSE=""

SRC_URI="http://users.tkk.fi/~aajanki/${PN}/${P}.tar.gz";

LICENSE="GPL-2"

SLOT="0"

KEYWORDS="~amd64 ~x86"

DEPEND="dev-libs/openssl
dev-libs/libxml2"

RDEPEND="${DEPEND}"

src_install() {
dobin ${PN}
dobin yle-dl
dodoc ChangeLog README* TODO
}
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

inherit vdr-plugin

DESCRIPTION="VDR Plugin: video website browser / viewer"
HOMEPAGE="http://users.tkk.fi/~aajanki/vdr/webvideo/";
SRC_URI="http://users.tkk.fi/~aajanki/vdr/webvideo/${P}.tgz";

LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE=""

DEPEND=">=media-video/vdr-1.6.0
=media-video/webvi-${PV}"

S="${WORKDIR}/${VDRPLUGIN}-${PV}/src/vdr-plugin"

src_install() {
vdr-plugin_src_install
insinto /etc/vdr/plugins/${VDRPLUGIN}
doins mime.types
dodoc ${WORKDIR}/${VDRPLUGIN}-${PV}/README*
dodoc ${WORKDIR}/${VDRPLUGIN}-${PV}/TODO
dodoc ${WORKDIR}/${VDRPLUGIN}-${PV}/HISTORY
dodoc ${WORKDIR}/${VDRPLUGIN}-${PV}/doc/*
}
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

EAPI=2

inherit eutils

DESCRIPTION="Video website browser / viewer library needed for the VDR plugin 
vdr-webvideo"

HOMEPAGE="http://users.tkk.fi/~aajanki/vdr/webvideo/";

IUSE="+yle"

SRC_URI="http://users.tkk.fi/~aajanki/vdr/webvideo/vdr-webvideo-${PV}.tgz";

LICENSE="GPL-2"

SLOT="0"

KEYWORDS="~amd64 ~x86"

DEPEND="dev-lang/python
dev-python/pycurl
dev-libs/libxml2
dev-libs/libxslt
yle? (  media-video/rtmpdump-yle )
"

RDEPEND="${DEPEND}"

S="${WORKDIR}/webvideo-${PV}"

src_unpack() {
unpack ${A}
cd ${S}
epatch ${FILESDIR}/${P}_prefix.diff
if ! use yle; then
rm -Rf templates/bin
rm -Rf templates/yleareena
fi
}

src_install() {
if [ ${ARCH} = "amd64" ]; then
dodir /usr/lib64
dosym lib64 /usr/lib
fi
cd ${S}
PREFIX=${D}/usr emake install-library || die "failed install"
dodoc HISTORY README* TODO doc/*
if [ ${ARCH} = "amd64" ]; then
rm ${D}/usr/lib
fi

[vdr] [PATCH] vdr-1.7.12 - few libsi exports needed in eepg plugin

[Lucian Muresan]

Hello folks,

recently I re-adjusted my antenna to receive the BBC channels and
discovered that EPG is only available for the current and next event,
and then found out in the vdr-portal that there is the EEPG plugin which
decodes the extended EPG data they send (see
http://www.linuxtv.org/vdrwiki/index.php/Eepg-plugin).

Well, wanting to quickly write a gentoo ebuild for it, I discovered that
the build fails because the author included libsi/si.c (not si.h) to
compile the plugin. While this might work when building plugins "by
hand" inside a vdr sources tree, or on a distribution where the sources
(not only headers) are available, I'm sure that's not good practice at
all. It's better to ask the maintainer of the respective library, class
or C file to export what's needed through the header.

Well, Klaus, would you please consider adding this patch to the next
release? Just exporting 2 functions and a flag, if you prefer you could
export the flag through a read-only access function, too.

Thank you,
Lucian
diff -Naur vdr-1.7.12_orig/libsi/si.c vdr-1.7.12/libsi/si.c
--- vdr-1.7.12_orig/libsi/si.c  2009-12-05 17:20:12.0 +0100
+++ vdr-1.7.12/libsi/si.c   2010-02-10 01:09:08.743017649 +0100
@@ -339,7 +339,7 @@
 // a string indicating that table. If no table can be determined, the
 // default ISO6937 is returned. If a table can be determined, the buffer
 // and length are adjusted accordingly.
-static const char *getCharacterTable(const unsigned char *&buffer, int 
&length, bool *isSingleByte = NULL) {
+const char *getCharacterTable(const unsigned char *&buffer, int &length, bool 
*isSingleByte/* = NULL*/) {
const char *cs = "ISO6937";
// Workaround for broadcaster stupidity: according to
// "ETSI EN 300 468" the default character set is ISO6937. But 
unfortunately some
@@ -375,7 +375,7 @@
return cs;
 }
 
-static bool convertCharacterTable(const char *from, size_t fromLength, char 
*to, size_t toLength, const char *fromCode)
+bool convertCharacterTable(const char *from, size_t fromLength, char *to, 
size_t toLength, const char *fromCode)
 {
   if (SystemCharacterTable) {
  iconv_t cd = iconv_open(SystemCharacterTable, fromCode);
diff -Naur vdr-1.7.12_orig/libsi/si.h vdr-1.7.12/libsi/si.h
--- vdr-1.7.12_orig/libsi/si.h  2009-12-06 12:37:35.0 +0100
+++ vdr-1.7.12/libsi/si.h   2010-02-10 01:09:08.743017649 +0100
@@ -492,6 +492,13 @@
 // like "iso8859-15" or "utf-8" (case insensitive).
 // Returns true if the character table was recognized.
 bool SetSystemCharacterTable(const char *CharacterTable);
+// Determines the character table used in the given buffer and returns
+// a string indicating that table. If no table can be determined, the
+// default ISO6937 is returned. If a table can be determined, the buffer
+// and length are adjusted accordingly.
+const char *getCharacterTable(const unsigned char *&buffer, int &length, bool 
*isSingleByte = NULL);
+bool convertCharacterTable(const char *from, size_t fromLength, char *to, 
size_t toLength, const char *fromCode);
+extern bool SystemCharacterTableIsSingleByte;
 
 } //end of namespace
 
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] 10 Year Anniversary of VDR

[Lucian Muresan]

Congratulations Klaus, and also to the rest of contributors. Many
returns of such decade anniversaries! I'm also using it for almost 6
years, quite catching hobby!

On 19.02.2010 17:09, Klaus Schmidinger wrote:
> It has been exactly 10 years since version 0.01 of VDR (originally
> named "OSM" - On Screen Menu) was released.
> 
> I want to use the occasion to thank everybody who has contributed
> to VDR, but also those who simply use VDR in their every day life.
> I for one couldn't imagine watching tv without VDR any more. Special
> thanks go to the people running the VDR-Portal (www.vdr-portal.de).
> 
> Originally I intended to release version 2.0 of VDR at the 10th
> anniversary, but as ever so often, I ran out of time. But I'm still
> on it - stability comes before deadlines ;-)

Oh, and the following version ends in 13 ;-)

Best regards,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Linux in the living room

[Lucian Muresan]

On 23.02.2010 10:34, Luca Olivetti wrote:

> Most (all?) modern tv sets from samsung, lg, panasonic, sharp (and
> probably philips) are running some form of Linux, but that's usually
> only the base operating system, the application controlling the tv and
> that's doing mostly everything is closed.
> You can still do some interesting things just hacking the Linux base
> (e.g, if the tv can reproduce media from usb, you can fake an usb stick
> with an nfs mounted directory to media from the network), provided the
> manufacturer is "friendly" enough to the GPL and provides everything it

> is required to provide (I'm struggling with LG to get the sources
> corresponding to what's actually running on my TV, so if that's an
> important decision factor I'd avoid LG).

Any reaction at all, from LG?

Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] OT: Applications for the living room

[Lucian Muresan]

On 25.02.2010 16:27, Adrian C. wrote:
> On Wed, 24 Feb 2010, Theunis Potgieter wrote:
> 
>> However I have seen where the media player option within VDR is not 
>> needed if you running something like XBMC as another front-end. I 
>> might be looking into enna http://enna.geexbox.org/ soon, which is 
>> similar concept as XBMC and uses xine-lib (neither vdr-xine or 
>> vdr-xineliboutput). Will see where that leads :)

Enna uses vdr-xine (through Geexbox' libplayer when compiled with xine
support) and libsvdrp (also a geexbox library specially written for
interacting with VDR). For those happening to use Gentoo, installing
everything is now a snap, I uploaded Enna-related ebuilds, see
http://forums.gentoo.org/viewtopic-t-816990.html

Cheers,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] enna + vdr

[Lucian Muresan]

On 26.02.2010 13:21, martinez wrote:
> Can somebody confirm that using enna as a media player, integration with vdr 
> via the vdr-xine plugin is good including the OSD?
> How does one navigate from enna to vdr and viceversa?

I cannot yet fully confirm everything, but from what I know, if it uses
vdr-xine, the original VDR OSD should also show up. As for navigating
from Enna to VDR, well, Enna runs all the time, VDR too, and Enna has a
main menu entry called "TV", that's where it connects to VDR and slides
the menu to the left. Unfortunately on my installation, at this point
I'm only getting a black screen so far, did not have too much time to
debug what's going on. Navigating back would disconnect from VDR  and
animate the main menu back, but I didn't get that far yet.

Btw, I'm using vdr-1.7.12, xine-lib-1.2 and vdr-xine-0.9.3 on Gentoo,
and the only way I can connect the traditional xine-ui to the running
VDR instance is usig as the MRL "netvdr:/localhost#demux:mpeg_pes", as
for using the other way of connecting through a pipe
("vdr:/tmp/vdr-xine/stream#demux:mpeg_pes"), on my system there is no
such pipe. I just wanted to try it that way in enna, but don't find a
way to activate it in vdr-xine, is that no longer supported?

Regards,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] enna + vdr

[Lucian Muresan]

On 26.02.2010 20:51, Reinhard Nissl wrote:
> Hi,
> 
> Am 26.02.2010 14:20, schrieb Lucian Muresan:
> 
>> Btw, I'm using vdr-1.7.12, xine-lib-1.2 and vdr-xine-0.9.3 on Gentoo,
>> and the only way I can connect the traditional xine-ui to the running
>> VDR instance is usig as the MRL "netvdr:/localhost#demux:mpeg_pes", as
>> for using the other way of connecting through a pipe
>> ("vdr:/tmp/vdr-xine/stream#demux:mpeg_pes"), on my system there is no
>> such pipe. I just wanted to try it that way in enna, but don't find a
>> way to activate it in vdr-xine, is that no longer supported?
> 
> Please check if you run vdr-xine with option -p. Just remove it
> then. MANUAL reports:
> 
> -p[N]   use socket connections on port N (18701)

Thanks Reinhard, I must have been way too tired when I checked the
plugin parameters and ruled that possibility out. Now I cand let enna
connect to vdr-xine at least in this pipe mode.

Regards,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] merging correctly several .ts files to a single ts file or better mkv

[Lucian Muresan]

On 28.03.2010 18:12, Eric Valette wrote:
> On 28/03/2010 17:45, Eric Valette wrote:
>> On 28/03/2010 17:23, Lars Bläser wrote:
> 
>> Granted. However, merging with cat *.ts > complete.ts + trying a single
>> pass mkv conversion fails miserably (allhough I have very up to date
>> ffmpeg version).
>>
>> See fourth message in this threads ffmpeg complain with non monotone
>> timestamps and simply hang the computer.
> 
> I just tryed remuxing the .ts (and removing unneeded languages and
> subtitles) file to another .ts before converting to matroska and it works!
> 
> cat 1.ts  2.ts > merged.ts
> ffmpeg -y -ss 00:01:06 -map 0.0 -map 0.1 -i merged.ts -vcodec copy
> -sameq -acodec copy simplified1.ts
> ffmpeg -y -i simplified1.ts  -vcodec copy -sameq -acodec copy -async 2
> -f matroska 1.mkv
> 
> Much simpler indeed and no risk to have a small glitch in the meddle of
> the cut.

Where do you take that time offset value from? I'm also working on such
kind of scripts right now, because I want to remux especially HD
recordings to MKV. In the case of movies broadcasted by ARD HD or ZDF HD
(7...@50hz), they are full of so-called filler-NALUs, which can be
removed just by muxing into MKV not directly by ffmpeg, but by mkvmerge,
which shrinks a 10GB movie to about 3GB. My problem is still A/V sync,
all the original TS chunks (I also record into 200MB pieces, because of
fast editing in VDR) show video delays for each audio track of over 1
second, which is also very noticeable ion the final converted MKV. The
delays are reported both by tsMuxeR and mediainfo see for example the
"Video delay" value below:

mediainfo 1.ts
General
ID   : 8008
Complete name: 1.ts
Format   : MPEG-TS
File size: 200 MiB
Duration : 2mn 6s
Overall bit rate : 13.3 Mbps

Video
ID   : 6010 (0x177A)
Menu ID  : 132 (0x84)
Format   : AVC
Format/Info  : Advanced Video Codec
Format profile   : h...@l4.0
Format settings, CABAC   : Yes
Format settings, ReFrames: 5 frames
Duration : 2mn 5s
Bit rate : 11.5 Mbps
Width: 1 280 pixels
Height   : 720 pixels
Display aspect ratio : 16:9
Frame rate   : 50.000 fps
Resolution   : 8 bits
Colorimetry  : 4:2:0
Scan type: Progressive
Bits/(Pixel*Frame)   : 0.249
Stream size  : 172 MiB (86%)
Color primaries  : BT.709-5, BT.1361, IEC 61966-2-4,
SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients  : BT.709-5, BT.1361, IEC 61966-2-4 709,
SMPTE RP177

Audio #1
ID   : 6020 (0x1784)
Menu ID  : 132 (0x84)
Format   : MPEG Audio
Format version   : Version 1
Format profile   : Layer 2
Duration : 2mn 5s
Bit rate mode: Constant
Bit rate : 256 Kbps
Channel(s)   : 2 channels
Sampling rate: 48.0 KHz
Video delay  : -1s 340ms
Stream size  : 3.84 MiB (2%)
Language : German
Language, more info  : Clean effects

Audio #2
ID   : 6021 (0x1785)
Menu ID  : 132 (0x84)
Format   : MPEG Audio
Format version   : Version 1
Format profile   : Layer 2
Duration : 2mn 5s
Bit rate mode: Constant
Bit rate : 256 Kbps
Channel(s)   : 2 channels
Sampling rate: 48.0 KHz
Video delay  : -1s 344ms
Stream size  : 3.84 MiB (2%)
Language : German
Language, more info  : Clean effects

Audio #3
ID   : 6022 (0x1786)
Menu ID  : 132 (0x84)
Format   : AC-3
Format/Info  : Audio Coding 3
Duration : 2mn 5s
Bit rate mode: Constant
Bit rate : 448 Kbps
Channel(s)   : 2 channels
Channel positions: Front: L R
Sampling rate: 48.0 KHz
Video delay  : -1s 486ms
Stream size  : 6.73 MiB (3%)
Language : German
Language, more info  : Clean effects


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/lis

Re: [vdr] merging correctly several .ts files to a single ts file or better mkv

[Lucian Muresan]

On 01.04.2010 13:23, Eric Valette wrote:
> 
>> Where do you take that time offset value from? 
> I play the simplified ts file using smplayer -ss is the start in the ts
> file, -t is the duration to add
> to the -ss value (I would have prefered the absolute end avoiding a
> substract...).

So for now you're determining that value sort of experimentally?

>> I'm also working on such
>> kind of scripts right now, because I want to remux especially HD
>> recordings to MKV. In the case of movies broadcasted by ARD HD or ZDF HD
>> (7...@50hz), they are full of so-called filler-NALUs, which can be
>> removed just by muxing into MKV not directly by ffmpeg, but by mkvmerge,
>> which shrinks a 10GB movie to about 3GB. 
> You mean you extract the various component (audio, video) into separate
> files
> and then reassemble them using mkvmerge?

Yes, I'm demuxing all the 000xy.ts files in all their component streams
with ffmpeg for now first, then multiplex the ones I want with mkvmerge.
I might switch to tsMuxeR, maybe also convert back to cleaned-up TS from
MKV also with tsMuxeR to make the smaller recording again playable by
VDR (I've read in the vdr-portal.de forum some users already
experimented with this).

>> My problem is still A/V sync,
>> all the original TS chunks (I also record into 200MB pieces, because of
>> fast editing in VDR) show video delays for each audio track of over 1
>> second, which is also very noticeable ion the final converted MKV. The
>> delays are reported both by tsMuxeR and mediainfo see for example the
>> "Video delay" value below:
>>   
> Yes I know this is why the "async 2, (+ vsync 2 for récent ffmpeg
> version)" is there. Without them I have the audio and the video out of
> sync just like you.
> 
> ffmpeg -y -i simplified1.ts  -vcodec copy -sameq -acodec copy -vsync 2 -async 
> 2 -f matroska 1.mkv
> 
> I'll post the mediainfo on the ts and mkv when back at home.

By "simplified" you mean the merged ts?

Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] yacoto TS patches [was: Re: converting .TS recordings to DIVX (or XVID)]

[Lucian Muresan]

On 14.07.2010 14:15, martinez wrote:
> Does anybody have the config files for commands to select a recording in VDR 
> and convert it to divx or xvid using ffmpeg?

Hi,

attached you will find my current TS and customization patches to
HelAu's vdr-yacoto-0.2.1 plugin and Yacoto worker scripts 0.0.2 in form
of Gentoo ebuilds (the bare patches are in the respective "files"
subdirectories in the archive if you're not using Gentoo, and the the
original distribution archives the patches are based based on can be
downloaded here: http://htpc-forum.de/index.php?url=downloads.php). They
work for me for SD recordings in TS format. I'm also working on
extending them with a new target for remuxing HD TS recordings into MKV,
and planning to submit the patches to HelAu's bugtracker...

Cheers,
Lucian


vdr-yacoto-ebuilds+patches-20100714.tar.bz2
Description: Binary data
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] yacoto TS patches + Gentoo ebuilds [was: converting .TS recordings to DIVX (or XVID)]

[Lucian Muresan]

On 14.07.2010 17:35, Helmut Auer wrote:
> Hello
>>
>> attached you will find my current TS and customization patches to
>> HelAu's vdr-yacoto-0.2.1 plugin and Yacoto worker scripts 0.0.2 in form
>> of Gentoo ebuilds (the bare patches are in the respective "files"
>> subdirectories in the archive if you're not using Gentoo, and the the
>> original distribution archives the patches are based based on can be
>> downloaded here: http://htpc-forum.de/index.php?url=downloads.php). They
>> work for me for SD recordings in TS format. I'm also working on
>> extending them with a new target for remuxing HD TS recordings into MKV,
>> and planning to submit the patches to HelAu's bugtracker...
>>
> There's a newer version available, but only as part of Gen2VDR.
> You can get it here:
> http://www.htpc-forum.de/download/yacoto.tgz

Thanks for the updated versions of the yacoto plugin ansd scripts. I
also updated my patches and opened http://redmine.gen2vdr.org/issues/269
and http://redmine.gen2vdr.org/issues/270 with the 2 patches. There one
can also find links to working Gentoo ebuilds, and the for those ebuilds
I allowed myself to split the latest archive in the 2 parts and host
them on my web space here: http://www.muresan.de/vdr/yacoto/

Have fun,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Developer versions

[Lucian Muresan]

On 13.01.2011 13:31, Rolf Ahrenberg wrote:
> On Wed, 12 Jan 2011, VDR User wrote:
> 
>> And you get VDR's full osd doing this?
> 
> FYI, xineliboutput provides three different OSD implementations:
> xinelib, composite HUD, and opengl HUD. For example the composite HUD
> OSD is drawn directly onto transparent window located exactly over the
> (xine-lib powered) video window and therefore is completely independent
> from the actual video decoding library.

Maybe a dumb question, but does that mean, at least in theory, something
like XBMC could be extended to be able to talk to vdr-xineliboutout just
like vdr-sxfe does for example and also get the genuine VDR OSD and
render it over the video streamed from VDR? If yes, what are roughly the
things that have to be implemented? I'm asking because I'd like to be
able to access _full_ VDR functionality (like editing for example to
name just an important one) without leaving XBMC, which is not provided
by the current streamdev or VNSI addons in XBMC. That would give us
video decoding without xine-lib, a really nice UI and true unification
of both VDR and XBMC experiences. Of course, there also has to be a
functionality in the event system of XBMC which toggles control between
XBMC and VDR...

Cheers,
Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Deinterlace video (was: Replacing aging VDR for DVB-S2)

[Lucian Muresan]

On 28.01.2011 10:57, Stuart Morris wrote:
[..]
> Standard definition video is going to be harder than I thought.
> I used xrandr to set this mode via HDMI to my LCD TV:
> # 1440x576i @ 50Hz (EIA/CEA-861B)
> ModeLine "1440x576" 27.000 1440 1464 1590 1728 576 581 587 625 -hsync -vsync 
> Interlace
> The TV reported mode 576i ok, but the desktop graphics were unreadable.

I guess that's because it's a very strange resolution with strange
aspect ratio, shouldn't that have been 1024x576i to maintain a 16:9
aspect ratio with square pixels? I only found 1440 on BBC HD which
broadcasts in 1080i but sets the aspect ratio flag to 16:9...

Lucian

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] TT S2 3200 and tuning timeout

[Lucian Muresan]

Hi,

On 26.02.2011 11:42, Davide Chiarini wrote:
> Hi all
> 
> I'm having some troubles with my two DVB-S2 "TechnoTrend TT-budget
> S2-3200" cards.
> At first I thought about driver issues but now I think the problem could
> lie within vdr.
> 
> Up until a couple of weeks ago I was running vdr 1.7.12 on debian lenny
> with stock kernel 2.6.26, and everything worked fine.
> Then my provider changed the SR of the DVB-S2 channels from 27500 to
> 29900. I could still watch regular channels, but HD channels where garbled.
> So I updated the kernel with debian backports (2.6.32). Nothing changed.
> Then I updated the dvb drivers (latest checkout I tried is the one from
> 25/02).
> With this update, DVB-S2 channels work perfectly, however, when I try to
> tune to SD channels in vdr I get " frontend 1/0 timed out while tuning
> to channel" errors.
> I tried watching those channels with kaffeine, and it works fine.
> Also, If I tune to a SD channel with szap prior to starting vdr, I get a
> FE_HAS_LOCK. If I then start vdr on that channel, all the channels from
> that transponder are visible. But If I try to change channel to anything
> not HD i get the timeout error.
> 
> I tried all combination of drivers above with vdr 1.7.12 and vdr 1.7.16,
> the results are identical.
> 
> any pointers? I'm running out of ideas...

for me, these kind of problems (same card as you have) seem to be
vanished since using this patch
https://patchwork.kernel.org/patch/244201/ this is not yet included even
in the 2.6.38 kernel which I'm using now. Btw, another one useful for
getting at least some indication in femon with this card is this one:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg22085.html

Regards,
Lucian



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Re: LCD plugin

[Lucian Muresan]

Hi Simon,

Simon Baxter wrote:
>> Hi,
>>
>> why dont you take a look at the files bundeled with the plugin?
> 
> I must have overlooked them?
> 
>> are you looking out for - a text or gfx display?
> 
> Graphics - nice high res colour would be nice
> 
>> 3.5" seems a little small for me. i dont think there are plenty of
>> displays in this size out there.
> 
> Limited space in my Shuttle :)
> 
> 
>> are you fine with soldering yourself?
> 
> absolutely!  What do you suggest?

You might want to also look for graphical Noritake VFD displays for
example, http://www.noritake-elec.com/, you can find PDFs with exact
dimensions on their website (at least it was possible some time ago,
haven't checked recently), and even data sheets with the command set if
there is no driver yet, in graphlcd-base (used by vdr-graphlcd for
example). I have a 128x64 800A series and am very pleased with it.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Re: AW: Xineliboutput with DirectFB

[Lucian Muresan]

Jaakko Kyro wrote:
> On Wednesday 08 November 2006 15:18, Tony Houghton wrote:
>> In <[EMAIL PROTECTED]>, Jaakko Kyro wrote:
[..]
>> This is how I run it:
>>
>> df_xine -a 5:4 -l 0 -s -f top vdr:/tmp/vdr-xine/stream#demux:mpeg_pes
> 
> The problem is that the /tmp/vdr-xine/stream doesn't exist here. Actually, 
> this being a Gentoo system it should appear in 
> /tmp/vdr/xine/stream 
> but they don't. :( 
> I get no clue from the log output either.

If you emerged vdr-xine and lib-xine on gentoo with the "vdr-net" USE
flag set, there is no pipe, but a socket, at which you could also
connect from a different host:
vdr-socket:/localhost#demux:mpeg_pes

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr