Re: [vdr] Dropping pixel font in VDR 1.5?
On 29 May 2007, at 17:16, Klaus Schmidinger wrote: Anti-aliased freetype fonts really do look good ;-) Have you tried either of the soft output methods (libxine, softdevice), or are you still running FF cards only? -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Dropping pixel font in VDR 1.5?
On 05/29/07 18:40, Torgeir Veimo wrote: On 29 May 2007, at 17:16, Klaus Schmidinger wrote: Anti-aliased freetype fonts really do look good ;-) Have you tried either of the soft output methods (libxine, softdevice), or are you still running FF cards only? I'm only running a FF card (with 4MB memory, so I can display the OSD with 256 colors). Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] How to change Pro7 SAT1 Channels via Menu
Hello List, What is the preferred way to change the settings of the channels Pro7 ... ? I have a lot of users which do not have a pc to take the easy way (shutting down vdr and editing channels.conf) Yesterday I had a phone call with one of these and changing the channel settings via the menu is horrible, because after changing the channel some minutes later vdr replaces the channel with the old settings. Looks like he has to turn the automagic channel update off for doing this ? Now the next persons have the same problem and I don't like to spent more time on the phone then necessary ;) -- Helmut Auer, [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to change Pro7 SAT1 Channels via Menu
Hello Carsten Looks like he has to turn the automagic channel update off for doing this ? Now the next persons have the same problem and I don't like to spent more time on the phone then necessary ;) Yeah, there is a trap. ;-) If you do not change the service ID, vdr correctly identifies the channel as the old channel and correctly restores the parameters, which is not what most people would expect. Exactly the same happens if you select an incorrect SID and I also have seen that a correct SID sometimes does not help. Entering everything correct, pressing ok, the new channel is correct. Zapping a litle bit, coming back and the channel is the old one In fact, that does make the feature which allows you to edit the other parameters somewhat funny. ;-) I guess there are two ways to get to the desired result: 1) Change *all* parameters including the service ID. 2) Look for the new channel entries at the end of your list and move them to the desired position. The second one is a no go - tell an old man how he should move channel 2000 to channel 2 ;) There should be an option to enter the desired number for the channel. -- Helmut Auer, [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new video-card with h264 decoder
E.g. 8500-series seems very good alternative. Don't know whether there is linux support for it yet. yes, as far as I understand this link http://www.nvnews.net/vbulletin/showthread.php?t=91896 there's linux drivers for this card, but the support of technology for h264 acceleration - NVIDIA® PureVideo™ didn't include in it :( Igor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to change Pro7 SAT1 Channels via Menu
Helmut Auer wrote: ... 2) Look for the new channel entries at the end of your list and move them to the desired position. The second one is a no go - tell an old man how he should move channel 2000 to channel 2 ;) There should be an option to enter the desired number for the channel. Yeah, I know, it is another weak point in VDRs GUI. I personally do not care much, because I know how to use a text editor. ;-) However, there is a shortcut: If you want to move channel 2000 to position 2, go to channel 2000 in the channel list, press Mark (blue), press 2 and then OK. Carsten. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1.5.x Shutdown
Chris wrote:
If I use an 'empty' shutdown script that just starts with #!/bin/sh or
bash or whatever, the script itself becomes a zombie. And if I use a script
with just an empty line, sh becomes the zombie. So in either way,
something is wrong and it can not be the script's fault.
I've checked this again, and you really have to care about processes
even in their own process group. After some research, I think the
double-fork trick is the best way to fix this: Make the script a
grandchild of VDR and let the intermediate child do an instant
wait-friendly exit. This makes the script an orphan that does not get a
zombie any more.
A patch is attached.
waitpid( -1, dummy, WNOHANG) called at some place later should do the
trick. Or waitpid() explicitly for the child's PID, if we want to store
the PID anywhere.
If the script may run longer than VDR, then VDR cannot wait for it.
Thats the problem.
Cheers,
Udo
--- thread.c.bak2007-05-29 21:07:27.0 +0200
+++ thread.c2007-05-29 21:12:56.0 +0200
@@ -12,6 +12,7 @@
#include linux/unistd.h
#include malloc.h
#include stdarg.h
+#include stdlib.h
#include sys/resource.h
#include sys/syscall.h
#include sys/time.h
@@ -507,7 +508,7 @@
if (pid 0) { // parent process
int status = 0;
- if (!Detached waitpid(pid, status, 0) 0) {
+ if (waitpid(pid, status, 0) 0) {
LOG_ERROR;
return -1;
}
@@ -515,6 +516,9 @@
}
else { // child process
if (Detached) {
+// Fork again and let first child die
+// Grandchild stays alive without parent
+if (fork() 0) exit(0);
// Start a new session
pid_t sid = setsid();
if (sid 0)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new video-card with h264 decoder
Igor Nikanov wrote: E.g. 8500-series seems very good alternative. Don't know whether there is linux support for it yet. yes, as far as I understand this link http://www.nvnews.net/vbulletin/showthread.php?t=91896 there's linux drivers for this card, but the support of technology for h264 acceleration - NVIDIA® PureVideo™ didn't include in it :( Well, this is hardly news to me. None of these advanced features are implemented in Linux drivers for some reason. Same goes for AMD/ATI. I'm hoping that Intel makes an exception with their 3000 series. It may not be fast in 3D but if they provide open source driver with accelerated decoding of HD materian then I'll switch to Intel the second. There should be either available or to become available also a stand-alone card and not just a mboard with integrated solution (this does not interest me due other reasons). Br, Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to change Pro7 SAT1 Channels via Menu
Helmut Auer wrote: Hello List, What is the preferred way to change the settings of the channels Pro7 ... ? I have a lot of users which do not have a pc to take the easy way (shutting down vdr and editing channels.conf) That's the hard way. ;-) Yesterday I had a phone call with one of these and changing the channel settings via the menu is horrible, because after changing the channel some minutes later vdr replaces the channel with the old settings. Looks like he has to turn the automagic channel update off for doing this ? Now the next persons have the same problem and I don't like to spent more time on the phone then necessary ;) Basically it's very easy: 0. Set 'Update channels' to 'add new transponder'. Wait until vdr has added the new channels (EPG scan). 1. Enter Channels menu: - Move cursor to 'ProSieben' - Press '0' until channels are sorted alphabetically. - Move cursor to the new 'ProSieben' channel. - Press blue (mark). - Either enter new channel number directly and press ok, or use up/down to select the channel which should be replaced (i.e. old ProSieben) and press ok. 2. Update timers in the Timer Menu to use the new channel. 3. Finally delete old channels (Channels menu). Note: It is very convenient that vdr issues a warning, if there is a timer for the channel to be deleted. Oliver -- VDR Remote Plugin 0.3.9 available at http://www.escape-edv.de/endriss/vdr/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Dropping pixel font in VDR 1.5?
Hi, Klaus Schmidinger wrote: Anti-aliased freetype fonts really do look good ;-) Have you tried either of the soft output methods (libxine, softdevice), or are you still running FF cards only? I'm only running a FF card (with 4MB memory, so I can display the OSD with 256 colors). vdr-xine can handle 16 fullscreen OSD areas with independent 256 color palettes. The only drawback is, that some of xine's video output devices only support overlays with 16 colors. I hope that there will be an option to still get the plain old 16 color STNG OSD. Or will it depend on the result of cOsd::CanHandleAreas()? Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Dropping pixel font in VDR 1.5?
On 05/29/07 22:05, Reinhard Nissl wrote:
Hi,
Klaus Schmidinger wrote:
Anti-aliased freetype fonts really do look good ;-)
Have you tried either of the soft output methods (libxine,
softdevice), or are you still running FF cards only?
I'm only running a FF card (with 4MB memory, so I can display
the OSD with 256 colors).
vdr-xine can handle 16 fullscreen OSD areas with independent 256 color
palettes. The only drawback is, that some of xine's video output devices
only support overlays with 16 colors.
I hope that there will be an option to still get the plain old 16
color STNG OSD. Or will it depend on the result of cOsd::CanHandleAreas()?
Here's how it will be handled:
osd = cOsdProvider::NewOsd(Setup.OSDLeft, Setup.OSDTop);
tArea Areas[] = { { x0, y0, x7 - 1, y7 - 1, 8 } };
if (Setup.AntiAlias osd-CanHandleAreas(Areas, sizeof(Areas) /
sizeof(tArea)) == oeOk) {
osd-SetAreas(Areas, sizeof(Areas) / sizeof(tArea));
osd-SetAntiAliasHint(9, 7);
}
else {
tArea Areas[] = { { x0, y0, x7 - 1, y7 - 1, 4 } };
if (osd-CanHandleAreas(Areas, sizeof(Areas) / sizeof(tArea)) == oeOk)
osd-SetAreas(Areas, sizeof(Areas) / sizeof(tArea));
else {
tArea Areas[] = { { x0, y0, x7 - 1, y3 - 1, 2 },
{ x0, y3, x3 - 1, y4 - 1, 1 },
{ x3, y3, x4 - 1, y4 - 1, 2 },
{ x4, y3, x7 - 1, y4 - 1, 2 },
{ x0, y4, x7 - 1, y7 - 1, 4 }
};
osd-SetAreas(Areas, sizeof(Areas) / sizeof(tArea));
}
}
There's a global Setup.AntiAlias option through which the user can
turn off anti-aliasing. In that case it immediately falls back to
4bpp. If Setup.AntiAlias is on, it tries to use 8bpp and falls back
to 4bpp if that's not possible.
osd-SetAntiAliasHint(9, 7) tells the OSD how many colors will be used
at all, and how many color combinations will be used with anti-aliasing.
That way the OSD can evenly distribute the available palette entries
to the various color blends by limiting the number of color levels
per color combination.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
