Beiträge von zulu

Moin Klaus,

hast du dir vdr-1.7.7 und xineliboutput mit unskaliertem osd mal angeschaut?
Du wirst es so wahrscheinlich nicht übernehmen können/wollen aber von der Funktion her klappt das bei mir sehr gut.

Gruß
Marc

und damit kämme das Seitenverhältnis auch aus dem Setup:

void cOsdProvider::UpdateOsdSize(bool Force)
{
  int Width;
  int Height;
  eVideoAspect Aspect;


  if (Setup.DisplayWidth > 720 || Setup.DisplayHeight > 576) {
     Width  = Setup.DisplayWidth;
     Height = Setup.DisplayHeight;
     if (Setup.VideoFormat == 0)
        Aspect = va4_3;
     else if (Setup.VideoFormat == 1)
        Aspect = va16_9;
     else
        Aspect = va16_9;
     }
  else
     cDevice::PrimaryDevice()->GetVideoSize(Width, Height, Aspect); 


...

Und noch einen gegen osdadjust-0.0.5. Damit lässt sich die OSD-Größe dann bequem einstellen.

diff -ruNp osdadjust-0.0.5/screenmenu.c osdadjust-0.0.5-displaysize/screenmenu.c
--- osdadjust-0.0.5/screenmenu.c	2009-08-05 15:23:09.000000000 +0200
+++ osdadjust-0.0.5-displaysize/screenmenu.c	2009-08-05 22:01:23.000000000 +0200
@@ -56,6 +56,11 @@ cScreenMenu::cScreenMenu()
   else
      height = (config.VideoFormat == 2) ? 480 : 576;
 
+  if (Setup.DisplayWidth > 720 || Setup.DisplayHeight > 576) {
+     width = Setup.DisplayWidth;
+     height = Setup.DisplayHeight;
+     }
+
   if (config.AspectRatio == 0)
      aspect = Aspect;
 #else

Hi,

beim reelbox-patch bin ich der falsche Ansprechpartner.
Da habe ich weder Karte noch Plan

Gruß
Marc

Hallo,

anbei drei kleine Patches gegen plain vdr oder vdr-ext und xineliboutput-cvs.
Damit habe ich mit vdr-1.7.7 und xineliboutput ein unskaliertes OSD auf meinem 1440x900 Display.

Die Patches gegen den VDR ergänzen Einstellungen - DVB um zwei Einträge für Bildschirm-breite und -höhe. Damit kann die Auflösung des Bildschirms angegeben werden.
In osd.c wird dann noch UpdateOsdSize verändert wobei dieser Teil sicher noch verbessert werden kann:

int Height;
   eVideoAspect Aspect;
   cDevice::PrimaryDevice()->GetVideoSize(Width, Height, Aspect);
+  if (Setup.DisplayWidth > 720 || Setup.DisplayHeight > 576) {
+     Width = Setup.DisplayWidth;
+     Height = Setup.DisplayHeight;
+     }
   if (Width != oldWidth || Height != oldHeight || Aspect != oldAspect || Force) {
      Setup.OSDLeft = int(round(Width * Setup.OSDLeftP));
      Setup.OSDTop = int(round(Height * Setup.OSDTopP));

Der Patch gegen xineliboutput sieht so aus:

diff -ruNp xineliboutput-cvs20090504/osd.c xineliboutput-cvs20090504-displaysize/osd.c
--- xineliboutput-cvs20090504/osd.c	2009-05-03 22:35:36.000000000 +0200
+++ xineliboutput-cvs20090504-displaysize/osd.c	2009-05-06 09:45:49.000000000 +0200
@@ -365,12 +365,19 @@ eOsdError cXinelibOsd::SetAreas(const tA
   }
 
   // Detect full OSD area size
+#if APIVERSNUM >= 10707
+  if (Setup.DisplayWidth > 720 || Setup.DisplayHeight > 576) {
+    m_ExtentWidth  = Setup.DisplayWidth;
+    m_ExtentHeight = Setup.DisplayHeight;
+    LOGDBG("Detected HD Display, using OSD size %dx%d", m_ExtentWidth, m_ExtentHeight);
+#else
   if(Left() + Width() > 720 || Top() + Height() > 576) {
     m_ExtentWidth  = Setup.OSDWidth  + 2 * Setup.OSDLeft;
     m_ExtentHeight = Setup.OSDHeight + 2 * Setup.OSDTop;
     LOGDBG("Detected HD OSD, size > %dx%d, using setup values %dx%d",
            2*Left() + Width(), 2*Top() + Height(),
            m_ExtentWidth, m_ExtentHeight);
+#endif
   } else {
     m_ExtentWidth  = 720;
     m_ExtentHeight = 576;

Alles in allem also recht überschaubar

Gruß
Marc

Moin,

danke für die Rückmeldungen.

Zitat

Mir ist beim überfliegen des Patches aufgefallen das beim nutzen von
SETUP=1
fast der komplette tinyxml code verwendet wird.

tinyxml sourcen werden unter einer anderen Lizenz als der VDR veröffentlicht

Siehe --> http://sourceforge.net/projects/tinyxml --> Details

License: zlib/libpng License

Irgendwo müsste dann beim patchen noch ne Notiz auf die Lizenz hinterlassen werden.

Alles anzeigen

Da habe ich eigentlich nichts verändert. Ein Link zu sourceforge.net/projects/tinyxml steht auch im Copyright. Reicht das nicht? Wie müsste so was dann aussehen?

Zitat

Was mir seit ext-68 aufgefallen ist, ich habe zwar im menu/setup gesetzt das der vdr auf dem kanal starten soll auf dem er beendet wurde,
aber in der setup.conf wird dievariable

CurrentChannel = xxx

nicht gesetzt.
Kann aber auch mit dem nutzen der eHD zu tun haben, welche nicht das primary device ist (wie meine alte FF) und nicht im transfer modus angesprochen wird.
( Falls ich das richtig aus den vdr sourcen erlesen habe ) Augen rollen

Das habe ich geprüft (mit FF und xine), CurrentChannel wird gesetzt und der VDR startet auf dem zuletzt eingestellten Kanal.

Zitat

Falls noch nicht auf der linux-tv/vdr ML oder hier im forum gesehen...

TomG hat nen angepassten jumpplay patch für vdr-1.7.6 veröffenticht

Ist im Extensions-Patch 72 dabei.

Gruß
Marc

Zitat

- Anpassungen an vdr-1.7.7
- ttxtsubs für vdr-1.7.7
- Änderungen aus jumpplay-1.0-1.7.6 übernommen
- Änderungen aus liemikuutio-1.27 übernommen
- Compiler-Warnungen in config.c (CMDRECCMDI18N) und submenu.h (SETUP) beseitigt
- Ergänzung der italienischen Übersetzung - danke an Diego Pierotto
- hud-osd.diff und osdbase.diff nach vdr-1.7.0-ext_h264-s2ng-speedup.diff übernommen
- vdr-1.7.7-ext_reelbox7.diff, vdr-1.7.7-ext_speedup.diff und vdr-1.7.7-ext_gotox.diff beigelegt

Alles anzeigen

Gruß
Marc

Danke für den Tipp. Hab es eingebaut
ttxtsubs sind auch wieder dabei.

Gruß
Marc

Hi cyberjunk,

Zitat

EDIT4: osdbase.diff hinzugefügt. Der osdbase-Patch bewirkt, dass die Menüs vorm Schließen nicht geleert werden. Das Leeren bewirkt, dass die Menüeinträge sofort verschwinden und dann nur ein leere Menü ausgeblendet wird. Mit Patch werden nun auch die Menüpeinträge mit ausgeblendet (ist nur eine optische anpassung und nicht für den Softosd-Patch lebensnotwendig).

Wenn er sich nicht mit dem SOFTOSD-Patch für die FF-Karten beißt, könnte ich ihn aber da mit rein packen.

Beim Hud-Patch habe ich das Problem, das das drumherum größer wäre als der Patch und einfach ersetzen mache ich im Extensions-Patch nicht.

Was ich mir vorstellen könnte wäre so was:

--- vdr/config.h.orig
+++ vdr/config.h
@@ -72,9 +72,17 @@
 #endif /* DVLVIDPREFER */


 #define MINOSDWIDTH  480
+#ifdef  SET_MAXOSDWIDTH
+#define MAXOSDWIDTH SET_MAXOSDWIDTH
+#else
 #define MAXOSDWIDTH  672
+#endif
 #define MINOSDHEIGHT 324
+#ifdef SET_MAXOSDHEIGHT
+#define MAXOSDHEIGHT SET_MAXOSDHEIGHT
+#else
 #define MAXOSDHEIGHT 567
+#endif


 #ifdef USE_SOURCECAPS
 #define MAXDEVICES         16 // the maximum number of devices in the system

Dann kann jeder selber in der Make.config mit SET_MAXOSDWIDTH und SET_MAXOSDHEIGHT bestimmen was maximal gehen soll.

Gruß
Marc

Hi,

ein erster Versuch mit den Anpassungen an vdr-1.7.6
http://www.zulu-entertainment.…1.7.6_ext71-test1.tar.bz2

und ein zweiter Versuch mit liemikuutio-1.27 und ttxtsubs-0.1.0
http://www.zulu-entertainment.…1.7.6_ext72-test2.tar.bz2

Gruß
Marc

Hallo Sven,

Zitat

Original von SvenGWK
Mit welcher Grundlage / Distrie lässt sich denn XVDR am idealsten verwenden?
Alles was ich will ist Videoausgabe über meine Nvidia Graka mittels VPAU in Verbindung mit einer Satelco Easywatch.

Das ganze bedienbar ohne tastatur und mit nvram-wakeup unterstützung.
Funktioniert das mit xvdr?

Ich habe jetzt seit Samstag keinen funktionierenden VDR mehr, möchte aber nicht aufgebene und zurückbauen (Platte mit existierender, funktionstüchtiger Gen2VDR 2.0 Installation + FF Karte sind ja noch vorhanden)

Alle bisherigen Versuche sind gescheitert, XVDR habe ich noch nicht probiert.

Alles anzeigen

Ubuntu 8.10 oder Sidux.
Eine komplette Neuinstallation ist aber bei beiden schon etwas her.
Kleinere Problemchen sind also nicht auszuschließen.
Ansonsten funktioniert das. Ein paar Anpassungen wirst du aber je nach System noch machen müssen.
Grafikkarten-Treiber musst du selber installieren.

Gruß
Marc

Hallo Torsten,

Zitat

Original von Torsten73
Hi Zulu,
mir ist ein Fehler in der Senderliste / Linowsat aufgefallen. Du bzw Linowsat verwendet das falsche und uralte Pro7 Paket vom letzten Jahr.
Siehe: Altes Pro 7 Paket (Sat) in der Linowsat 19,2 unsortiert
...

habe ich jetzt geändert.

Gruß
Marc

Hallo Gerd,

Zitat

Original von Judge
Hi,

gerade bemerkt:

--with-extraincdir=$SOURCEDIR/DVB/linux/include

Diesen Schalter gibt es wohl nicht mehr im aktuelle Snapshot vom Mplayer. Bei mir wird er angemeckert und deshalb wird mplayer nicht gebaut.

Kann das jemand bestätigen?

Gerd

Update:

make && checkinstall --fstrans=no --install=yes --pkgname=mplayer --pkgversion "2:1.0.svn${DATE}-xvdr" --default

bringt: [libvo/vo_mpegpes.o] Fehler 1

wenn ich auf obrigen Eintag beim configure verzichte.

Update 2:

Der Schalter --enable-largefiles ist nicht mehr gültig, da in der neuen Version als Standard > 2 GB enabled ist.

Kompiliert nach weglassen aber trotzdem nicht. Ich suche mal weiter.

Gerd

Alles anzeigen

die Schalter habe ich jetzt entfernt und einen Test dazu eingebaut.

Damit sich mplayer übersetzen lässt musste ich noch video.h ändern:

--- /usr/include/linux/dvb/video.h.orig
+++ /usr/include/linux/dvb/video.h
@@ -28,6 +28,7 @@
 #ifdef __KERNEL__
 #include <linux/compiler.h>
 #else
+#include <linux/compiler.h>
 #include <stdint.h>
 #include <time.h>
 #endif

Die Geschichte mit den Headern und den neuen Treibern schau ich mir aber noch mal an. Hab leider im Moment nicht so viel Zeit...

Gruß
Marc

Hallo Pete,

Zitat

Original von Pete248
Hallo Marc,

habe heute versucht meine S100 mit vdr 1.7.0 von x-vdr-0.8.6 auf x-vdr-0.8.9 upzudaten. War allerdings keine so gute Idee.

Das Kompilieren vom vdr bricht jetzt ab mit

dvbdevice.c:538: error: ‘FE_CAN_2G_MODULATION’ was not declared in this scope

Im Thread zum Extension patch steht darüber schon Einiges und so wie ich es verstanden habe, hast Du das Problem bereits mit dem vdr-1.7.0-ext_h264-s2ng-speedup.diff Patch, der Bestandteil von x-vdr-0.8.9 ist, in den Griff bekommen.

Bei mir tuts aber leider nicht.

Ich vermute es liegt daran, dass ich auf der S100 noch die uralte DVB_API_VERSION 3 von zendeb drauf habe. Das ist aber eigentlich auch egal, da die S100 ja nur als Streaming Client läuft und selbst gar keine DVB Geräte ansprechen muss. Zumindest lief die S100 mit den Treibern unter x-vdr 0.8.6 problemlos auch mit HD Sendern.

Hast Du eine Lösung für das Problem? Oder muss ich jetzt die s2-liplianin Treiber installieren, um den vdr wieder kompilieren zu können?

Auf die Schnelle gehe ich jetzt erst mal wieder zurück zu x-vdr 0.8.6

Pete

Alles anzeigen

um neue Treiber wirst du auf Dauer nicht herum kommen. Wenn du keine DVB-Karte drin hast könnte es reichen, den Treiber auszupacken und DVBDIR im Make.config dementsprechend anzupassen. Ist dann aber Pfusch...

Gruß
Marc

Hi Chris,

Zitat

Original von MChrisZ
Hallo Marc,

seit 0.8.9 wird (jedenfalls bei auswahl des vdr1.6.0 und patchlevel 2)das control-plugin falsch benannt in /usr/lib/vdr/plugins abgelegt. Im namen ist am ende noch ein -2, wobei die anderen plugins mit 1.6.0 enden.

Gruß,
Chris

war das denn schon mal anders?
Die Lösung müsste im Makefile des Plugins zu finden sein: VDRVERSION <> APIVERSION

Gruß
Marc

Moin Torsten,

Zitat

Die Gnome Version läuft wunderbar mit X-VDR. Keine Probleme bei der Installation!

Das freut mich!

Zitat

Ich habe mir die plugins und auch das x-vdr script angesehen, konnte aber nicht die eigentliche installation von LCDd finden. Ob das "enable.drivers=irtrans" überhaupt noch exisitert weiß ich allerdings nicht.

LCDd ist Teil des LCDproc (utilities). Das wird aber schon mit " --enable-drivers=all" erstellt.

Zitat

...
LCD daemon
This is actually a forked version of the lcdProc package, so uninstall lcdproc if you have it...

Wenn es mit dem "echten" LCDproc nicht funktioniert, kannst du WEB und VERSION in der utilitie.sh durch die andere Version ersetzen. Wenn du ausschließlich irtrans nutzen möchtest, kannst du natürlich --enable-drivers=... auch noch anpassen.

Gruß
Marc

Zitat

Original von kls

Diego hat wohl den Zeichensatz von ISO-8859-15 auf UTF-8 geändert.
Evtl. liegt da der Hund begraben.
Ich wüsste jedenfalls nicht, was ich hier ändern sollte...

Klaus

Diego hat sich gemeldet und seinem Mail nach, hat er genau das getan.
Er hat die Übersetzungen (samt meinen Anpassungen für den neuen Ext-Patch) auch nochmal im OSD geprüft, und alle Zeichen werden richtig dargestellt.

Gruß
Marc

PS: Warum die Sonderzeichen jetzt im Code so merkwürdig dargestellt werden, verstehe ich trotzdem nicht.

Im ersten Beitrag gibt es jetzt vdr-1.7.5-ext_reelbox7.diff als Anhang.
Das ist der Patch von da aktueller rmm patch für vanilla und ext70 vdr 1.7.5 erweitert mit Präprozessoranweisung USE_REELPLUGIN.
Oder brauchst du unbedingt reelbox6?

Moin Torsten,

Zitat

Original von Torsten73
Noch mal zum Thema KDE deinstallation:
- dies passiert immer beim Versuch etwas an Xine-Lib aus den Utilitys zu ändern, d.h. sowohl beim Aus als auch Abwählen!
- Xine-Lib gehört standardmäßig schon zum Paket KDE. Wird also Xine-Lib geändert, wird das gesammte Paket entfernt.

Schau mal hier was bei KDE 4.2.2 alles installiert wird, insbesondere was xine betrifft:

Code

sudo apt-get install kdePaketlisten werden gelesen...
Fertig Abhängigkeitsbaum wird aufgebaut Lese Status-Informationen ein... Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht länger benötigt:
ubuntu-sounds Verwenden Sie »apt-get autoremove«, um sie zu entfernen.
Die folgenden zusätzlichen Pakete werden installiert: akonadi-kde .... libxine1 libxine1-bin libxine1-console libxine1-mi**-plugins libxine1-x ...superkaramba sweeper systemsettings
0 aktualisiert, 164 neu installiert, 0 zu entfernen und 85 nicht aktualisiert.
Es müssen noch 16,2kB von 94,8MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 275MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren [J/n]? j

D.h. wenn ich das richtig verstehe, wird vom x-vdr xine-lib installiert obwohl es bereits da ist. Möglicherweise eine andere/inkompatible Version? Wenn nicht, kann man das Problem nicht umgehen, indem man überprüft ob xine-lib bereits vorhanden ist und wenn ja es nicht verändert? Mit Paket Abhängigkeiten kenne ich mich nicht aus, aber ich denke da liegt die Ursache.
Bringt das Dich weiter?

Alles anzeigen

Ich brauche aber die selbst gebaute libxine, sonst kann ich mir gleich den VDR von E-Tobi installieren
Das KDE 4.2.2 Abhängigkeiten zu libxine hat, ist für mich absoluter Nonsens.
Die sauberste Lösung gegen so etwas wäre, echte Debian Pakete für die Utilities zu erstellen und diese Lokal anzubieten. Dann könnten die Pakete mit apt-get installiert werden.

Zitat

kennst Du runvdr extreme? ( [ANNOUNCE] runvdr extreme 0.4)
Damit sollte das Problem für Kubuntu und dem xinitrc sich doch beheben lassen. Vielleicht ist das einfache zu integrieren?

Kennen wäre zu viel gesagt.
Es gibt kein Problem mit "Kubuntu und dem xinitrc" für das "runvdr extreme" nötig wäre.
Ubuntu benutzt keine inittab und startet den Desktop-Manger in jedem Runlevel.
Erstellt man also /etc/inittab, trägt dort den gewünschten Runlevel ein und löscht die Symlinks auf das Start-Skript des Desktop-Managers in /etc/rc2-4, funktioniert das.

Dann kannst du über den Runlevel in der inittab bestimmen ob der Desktop-Manager gestartet werden soll, oder nicht.

xinitrc wird dann über das "startx" in der runvdr ausgelöst.

Aber bekanntlich führen viele Wege nach Rom.

Gruß
Marc

Hallo Karsten,

Zitat

Original von kwacker
Hallo Marc,

falls es die nicht betroffenen Systeme nicht stört.....könnte man den in der nächsten x-vdr-Version fest einbauen?

Hat mich hier heute och nerven gekostet:-)

Tschau, Karsten.

Alles anzeigen

ich probiere bei mir mal, ob er stört.
Eventuell kann man ja am Kernel erkennen, ob der Patch notwendig ist?
Dann könnte ich es so machen, das nur falls nötig...

Gruß
Marc