[ANNOUNCE] Live - das Live Interactive VDR Environment

Hi ,

Danke . Live Fernsehen geht FullScreen nicht über den Button unten aber über Doppelt Clik.
Super jetzt fehlt nur noch eine Menu mit Fernbediennung.

Und die Aufnahmen gehen noch nicht aber Sonst Super ....

Frohe Weihnachten

Patrice

Ich hatte weiter vorne im Thread schon mal berichtet - ich hab es auf dem alten nicht zum rennen gebracht. Inzwischen hab ich - aus anderen Gründen - meinen vdr einer Runderneuerung unterzogen :

Es ist ein Suse 10.3 , aktueller Kernel 2.6.23.12, aktuelle Treiber etc - hab (fast) wieder alles am rennen - und da wollte ich nochmal live versuchen.

Was hab ich bisher gemacht :

1. boost, boost-devel als rpms von suse Installiert

2. cxxtools cxxtools-devel als rpms installiert (nicht von suse - hab ich da nicht gefunden) -> Version 1.4.6

Einschub : cxxtools aus dem Source hat sich beharrlich geweigert erfolgreich übersetzt zu werden - immer der pthread - Fehler - ich kann allerdings ausschließen, daß ein cxxtools 1.4.3 drauf ist.

3. VOR .configure für tntnet hab ich nen libtool-bug korrigiert, der mit cxxtools-rpms "dabei" ist

4. tntnet compiliert und installiert (Version 1.6.1)

5. live übersetzt und installiert (aktueller cvs) - der 0.1.0 kackt schon beim bauen ab

6. vdr restart :

Dec 29 18:21:25 vdr vdr: [7346] ERROR: /usr/lib/vdr/libvdr-live.so.1.5.12: undefined symbol: _ZTIN3tnt13EcppComponentE

7. EDIT : sollte hier nicht auch libtnt auftauchen ?

vdr:/usr/lib/vdr # ldd libvdr-live.so.1.5.12
        linux-gate.so.1 =>  (0xffffe000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7de0000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7dc9000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7dc5000)
        libcap.so.1 => /lib/libcap.so.1 (0xb7dc1000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7d52000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7d26000)
        libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0xb7c46000)
        libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb7b00000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7a12000)
        libm.so.6 => /lib/libm.so.6 (0xb79ed000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb79e1000)
        libc.so.6 => /lib/libc.so.6 (0xb78ae000)
        /lib/ld-linux.so.2 (0x80000000)
        libz.so.1 => /lib/libz.so.1 (0xb789a000)
        libexpat.so.1 => /lib/libexpat.so.1 (0xb7879000)

rabäh

Stell ich mich so doof an, oder ist es so hakelig ? Bisher hab ich noch jedes (fast) jedes Plugin zum fliegen bekommen - und keins hat mich soviel Nerven gekostet...

Hallo

Also ganz allgemein haben es wohl schon einige Leute erfolgreich im Einsatz. An sich ist das LIVE-Plugin nicht komplizierter in Betrieb zu nehmen als andere
Ok, es gibt die Abhängigkeit zu Tntnet und Tntnet selber ist von der cxxtools Library abhängig. Aber beide stammen vom selben Entwickler. Boost wird in der CVS Version von LIVE nur bzgl. den Features benutzt, die auch im TR1 des C++-Standards aufgenommen sind und von GCC > 4.1 unterstützt werden (d.h. LIVE hätte auch ohne Boost-Dev übersetzbar sein sollen).

Nun zu Deinem speziellen Problem:

echo _ZTIN3tnt13EcppComponentE | c++filt
typeinfo for tnt::EcppComponent

Das sieht mir danach aus, als ob Du tntnet mit Flags übersetzt hast, die keine Typeinfos erzeugen. Wie Du am Namespace siehst, ist das etwas was bei tntnet fehlt.

Obwohl eine entsprechende Warnung ausgegeben wird, ist LIVE aus dem CVS aktuell auch mit älternen Versionen von tntnet noch betreibbar.

Gruß
Dieter (tadi)

Hi,

stimmt, bei mir sieht das so aus:

vdr:~/src/VDR/PLUGINS/lib# ldd libvdr-live.so.1.5.12
        linux-gate.so.1 =>  (0xffffe000)
        libtntnet.so.7 => /usr/lib/libtntnet.so.7 (0xb7cf4000)
        libcxxtools.so.4 => /usr/lib/libcxxtools.so.4 (0xb7ca9000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7bbd000)
        libm.so.6 => /lib/libm.so.6 (0xb7b97000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7b8c000)
        libc.so.6 => /lib/libc.so.6 (0xb7a3f000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7a2a000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7a13000)
        libgnutls.so.13 => /usr/lib/libgnutls.so.13 (0xb799b000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7997000)
        libnsl.so.1 => /lib/libnsl.so.1 (0xb797f000)
        /lib/ld-linux.so.2 (0x80000000)
        libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7970000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb796c000)
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb7903000)

Was kommt bei Dir denn mit

vdr:~/src/VDR/PLUGINS/lib# tntnet-config --libs
-L/usr/lib -ltntnet -lcxxtools
vdr:~/src/VDR/PLUGINS/lib# tntnet-config --cxxflags
-I/usr/include

Tschüss,

winni

winni - bei mir kommst das :

vdr:~ # tntnet-config --libs
-L/usr/local/lib -ltntnet -lcxxtools
vdr:~ # tntnet-config --cxxflags
-I/usr/local/include
vdr:~ #

ja - unter /usr/local/lib liegen die libs von tntnet - es liegt dort auch ein verzeichnis von tntnet mit libs - mein LD_LIBRARY_PATH sieht so aus :

vdr:~ # grep LD_LIBRARY_PATH /usr/local/bin/runvdr
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib:/usr/local/lib/tntnet

Zitat

Also ganz allgemein haben es wohl schon einige Leute erfolgreich im Einsatz. An sich ist das LIVE-Plugin nicht komplizierter in Betrieb zu nehmen als andere

Wer fragt - bekommt u.U. unangenehme Antworten ...

Ich bin mir ziemlich sicher, daß ich mir mein tntnet mit ./configure --prefix=/usr/local gebaut habe - mach ich eigentlich nie anders meine configures - aber ich prüfe grad nochmal/bzw. mach es nochmal

EDIT :

das eigentliche Problem ist das Fehlen der cxxtools-lib - trotz der installierten rpm's - dann taugen die wohl auch nicht ...

Ich bin jetzt also wieder soweit wie schon einmal - ich scheitere am bauen von cxxtools von Hand mit dem Fehler :

if /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I. -I../include/cxxtools -I../include    -g -O2 -MT libcxxtools_la-thread.lo -MD -MP -MF ".deps/libcxxtools_la-thread.Tpo" -c -o libcxxtools_la-thread.lo `test -f 'thread.cpp' || echo './'`thread.cpp; \
        then mv -f ".deps/libcxxtools_la-thread.Tpo" ".deps/libcxxtools_la-thread.Plo"; else rm -f ".deps/libcxxtools_la-thread.Tpo"; exit 1; fi
 g++ -DHAVE_CONFIG_H -I. -I. -I. -I../include/cxxtools -I../include -g -O2 -MT libcxxtools_la-thread.lo -MD -MP -MF .deps/libcxxtools_la-thread.Tpo -c thread.cpp  -fPIC -DPIC -o .libs/libcxxtools_la-thread.o
thread.cpp: In member function âvirtual void cxxtools::AttachedThread::create()â:
thread.cpp:71: error: invalid conversion from âintâ to âint* (*)()â
thread.cpp:71: error:   initializing argument 1 of âcxxtools::ThreadException::ThreadException(int* (*)(), const char*)â
thread.cpp: In member function âvoid cxxtools::AttachedThread::join()â:

Noch'n EDIT :

das ist eine der Stellen : (src/thread.cpp Zeile 71)

void AttachedThread::create()
{
  int ret = pthread_create(&pthreadId, &pthread_attr, start, (void*)this);
  if (ret != 0)
    throw ThreadException(ret, "pthread_create");
  joined = false;
}

unter cxxtools/include/cxxtools/thread.h liegt die Deklaration von ThreadException :

class ThreadException : public SysError
{
  public:
    ThreadException(int errno, const char* method)
      : SysError(errno, method)
      { }
};

bis dahin passt es ja noch - würde ich sagen

SysError wiederrum findet sich in cxxtools/include/cxxtools/syserror.h :

...
#include <cxxtools/api.h>
#include <stdexcept>


namespace cxxtools
{
  class SysError : public std::runtime_error
  {
      int m_errno;


    public:
      explicit SysError(const char* fn);
      SysError(int err, const char* fn);


      int getErrno() const   { return m_errno; }
  };
}
...

Nach meinem bescheidenen c++ - Verständnis ist auch bis hier noch alles i.O, weiter geht's mit runtime_error oder ? - Und der findet sich in stdexcept - und davon hab ich im System mehrere - die unter "Boost" ziehen nicht, da ich boost nicht gebaut habe - liegen da nur so rum - boost kam aus den RPM's von Suse :

vdr:/ # find . -name stdexcept -print
./usr/include/c++/4.2.1/stdexcept
./usr/local/src/boost/boost/tr1/tr1/stdexcept
./usr/local/src/boost-RC_1_34_0-07-06-03-0909/boost/tr1/tr1/stdexcept
./usr/local/src/boost_1_34_1/boost/tr1/tr1/stdexcept

und das stdexcept aus c++ sieht so aus - an der aus meiner sicht interessanten Stelle :

/** Runtime errors represent problems outside the scope of a program;
   *  they cannot be easily predicted and can generally only be caught as
   *  the program executes.
   *  @brief One of two subclasses of exception.
   */
  class runtime_error : public exception
  {
    string _M_msg;


  public:
    /** Takes a character string describing the error.  */
    explicit
    runtime_error(const string&  __arg);


    virtual
    ~runtime_error() throw();


    /** Returns a C-style character string describing the general cause of
     *  the current error (the same string passed to the ctor).  */
    virtual const char*
    what() const throw();
  };

imho ginge es jetzt mit exception weiter - oder ?

So - jetzt lüppt es - der Fehler saß zwischen Tastatur und Rückenlehne :

cxxtools geht bei mir echt nicht - bis mir jemand mal das Thema mit dem thread.cpp schlüssig erklärt - das hake ich ab.

Ich hab nochmal die rpms von cxxtools installiert - die libs und header sind alle da - unter /usr/include, bzw. /usr/lib

wenn man die RPM's installiert muß man - zumindest wenn man Suse 10.3 hat folgendes korrigieren BEVOR man tntnet baut :

in /usr/lib/libcxxtools.la :

aus

dependency_libs=' -lpthread -ldl -lnsl /usr/lib/libstdc++.la'

wird :

dependency_libs=' -lpthread -ldl -lnsl'

- sonst kommt es beim bauen von tntnet zu einem :

(cd .libs && rm -f libtntnet.so.7 && ln -s libtntnet.so.7.0.1 libtntnet.so.7)
(cd .libs && rm -f libtntnet.so && ln -s libtntnet.so.7.0.1 libtntnet.so)
creating libtntnet.la
/usr/bin/sed: can't read /usr/lib/libstdc++.la: No such file or directory
libtool: link: `/usr/lib/libstdc++.la' is not a valid libtool archive
make[2]: *** [libtntnet.la] Error 1
make[2]: Leaving directory `/usr/local/src/tntnet-1.6.1/framework/common'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/local/src/tntnet-1.6.1/framework/common'
make: *** [all-recursive] Error 1

und jetzt kann man live bauen - und hier kommt dann auch MEIN FEHLER :

Im Makefile von live wird auch VDR/Make.config included - und der im gleichen Makefile mühsam zusammengesetzte Optionsstring für den g++ wurde durch MEINEN eintrag im Make.config teilweise überbügelt.

Konkret : es wurde niemals mit -lcxxtools -ltntnet gebaut - AUTSCH.

Hi,

schön, dass es nun funktioniert und Danke für die ausführliche Erläuterung. Hilft vielleicht auch mal jemand anderem weiter.

Tschüss,

winni

Dazu ein kleiner Hinweis:
Ich habe auf die RPM`s verzichtet und für Live die sourcen direkt über die Projekt-Homepage gezogen ...Damit gab es keine Probleme.

Zitat

Originally posted by magicamun
Im Makefile von live wird auch VDR/Make.config included - und der im gleichen Makefile mühsam zusammengesetzte Optionsstring für den g++ wurde durch MEINEN eintrag im Make.config teilweise überbügelt.

Als Tipp: Bei mir sieht das am Ende der Make.config so aus:

ifeq ($(PLUGIN),live)
  CXXFLAGS = ....
endif

Gruß,

Udo

Also ich hab diesen Thread seit Ewigkeiten abonniert um die Neigkeiten zu verfolgen. Ich hatte - wie andere auch - mehrfach von Problemen mit der CVS Version auf meiner SuSE 10.0 berichtet. In Fakt war nichts zum Funktionieren zu bewegen außer der 0.1.0 Initialversion.

Die letzten Posts haben mich noch einmal ermutigt einen neuen Versuch zu wagen.

Was hab ich gemacht:
die alten libs von tntnet und den cxxtools mit 'make unistall' rausgehauen, danach ein ldconfig.

Dann die libs samt den devel Paketen von Packman installiert:
cxxtools4-1.4.6-0.pm.2.i586.rpm
cxxtools-devel-1.4.6-0.pm.2.i586.rpm
tntnet-1.6.1-0.pm.2.i586.rpm
tntnet-devel-1.6.1-0.pm.2.i586.rpm

CVS gezogen, make plugins - fertig
Geht!

Die Pakete gibts übrigens auch für SuSE 10.1, 10.2 und 10.3

Grüße Christian

komischer fehler mit der cvs version

root@dvb:/usr/local/src/vdr-1.5.2/PLUGINS/src/live.cvs2# make
/bin/sh: arith: syntax error: "161<100?161*100:(161<1000?161*10:161)"
/bin/sh: arith: syntax error: "161<100?161*100:(161<1000?161*10:161)"
/bin/sh: arith: syntax error: "161<100?161*100:(161<1000?161*10:161)"
/bin/sh: arith: syntax error: "161<100?161*100:(161<1000?161*10:161)"
/bin/sh: arith: syntax error: "161<100?161*100:(161<1000?161*10:161)"
/bin/sh: arith: syntax error: "161<100?161*100:(161<1000?161*10:161)"
/bin/sh: arith: syntax error: "161<100?161*100:(161<1000?161*10:161)"
/bin/sh: arith: syntax error: "161<100?161*100:(161<1000?161*10:161)"

das kommt bei mir am anfang des kompelieren.
ich konnte es schon etwas eingrenzen es liegt am Makefile an dieser zeile

TNTVERS7   = $(shell ver=`tntnet-config --version | sed -e's/\.//g'`; ver=$$(($$ver<100?$$ver*100:($$ver<1000?$$ver*10:$$ver))); if [ $$ver -ge "1606" ]; then echo "yes"; fi)

die geht nicht richtig durch.
mein quickhack war jetzt

TNTVERS7   = $(shell echo "yes")

sonsten hat er es nicht richtig durchkompeliert.

ich hoffe das kann sich mal einer anschauen der sich auskennt.

mfg
ernie

Hallo ernie

Danke für den Hinweis, dass im LIVE Makefile ein Bash-Feature verwendet wird, ohne die SHELL auf bash zu setzen.
Das aktuelle CVS setzt im Makefile SHELL = /bin/bash.
Damit ist eine installierte Bash nun Voraussetzung für LIVE übersetzen.

Grüße
Dieter (tadi)

Hallo

zusammen mit Keef wurde ein Weg gefunden, der ohne 'bash arithmetic expressions' auskommt.
Damit ist die bash-Abhängigkeit für LIVE wieder verschwunden.

Grüße
Dieter (tadi)

hi,

erstmal toll, dass das live plugin so klasse funktioniert. ich hab dazu mal eine frage. wenn ich streaming verwende passiert folgendes: ich schaue am tv ein programm über cam und wenn ich dann auf dem browser den live stream eines anderen cam programms gucken will schaltet mir das live plugin den transponder für den hauptfenseher weg.

ich weiss, weshalb das so ist, etc, aber kann man das eigentlich unterbinden? ich will, dass streaming clients generell sozusagen dem hauptsystem untergeordnet sind und das hauptsystem immer vorrang hat (und ggf. einem streaming client auch den stream entziehen kann)

und noch eine frage: kann ein vdr mit 4 sat karten eigentlich alle clients uneingeschränkt bedienen, oder gibt es da auch transpondersperrungen? mal abgesehen von cam streitigkeiten...

gruß fen.

sind eigentlich alles streamdev fragen.
haben mal nix mit live zu tun.

http://www.vdr-wiki.de/wiki/index.php/Streamdev-plugin

ja - hast du recht. danke für den linke. antworten auf meine fragen konnte ichaber leider nicht finden... werde mal weitersuchen zu dem thema.

gruß fen

Hallo
mit dem neuen VDR-1.5.13 will das Live Plugin bei mir nicht "deutsch" werden.
Hat das noch jemand ??
gruss
speed

Habe vorhin gerade auf 1.5.13 geupdatet und es ist Deutsch bei mir.
Ich nutze die aktuelle Repositoryversion.

... da stimme mal was mit den .po files nicht, ist jetzt aber wohl behoben.

Allerdings schlage ich mich mit einem Problem rum, daß ein thread des live-plugins beim Abschalten nicht sauber beendet wird und nach 5sec gekillt wird. Leider ließ sich das bisher per gdb nicht weiter einkreisen, da der thread ja zwangsbeendet wird, halt mit exit code 01. Die unangenehme Nebenwirkung ist jedoch, daß der VDR hin und wieder auch mal abschmiert wenn man umschaltet. Ohne live-plugin läuft er rock solid.

Ich versuche nochmal Infos zu sammeln, soweit erstmal ein heads-up...

Gruß, ollo

Hi,

also ich habe hier allgemein Probleme mit den Language-Files der neusten CVS-Version:

msgfmt -c -o po/ca_ES.mo po/ca_ES.po
msgfmt: po/ca_ES.po: headerfield `Language-Team' missing in header
msgfmt: found 1 fatal error

Ich habe mir jetzt damit beholfen, dass ich alle *.po-Files durchgegangen bin und per Hand

"Language-Team: <vdr@linuxtv.org>\n"

ergänzt habe.

ciao,
Chris