Posts by Taros666

Es fehlte in videodir.c noch:

#ifdef USE_LIVEBUFFER
const char *BufferDirectory = NULL;
#endif /*USE_LIVEBUFFER*/

compilieren tut es jetzt schon mal

Frank

Quote from carel

Deine livebuffer.o wird nicht erstellt

aber auch mit der Änderung im Makefile klappt es noch nicht ganz:

/usr/bin/g++-4.2 -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -rdynamic audio.o channels.o ci.o config.o cutter.o device.o diseqc.o dvbdevice.o dvbci.o dvbplayer.o dvbspu.o dvbsubtitle.o eit.o eitscan.o epg.o filter.o font.o i18n.o interface.o keys.o lirc.o menu.o menuitems.o nit.o osdbase.o osd.o pat.o player.o plugin.o rcu.o receiver.o recorder.o recording.o remote.o remux.o ringbuffer.o sdt.o sections.o shutdown.o skinclassic.o skins.o skinsttng.o sourceparams.o sources.o spu.o status.o svdrp.o themes.o thread.o timers.o tools.o transfer.o vdr.o videodir.o livebuffer.o tinystr.o tinyxml.o tinyxmlerror.o tinyxmlparser.o submenu.o vdrttxtsubshooks.o iconpatch.o -ljpeg -lpthread -ldl -lcap -lrt -lfreetype -lfontconfig ./libsi/libsi.a -o vdr 
vdr.o: In function `main': 
/home/schertha/vdr-1.7.19/vdr.c:261: undefined reference to `BufferDirectory' 
/home/schertha/vdr-1.7.19/vdr.c:589: undefined reference to `BufferDirectory' 
/home/schertha/vdr-1.7.19/vdr.c:590: undefined reference to `BufferDirectory' 
videodir.o: In function `OpenVideoFile(char const*, int)': 
/home/schertha/vdr-1.7.19/videodir.c:117: undefined reference to `BufferDirectory' 
livebuffer.o: In function `cLiveRecorder::FileName()': 
/home/schertha/vdr-1.7.19/livebuffer.c:300: undefined reference to `BufferDirectory' 
livebuffer.o:/home/schertha/vdr-1.7.19/livebuffer.c:304: more undefined references to `BufferDirectory' follow 
collect2: ld returned 1 exit status 
make: *** [vdr] Fehler 1

Frank

Quote from Copperhead

Übrigens habe ich jetzt auch eine Version mit livebuffer hochgeladen.

Aber leider sind in menu.c mind. 2 Zeilen verrutscht, compiliert nicht.

... auch nach dem manuellen flicken von menu.c klappt es noch nicht...

Das linken geht schief...

letzte Fehlermeldung:

menu.o: In function `cRecordControls::GetLiveIndex(char const*)':
/home/schertha/vdr-1.7.19/menu.c:5474: undefined reference to `cLiveRecorder::FileName()'
menu.o: In function `cRecordControls::SetLiveChannel(cDevice*, cChannel const*)':
/home/schertha/vdr-1.7.19/menu.c:5442: undefined reference to `cLiveRecorder::Prepare()'
/home/schertha/vdr-1.7.19/menu.c:5443: undefined reference to `cLiveRecorder::cLiveRecorder(cChannel const*)'
menu.o: In function `cRecordControl':
/home/schertha/vdr-1.7.19/menu.c:5207: undefined reference to `cBufferRecorder::cBufferRecorder(char const*, cChannel const*, int, cIndex*)'
/home/schertha/vdr-1.7.19/menu.c:5207: undefined reference to `cBufferRecorder::cBufferRecorder(char const*, cChannel const*, int, cIndex*)'
menu.o: In function `cRecordControls::StartLiveBuffer(eKeys)':
/home/schertha/vdr-1.7.19/menu.c:5398: undefined reference to `cLiveRecorder::FileName()'
player.o: In function `cControl::Launch(cControl*)':
/home/schertha/vdr-1.7.19/player.c:77: undefined reference to `cLiveRecorder::FileName()'
vdr.o: In function `main':
/home/schertha/vdr-1.7.19/vdr.c:261: undefined reference to `BufferDirectory'
/home/schertha/vdr-1.7.19/vdr.c:589: undefined reference to `BufferDirectory'
/home/schertha/vdr-1.7.19/vdr.c:590: undefined reference to `BufferDirectory'
/home/schertha/vdr-1.7.19/vdr.c:1407: undefined reference to `cLiveRecorder::Cleanup(bool)'
videodir.o: In function `OpenVideoFile(char const*, int)':
/home/schertha/vdr-1.7.19/videodir.c:117: undefined reference to `BufferDirectory'
collect2: ld returned 1 exit status
make: *** [vdr] Fehler 1

Komm aber frühestens morgen dazu, mal genauer zu schauen.

Quote from Copperhead

Ich habe kein Problem damit, den Extensionpatch weiterzupflegen. Der Livebuffer Patch ist nicht drin, weil helau meinte, er sei instabil. Wenn ihr den Livebuffer-Patch unbedingt haben wollt, mache ich den mit rein. Die History-Datei ist wieder vorhanden. Ich hatte diese ab einer gewissen Version vergessen weiterzupflegen.

Wenn ich schon dabei bin: Fehlt denn noch ein Patch? Irgendeiner den ich zb rausgenommen habe, obwohl ihn noch jemand benötigt? Oder vielleicht ein neuer?

Wenn Du die letzte Version des Livebuffer[1] wieder einfügen könntest wäre ich sehr dankbar und mir persönlich fehlt auch sonst nichts
Die History, um einen Überblick über die Änderungen zu bekommen ist ja auch wieder da...ich glaub ich bin glücklich

Frank

[1] livebuffer patch für vdr 1.7.16 (aus rmm svn)

Hab gerade extp für 1.7.19 entdeckt.

Ich könnt heulen wenn ich das lese und dazu die letzte Frage hier, ob die Patches DVLVIDPREFER, LIEMIEXT, PLUGINMISSING, und VALIDINPUT drin bleiben sollen.

Da kann ich nur den Kopf schütteln...

Copperhead:
Wenn Du keinen Bock mehr hast, dann sag es doch einfach...da ist dir sicher keiner böse, im Gegenteil, ich finde Deine Arbeit bewundernswert und toll. Du musst das nicht machen...ich weiss!

Aber muss man sich hier wirklich alle paar wochen rechtfertigen, weil man einen Patch benutzt?

Ich bin dann mal im neuen Thread... der hier war eh nur bis VDR 1.7.16 gedacht

Frank

Jetzt wollte ich gerade auf 1.7.19 umsteigen und darf feststellen, dass der livebuffer nicht mehr im Ext-Patch ist?

Nicht nur, dass ich das in keinem HISTORY oder Changelog oder so was gelesen habe, ich versteh gerade auch gar nicht warum der weg ist?

Ich dachte es wären sich alle einig, dass patches nur rausfliegen, wenn diese via Plugin, VDR-Corefunktion oder Add-On ermögliocht werden?

Es macht doch gar keinen Sinn, einen patch zu entfernen, den es nirgends anders gibt? Jeder patch kann ja komplett beim compile weggelassebn werden, so dass es auch keinerlei Stabilitätsprobleme gibt?

Was hab ich denn jetzt schon wieder verpasst?

Frank

Gibt es noch irgendwo ein Changelog? Oder ne History?
Wie bekomm ich raus, was in den letzten 3-4 VErsion verändert wurde?

Frank

Quote from gda

Warum den das? Keiner der Patches war gegen den VDR von yaVDR, sondern gegen den Vanilla. Der mit yaVDR gekennzeichnete Patch hat nur einen anderen Funktionsumfang aber trotzdem gegen Vanilla,

Die 2. Zeile des Zitats gehört ja auch noch dazu die hab ich nur nicht zitiert. D.h. der patch war gegen den Ext-Patch und darauf habe ich gewartet...

Frank

Quote from carel

An allen die kein yavdr nutzen, hab ich ein diff erstellt gegen einem vanilla vdr-1.7.17

DANKE! Genau darauf hab ich gewartet

Frank

Quote

Original von carel
Eigentlich sehe ich keine Verbesserungen im letzte LB patch (LB.diff.gz) im Vergleich mit "vdr-1.7.16-livebuffer6.diff" von Joachim.

Ich haBE NICHT NUR "KEINE vERBESSERUNG" (ups..neue Tastatur...CAPS Lock liegt anders ) sondern nur noch segfaults, wenn ich livebuffer versuche zu starten...auch ohne text2skin

Leider hab ich aber keine Zeit genau rauszubekommen, ob das nur an meinem gepatchten VDR liegt oder allgeminer ist ... Der patch davor lief einwandfrei...

EDIT2: Sorry, war doch txt2skin. Ich dachte, man müsste txt2skin auch nutzen. Es reicht aber, das Plugin zu laden. Dann gibt es den segfault wenn man livebuffer nutzt. Erstaml lebe ich ohne txt2skin

Frank

edit: hab das Zitat zerschossen...gefixt!

Quote

Original von Copperhead
...
TODO:

Setup-Patch endgültig reparieren (Wie von det beschrieben)
Livebuffer aktualisieren (neue Version?!)
LNB-Share aktualisieren

Was vergessen?

Nee, das sieht vollständig aus und ich freu mich schoin drauf

Frank

Quote

Original von Copperhead
Jetzt ist wieder alles beim Alten

Danke dafür.

Frank

Hallo,

ich hab immer noch nicht verstanden, warum für SETUP wirklich eine TinyXML-shared-lib kreiert werden soll.
Oder anders: Die Original-Autoren von TinyXML sehen vor, dass man KEINE lib sondern die 5 Dateien verwendet. Hast Du Dir das readme mal durchgelsen?
Hier mal der Auszug:

Quote

<h3>To Use in an Application:</h3>
Add tinyxml.cpp, tinyxml.h, tinyxmlerror.cpp, tinyxmlparser.cpp, tinystr.cpp, and tinystr.h to your project or make file. That's it! It should compile on any reasonably compliant C++ system. You do not need to enable exceptions or RTTI for TinyXML.

D.h. die Art und Weise wie der SETUP-patch die TinyXML integriert hat war genau das, was gemacht werden sollte. Und das hat sehr lange wunderbar funktioniert

TinyXML ist erst mal KEINE shared-lib. Die existiert in der Form aktuell auch nicht in Ubuntu oder Debian, sondern nur ne alte Version.

Ich habe leider erhebliche Probleme mit Deiner Vorgehensweise und mind. 2 weitere User hier auch. Also nicht die Tasache, wie Du es gemacht hast, sondern das Ergebnis. Sollte kein Angriff sein...

Den patch ein paar byte kleiner zu machen kann doch nicht wirklich das Ziel gewsen sein?

Ich bitte Dich jedenfalls, Deine Änderungen noch mal zu üerdenken. Bitte! Ich bekomme derzeit nix compiliert...

Ich versuche jedenfalls jetzt zumindest für mich mit der Anleitung von wbreu die ursprünglich intendierte Vorgehensweise wieder herzustellen...

Und wegen Deiner Frage, warum jemand SETUP nutzt und nicht z.B. MenuORG: Usability! Man kann mit SETUP direkt über Menü neue Einträge anlegen, verschieben, löschen. Bei MenuORG muss ich via Texteditor ein XML-File bearbeiten. Wie soll man das einem User denn beibringen? MenuOrg wurde "nur" gemacht, um ABI-neutral Menüs zu ermöglichen. Das ist ja auch nett, aber Setup geht halt ein ganzes Stück weiter...

Frank

Bitte bitte, kann man denn nicht einfach wieder tinyxml einfach mitliefern?
Die derzeitige Lösung ist maximal kompliziert durch die ausgelagerte lib und nicht gerade Nutzerfreundlich

Was zu Hölle machen ein paar kbyte mehr beim Ext-patch in zeiten von DSL und LTE

Frank

man 5 vdr !!!

COMMANDS
       The file commands.conf contains the definitions of commands that can be executed from the vdr main menu's "Commands" option.  Each line contains one command  definition
       in the following format:


       title : command


       where  title  is  the string that will be displayed in the "Commands" menu, and command is the actual command string that will be executed when this option is selected.
       The delimiting ':' may be surrounded by any number of white space characters. If title ends with the character '?', there will be a confirmation prompt before  actually
       executing the command. This can be used for commands that might have serious results (like deleting files etc) to make sure they are not executed inadvertently.


       Everything following (and including) a '#' character is considered to be comment.


       You can have nested layers of command menus by surrounding a sequence of commands with '{'...'}' and giving it a title, as in


       My Commands {
         First list {
           Do something: some command
           Do something else: another command
           }
         Second list {
           Even more: yet another command
           So much more: and yet another one
           }
         }


       Command lists can be nested to any depth.


       By  default the menu entries in the "Commands" menu will be numbered '1'...'9' to make them selectable by pressing the corresponding number key. If you want to use your
       own numbering scheme (maybe to skip certain numbers), just precede the titles with the numbers of your choice. vdr will suppress its automatic numbering  if  the  first
       entry in commands.conf starts with a digit in the range '1'...'9', followed by a blank.


       In  order  to avoid error messages to the console, every command should have stderr redirected to stdout. Everything the command prints to stdout will be displayed in a
       result window, with title as its title.


       Examples:


       Check for new mail?: /usr/local/bin/checkmail 2>&1
       CPU status: /usr/local/bin/cpustatus 2>&1
       Disk space: df -h | grep '/video' | awk '{ print 100 - $5 "% free"; }'
       Calendar: date;echo;cal


       Note that the commands 'checkmail' and 'cpustatus' are only examples!  Don't send emails to the author asking where to find these ;-)
       The '?' at the end of the "Check for new mail?" entry will prompt the user whether this command shall really be executed.

Frank

Das steckt doch inzwischen im core-VDR...

Oder ist das was anderes als Untermenüs in den Commands?
Das macht man mit "{}" beim vdr...

Frank

Gestern Abend kam bei mir Liveticker. Jetzt schon das 3. oder 4. mal, aber ich seh quasi zwischen 15 und 17 Uhr Sa kein fern.
Ich rede also nur von Fr und So Spielen

Frank

Gestern ist wieder der Ticker losgelaufen... ich hatte SportNG schon fast vergessen.

Danke fürs Weiterführen!

Frank

Hallo,

also irgendwie klappt es nicht oder ich raff es einfach nicht:

Ich dachte, ich könnte OHNE composite-manager und OHNE Fenstermanager via OPENGL ein OSD bekommen.

Ist das falsch?
Mein Setup:
vdr 1.7.15
xineliboutput cvs-Version von heute (13.6.2010)
Alles neu kompiliert und vorher schön "make clean" und danach "sudo make install" im xinelibout-Verzeichnis

Was ich probiert habe:
Nacktes X, composite in xorg disabled, start mit --opengl-always und --hud gibt mir nur die Fehlermeldung:

Jun 13 08:00:42 vdr vdr: [6419] [vdr-sxfe]  opening HUD OSD window...
Jun 13 08:00:42 vdr vdr: [6419] [vdr-sxfe]  find_argb_visual: XGetVisualInfo failed (no xvi)
Jun 13 08:00:42 vdr vdr: [6419] [vdr-sxfe]     (ERROR (xine_sxfe_frontend.c,597): Die Ressource ist zur Zeit nicht verfügbar)
Jun 13 08:00:42 vdr vdr: [6419] [vdr-sxfe]  find_argb_visual() failed. HUD OSD disabled.

Oder dann mal mit composite in xorg enabled: kein OSD!

Kann mir mal jemand genau sagen, wie der Aufruf von xineliboutput aussehen muss?
Oder ob ich jetzt in der xorg.conf composite an oder ausschalten muss?

Muss --hud zusätzlich zu --opengl-hud/--opengl-always angegeben werden? Oder Optional?

Frank, etwas am verzweifeln...

Quote

Original von Copperhead
Überflüssige Übersetzungen entfernt und damit auch das fi_FI.po Problem gelöst.

?? Du siehst alles andere als deutsch als überflüssig an?

Ja, es ist Deine Arbeit und ja, Du bestimst was rein und raus soll...aber ich glaube Du schiesst da langsam etwas über das Ziel hinaus

Trotzdem: Danke fürs Pflegen und Bereitstellen! Sehr schnelle und gute Arbeit!

Frank