Problem mit Streamdev für XBMC

henfri · 20. März 2009

Hallo,

ich versuche den Patch für Streamdev für die Verwendung mit xbmc zu verwenden.
(siehe: XBMC (xbox media center) als front-end für VDR)

Es gibt den Patch hier:
http://www.xbmc.org/trac/ticket/5595 bzw. direkt hier: http://www.xbmc.org/trac/attac…dr-1.7.4_xbmc-v4.patch.gz

Ich installiere den Patch so:

Code

cvs -d:pserver:anoncvs@vdr-developer.org:/var/cvsroot login
cvs -d:pserver:anoncvs@vdr-developer.org:/var/cvsroot co -D 2/18/09 streamdev
wget http://www.xbmc.org/trac/raw-attachment/ticket/5595/streamdev-cvs180209-vdr-1.7.4_xbmc-v4.patch.gz
gunzip streamdev-cvs180209-vdr-1.7.4_xbmc-v4.patch.gz
patch -p0 < streamdev-cvs180209-vdr-1.7.4_xbmc-v4.patch

Vorher habe ich auch den VDR-Patch angewandt und neu kompiliert. Allerdings verwende ich VDR 1.6, was aber -wie ich gelesen hab- funktionieren sollte.

Das Ergebnis:

Code

./server/connectionVTP.h: In constructor 'cConnectionVTP::cConnectionVTP()':
./server/connectionVTP.h:36: warning: 'cConnectionVTP::m_LSTTHandler' will be initialized after
./server/connectionVTP.h:30: warning:   'RecPlayer* cConnectionVTP::m_RecPlayer'
server/connectionVTP.c:555: warning:   when initialized here
server/connectionVTP.c: In member function 'bool cConnectionVTP::CmdREAD(char*)':
server/connectionVTP.c:854: warning: format '%u' expects type 'unsigned int', but argument 4 has type 'long unsigned int'
server/connectionVTP.c: In member function 'bool cConnectionVTP::CmdPLAY(char*)':
server/connectionVTP.c:911: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'uint32_t'
server/connectionVTP.c:902: warning: unused variable 'recordings'
server/connectionVTP.c: In member function 'bool cConnectionVTP::CmdLSTR(char*)':
server/connectionVTP.c:1278: warning: format '%ld' expects type 'long int', but argument 4 has type 'tEventID'
server/connectionVTP.c:1278: warning: format '%ld' expects type 'long int', but argument 6 has type 'int'
server/connectionVTP.c:1278: warning: too many arguments for format
server/connectionVTP.c: In member function 'bool cConnectionVTP::CmdRENR(char*)':
server/connectionVTP.c:1365: error: no matching function for call to 'cRecording::Rename(char*&)'
/usr/local/src/VDR/include/vdr/recording.h:166: note: candidates are: bool cRecording::Rename(const char*, int*, int*)
server/connectionVTP.c:1361: warning: unused variable 'priority'
server/connectionVTP.c:1362: warning: unused variable 'lifetime'
server/connectionVTP.c: In member function 'bool cConnectionVTP::CmdFRAM(const char*)':
server/connectionVTP.c:1622: warning: unused variable 'recording'
make: *** [server/connectionVTP.o] Error 1

Alles anzeigen

Und nu??

Gruß,
Hendrik

PanamaJack · 21. März 2009

Hi,

für den vdr-1.6 hast du die falsche Version vom streamdev-patch erwischt. Nimm mal http://www.xbmc.org/trac/attac…-cvs180209_xbmc-v4.patch.

henfri · 21. März 2009

Funktioniert.
Danke!

henfri · 21. März 2009

Naja... das kompilieren funktioniert.

Wenn ich jetzt xbmc starte, hängt es beim Start Bildschirm.

Beende ich den VDR und starte erst XBMC, so klappt das. Wenn ich aber dann den VDR starte und in XBMC auf 'TV' gehe, hängt xbmc.

Im Syslog steht dann:
Mar 21 12:30:33 [vdr] [13297] ERROR: streamdev: output buffer overflow (VTP) for 127.0.0.1:44365

Und nu?

Gruß,
Hendrik

hepi · 23. März 2009

Zitat

Original von henfri

Wenn ich jetzt xbmc starte, hängt es beim Start Bildschirm.

Beende ich den VDR und starte erst XBMC, so klappt das. Wenn ich aber dann den VDR starte und in XBMC auf 'TV' gehe, hängt xbmc.

Im Syslog steht dann:
Mar 21 12:30:33 [vdr] [13297] ERROR: streamdev: output buffer overflow (VTP) for 127.0.0.1:44365

Alles anzeigen

Hallo henfri,

was passiert denn, wenn Du im Web-Browser 127.0.0.1:3000 eingibst und versuchst, dort Kanäle via streamdev anzuschauen?

Viele Grüße
hepi

hepi · 23. März 2009

Zitat

Original von henfri
Vorher habe ich auch den VDR-Patch angewandt und neu kompiliert. Allerdings verwende ich VDR 1.6, was aber -wie ich gelesen hab- funktionieren sollte.

Hallo,

welchen VDR-Patch hast Du genau angewendet? Welches VDR-Source-Paket hast Du benutzt?

Gruß
hepi

Papablues · 25. März 2009

Bei mir geht das auch nicht,

habe den 1.7 er patch in den 1.6 er VDR gequetscht.
und das stremdev dagegen angepasst. Musste einige calls in den vdr anpassen aber schlussendlich hat es
kompiliert. leider raucht mir der XBMC ab wenn ich einen Kanal auswaehle. (EPG scheint zu gehen, wenn auch recht zaeh)

device des vdr ist ein anderer 1.6 er VDR via streamdev.
XBMC laeuft auf meinem MacBookPro ( hat sich am Anfang gegen das compilieren gewehrt aber ich war harnaeckig )

evtl. hat ja jemand einen Tipp

Gruß

Fabian

hepi · 25. März 2009

Hallo,

ich habe mir erfolgreich einen XBMC-fähigen VDR 1.6 + streamdev-Plugin gebaut (auf Basis von e-tobi-Paketen) und es läuft mit XBMC+VDPAU. (Natürlich läuft es nicht perfekt, aber ich kann Kanäle umschalten und auch HD-Kanäle gucken. Mein Vorgehen habe ich hier beschrieben. Vielleicht hilft Euch das weiter:

Via DVB-S-Hardware HD-Kanäle empfangen, die ohne DVB-S2 auskommen

Viele Grüße
hepi

hepi · 25. März 2009

Hi,

Zitat

Original von Papablues
leider raucht mir der XBMC ab wenn ich einen Kanal auswaehle. (EPG scheint zu gehen, wenn auch recht zaeh)

wenn XBMC abraucht, kann es ja theoretisch allein an XBMC liegen. Von daher prüfe doch mal, ob Dein streamdev-Server-Plugin ohne XBMC funktioniert. Will heißen: Im Browserfenster mal localhost:3000 eingeben und versuchen, die Kanäle über HTTP zu streamen (z. B. auch mit VLC).

Viele Grüße
hepi

henfri · 25. März 2009

Hallo,

das streamen über VLC klappt.
Es muss also an den Patches für Streamdev oder an XBMC selbst liegen.

Noch Ideen zum eingrenzen?

Gruß,
Hendrik

hepi · 26. März 2009

Zitat

Original von henfri
Wenn ich jetzt xbmc starte, hängt es beim Start Bildschirm.

Sowas hatte ich vorhin auch. Bei mir hat komischerweise geholfen, dem VDR ein leeres VDR-Aufnahme-Verzeichnis zu spendieren (/var/lib/video.00). freezy sagt aber, das Hängen würde eher mit EPG-Daten-Übertragung zusammenhängen.

Gruß
hepi

MChrisZ · 6. April 2009

Mit LEEREM hat das bei mir jetzt auch geklappt.

Danke für den Tipp. Was hab ich mir einen abgesucht

EDIT: Wie bekommt man das in den Griff - kann man die aufnahmen irgendwie "softer" einbinden?

maro · 16. Mai 2009

Das Problem hatte ich auch. Da scheint es einen Buffer Overflow im streamdev-server zu geben.
Log-Eintrag sah so aus:

May 16 19:40:13 video vdr: [17174] ERROR: streamdev: output buffer overflow (VTP) for 127.0.0.1:50943
May 16 19:40:13 video last message repeated 330 times

Nach Wireshark kommt das nach dem Befehl "STAT records" - ok ich hab auch genug Aufnahmen

Ich hab das ganze einfach auskommentiert, da ichs eh nicht brauche - damit ist zumindest für mich Ruhe - für mehr reichen meine Programmierkenntnisse leider nicht...

machtnix · 17. Mai 2009

Zitat

Original von maro

Nach Wireshark kommt das nach dem Befehl "STAT records" - ok ich hab auch genug Aufnahmen

Ich hab das ganze einfach auskommentiert, da ichs eh nicht brauche - damit ist zumindest für mich Ruhe - für mehr reichen meine Programmierkenntnisse leider nicht...

Hi maron,
was und wo genau hast du auskommentiert ?

Thank's

machtnix

maro · 17. Mai 2009

in server/connectionVTP.c hab ich ab Zeile 1130 die Abfrage auskommentiert. Jetzt geht streamdev immer davon aus, das keine Aufnahmen vorhanden sind.
So sieht das aus:

Code

else if (strcasecmp(Option, "RECORDS") == 0) {
/* bool recordings = Recordings.Load();
Recordings.Sort();
if (recordings) {
cRecording *recording = Recordings.Last();
Reply(250, "%d", recording->Index() + 1);
}
else */ {
Reply(250, "0");
}
}

Alles anzeigen

Das ist natürlich ein übler Hack, aber fürs erste kann ich damit leben.

Problem mit Streamdev für XBMC

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema