Re: [vdr] Yaepghd record dialog
I'm not the developer of the yaepghd plugin, but I had a deeper look at
the source code. Many things of the record dialog have already been
implemented, but the record dialog isn't called anywhere in the source
code. So I think this done intentionally. I implemented a small patch,
that adds the possibility to set timer with the red button without any
record dialog. The patch attached contains also some other minor
improvements from other authors. If you have questions concerning the
patch, you can ask at vdr-portal.de
http://www.vdr-portal.de/board/thread.php?threadid=83864&threadview=0&page=3
(even it's a German forum, you will get answers in English ;) ).
> I have been trying out the yaepghd plugin. It looks very impressive
> but the record dialog appears to be disabled. Does anyone know if this
> has been intentionally disabled or is only partially implemented?
>
> There has been no development activity on this plugin for about
> 9 months now.
>
>
>
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
diff -NaurwB yaepghdorig/po/de_DE.po yaepghdpatched/po/de_DE.po
--- yaepghdorig/po/de_DE.po 2009-11-09 20:00:46.0 +0100
+++ yaepghdpatched/po/de_DE.po 2009-11-09 20:26:29.0 +0100
@@ -6,9 +6,9 @@
msgstr ""
"Project-Id-Version: Yaepghd 0.0.1\n"
"Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2009-01-30 20:42+0200\n"
-"PO-Revision-Date: 2009-01-28 10:51+0200\n"
-"Last-Translator: Klaus Schmidinger \n"
+"POT-Creation-Date: 2009-10-18 22:24+0200\n"
+"PO-Revision-Date: 2009-10-15 22:58+0100\n"
+"Last-Translator: Tomas Saxer \n"
"Language-Team: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=ISO-8859-15\n"
@@ -17,14 +17,15 @@
msgid "No Info"
msgstr "Keine Daten verfügbar."
-msgid "Screenshot"
-msgstr ""
+#, fuzzy
+msgid "Timer"
+msgstr "Zeit-Format"
msgid "Page up"
-msgstr ""
+msgstr "Seite hoch"
msgid "Page down"
-msgstr ""
+msgstr "Seite runter"
msgid "Once"
msgstr "Sobald"
@@ -54,10 +55,10 @@
msgstr ""
msgid "Up"
-msgstr ""
+msgstr "Hoch"
msgid "Down"
-msgstr ""
+msgstr "Runter"
msgid "Manual"
msgstr ""
@@ -83,6 +84,9 @@
msgid "Channel order"
msgstr ""
+msgid "Channel number"
+msgstr ""
+
msgid "Yet another EPG in HD"
msgstr ""
diff -NaurwB yaepghdorig/po/fi_FI.po yaepghdpatched/po/fi_FI.po
--- yaepghdorig/po/fi_FI.po 2009-11-09 20:00:46.0 +0100
+++ yaepghdpatched/po/fi_FI.po 2009-11-09 20:26:29.0 +0100
@@ -7,7 +7,7 @@
msgstr ""
"Project-Id-Version: Yaepghd 0.0.1\n"
"Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2009-01-30 20:42+0200\n"
+"POT-Creation-Date: 2009-10-18 22:24+0200\n"
"PO-Revision-Date: 2009-01-28 10:51+0200\n"
"Last-Translator: Rolf Ahrenberg \n"
"Language-Team: \n"
@@ -18,8 +18,9 @@
msgid "No Info"
msgstr "Ei tietoja"
-msgid "Screenshot"
-msgstr "Ota kuva"
+#, fuzzy
+msgid "Timer"
+msgstr "Kellonajan esitysmuoto"
msgid "Page up"
msgstr "Sivu ylös"
@@ -84,8 +85,15 @@
msgid "Channel order"
msgstr "Kanavajärjetys"
+#, fuzzy
+msgid "Channel number"
+msgstr "Kanavajärjetys"
+
msgid "Yet another EPG in HD"
msgstr "Vaihtoehtoinen ohjelmaopas"
msgid "YaepgHD"
msgstr "Ohjelmaopas (YaepgHD)"
+
+#~ msgid "Screenshot"
+#~ msgstr "Ota kuva"
diff -NaurwB yaepghdorig/yaepghd.c yaepghdpatched/yaepghd.c
--- yaepghdorig/yaepghd.c 2009-11-09 20:00:46.0 +0100
+++ yaepghdpatched/yaepghd.c 2009-10-21 12:40:41.0 +0200
@@ -24,6 +24,8 @@
#include
#include
#include
+#include
+#include
#ifndef YAEPGHDVERSNUM
#error "You must apply the yaepghd patch for VDR!"
@@ -36,6 +38,7 @@
/**
* Macros
*/
+#define WO__MSG_RECDLG
#ifdef DEBUG
#define ASSERT assert
@@ -70,6 +73,7 @@
#define GRID_TIME_FONT THEME_FONT("gridTimeFont")
#define GRID_DATE_FONT THEME_FONT("gridDateFont")
#define EVENT_TITLE_FONT THEME_FONT("eventTitleFont")
+#define EVENT_INFO_FONT THEME_FONT("eventInfoFont")
#define EVENT_TIME_FONT THEME_FONT("eventTimeFont")
#define EVENT_DESC_FONT THEME_FONT("eventDescFont")
#define EVENT_DATE_FONT THEME_FONT("eventDateFont")
@@ -81,6 +85,7 @@
#define GRID_DATE_COLOR THEME_COLOR("gridDateColor")
#define GRID_SEP_COLOR THEME_COLOR("gridSepColor")
#define EVENT_TITLE_COLORTHEME_COLOR("eventTitleColor")
+#define EVENT_INFO_COLOR THEME_COLOR("eventInfoColor")
#define EVENT_TIME_COLOR THEME_COLOR("eventTimeColor")
#define EVENT_DESC_COLOR THEME_COLOR("eventDescColor")
#define EVENT_DATE_COLOR THEME_COLOR("eventDateColor")
@@ -90,6 +95,7 @@
#define GRID_TIME_GEOM THEME_GEOM("gridTimeGeom")
#define GRID_DATE_GEOM THEME_GEOM("gridDateGeom")
#define EVENT_TITLE_GEOM THEME_GEOM("eventTitleGeom")
+#define EVENT_INFO_GEOM THEME_GEOM("eventInfoGeom")
#define EVENT_TIME_GEOM THEME_GEOM
[vdr] [patch] vdr-1.6 merge transparent color
Hi,
this patch merge all color that are transparent (alpha = 0) in ClosestColor.
This allow to save precious color Index on ff cards.
Matthieu
--- vdr-1.6.0/osd.c 2007-10-12 14:38:36.0 +0200
+++ vdr-1.6.0p/osd.c 2009-11-21 21:33:09.0 +0100
@@ -141,6 +141,8 @@
int B1 = (Color & 0x00FF);
for (int i = 0; i < numColors; i++) {
int A2 = (color[i] & 0xFF00) >> 24;
+ if (A2 == 0 && A1 == 0)
+ diff = 0;
int R2 = (color[i] & 0x00FF) >> 16;
int G2 = (color[i] & 0xFF00) >> 8;
int B2 = (color[i] & 0x00FF);
@@ -149,6 +151,8 @@
d = diff;
n = i;
}
+ if (d == 0)
+ break;
}
return d <= MaxDiff ? n : -1;
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [path] vdr-1.6 better spu on ff card
Hi, this patch try to handle case where the osd is limited (for example on ff card). For that it try to split area, count the really needed bpp (all transparent index can be merged together and will with my previous patch in osd.c). Also it fix a bug in the current version : removing all the transparent baground area is ok only if it is recomputed at each draw. Otherwise a highlight request can happen outside the computed area. With this patch I can navigate in dvd menu that produce oeOutOfMemory before. Matthieu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [path] vdr-1.6 better spu on ff card
matthieu castet a écrit :
Hi,
this patch try to handle case where the osd is limited (for example on
ff card).
For that it try to split area, count the really needed bpp (all
transparent index can be merged together and will with my previous patch
in osd.c).
Also it fix a bug in the current version : removing all the transparent
baground area is ok only if it is recomputed at each draw. Otherwise a
highlight request can happen outside the computed area.
With this patch I can navigate in dvd menu that produce oeOutOfMemory
before.
Matthieu
I forgot the patch...
--- vdr-1.6.0/dvbspu.c 2007-02-03 11:13:18.0 +0100
+++ vdr-1.6.0p/dvbspu.c 2009-11-21 21:48:54.0 +0100
@@ -335,6 +335,35 @@
return size;
}
+int cDvbSpuBitmap::getMinBpp(const aDvbSpuPalDescr paldescr)
+{
+int col = 1;
+for (int i = 0; i < 4; i++) {
+if (paldescr[i].trans != 0) {
+col++;
+}
+}
+return col > 2 ? 2 : 1;
+}
+
+int cDvbSpuDecoder::CalcAreaBpp(cBitmap *fgbmp, cBitmap *bgbmp)
+{
+int fgbpp = 0;
+int bgbpp = 0;
+int ret;
+if (fgbmp) {
+fgbpp = spubmp->getMinBpp(hlpDescr);
+}
+if (bgbmp) {
+bgbpp = spubmp->getMinBpp(palDescr);
+}
+ret = fgbpp + bgbpp;
+if (ret > 2)
+ret = 4;
+return ret;
+}
+
+
void cDvbSpuDecoder::Draw(void)
{
cMutexLock MutexLock(&mutex);
@@ -342,43 +371,89 @@
Hide();
return;
}
-
+sDvbSpuRect bgsize;
cBitmap *fg = NULL;
cBitmap *bg = NULL;
-sDvbSpuRect bgsize;
-sDvbSpuRect hlsize;
-
-hlsize.x1 = hlpsize.x1;
-hlsize.y1 = hlpsize.y1;
-hlsize.x2 = hlpsize.x2;
-hlsize.y2 = hlpsize.y2;
if (highlight)
-fg = spubmp->getBitmap(hlpDescr, palette, hlsize);
+fg = spubmp->getBitmap(hlpDescr, palette, hlpsize);
if (spubmp->getMinSize(palDescr, bgsize))
bg = spubmp->getBitmap(palDescr, palette, bgsize);
-sDvbSpuRect areaSize = CalcAreaSize(hlsize, fg, bgsize, bg);
+if (osd == NULL) {
+restricted_osd = false;
+osd = cOsdProvider::NewOsd(0, 0);
+
+tArea Area = { size.x1, size.y1, size.x2, size.y2, 4};
+if (osd->CanHandleAreas(&Area, 1) != oeOk)
+restricted_osd = true;
+else
+osd->SetAreas(&Area, 1);
+}
+if (restricted_osd) {
+sDvbSpuRect hlsize;
+bool setarea = false;
+/* reduce fg area (only valid if there is no bg below) */
+if (fg) {
+spubmp->getMinSize(hlpDescr,hlsize);
+/* clip to the highligh area */
+setMax(hlsize.x1, hlpsize.x1);
+setMax(hlsize.y1, hlpsize.y1);
+setMin(hlsize.x2, hlpsize.x2);
+setMin(hlsize.y2, hlpsize.y2);
+if (hlsize.x1 > hlsize.x2 || hlsize.y1 > hlsize.y2) {
+hlsize.x1 = hlsize.x2 = hlsize.y1 = hlsize.y2 = 0;
+}
+}
+sDvbSpuRect areaSize = CalcAreaSize((fg && bg) ? hlpsize : hlsize, fg, bgsize, bg);
-if (!fg || !bg || !osd) {
- Hide();
- }
+#define DIV(a, b) (a/b)?:1
+for (int d = 1; !setarea && d <= 2; d++) {
-if (bg || fg) {
-if (osd == NULL) {
- osd = cOsdProvider::NewOsd(0, 0);
- if ((areaSize.width() & 3) != 0)
- areaSize.x2 += 4 - (areaSize.width() & 3);
- tArea Area = { areaSize.x1, areaSize.y1, areaSize.x2, areaSize.y2, (fg && bg) ? 4 : 2 };
- if (osd->SetAreas(&Area, 1) != oeOk)
+/* first try old behaviour */
+tArea Area = { areaSize.x1, areaSize.y1, areaSize.x2, areaSize.y2, DIV(CalcAreaBpp(fg, bg), d) };
+
+if ((Area.Width() & 7) != 0)
+Area.x2 += 8 - (Area.Width() & 7);
+
+if (osd->CanHandleAreas(&Area, 1) == oeOk &&
+osd->SetAreas(&Area, 1) == oeOk)
+setarea = true;
+
+/* second try to split area if there is both area */
+if (!setarea && fg && bg) {
+tArea Area_Both [2] = {
+{bgsize.x1, bgsize.y1, bgsize.x2, bgsize.y2, DIV(CalcAreaBpp(0, bg), d)},
+{hlpsize.x1, hlpsize.y1, hlpsize.x2, hlpsize.y2, DIV(CalcAreaBpp(fg, 0), d)}
+};
+if (!Area_Both[0].Intersects(Area_Both[1])) {
+/* there is no intersection. We can reduce hl */
+Area_Both[1].x1 = hlsize.x1;
+Area_Both[1].y1 = hlsize.y1;
+Area_Both[1].x2 = hlsize.x2;
+Area_Bot
Re: [vdr] mdadm software raid5 arrays?
On 18.11.2009 18:28, H. Langos wrote: I/O-load can have some nasty effects. E.g. if your heads have to jump back and forth between an area from where you are reading and an area to which you are recording. I remember reading some tests about file system write strategies that showed major differences between file systems when writing several file streams in parallel. IIRC the old EXT2/3 was way at the lower end, while XFS scored more at the upper end. One major point here is to avoid heavy seeking, by massive use of write caching and read ahead caching. Another one is a smart allocation strategy so that the files don't get interleaved too much, and so that metadata doesn't have to be read/written too often. (-> extents) In a raid1 setup you have two sets of heads that you can work with. (Or more if you are willing to put in more disks.) In theory yes, but I would really like to know whether raid systems are actually smart enough to split their read operations between the heads in an efficient way. For example, while reading two data streams, its probably the best to use one head for each stream. Unless one of the streams needs a higher bandwidth, in which case it would be more wise to use one head exclusively, and let the other jump between the streams. And what if there are several small reads in parallel? Which head should be interrupted? In the end you can probably put a lot of strategy fine tuning into this, and there will still be situations where a different strategy would still improve performance in some scenarios - or in others not. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [path] vdr-1.6 better spu on ff card
Did you know Klaus is updating the OSD to 24bit truecolor? I don't think he is going to adapt 1.6.x further though so you might need at least 1.7.10(?) to use it. Cheers ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
