Wenn schon perl, wieso nicht einen Perl server auf der Box laufen lassen. Perl rockt zwar ganz schön den Speicher der Dream, aber machbar wäre es. Kannst denn Service ja fast auf jeden beliebigen Port zur Verfügung stellen.

Module für Webserver und Perl gibt's bei CPAN. Fehlt dir nur der entsprechende Compiler bzw. make und tools auf der Box, denn viele Module basieren auf C-Sourcen und müssen erst für die Box übersetzt werden.
Dafür gibt's aber die xdevels, da ist ein compiler, binutils, make und was man noch so braucht bei, sowie natürlich auch perl unnd zwar als komplett funktionstüchtiger Interpreter. Nicht die halbe Sache mit ein paar Modulen.

cheers

Zitat

mplayer scheint nur besser zu funktionieren... weil er ein anderes handling macht, wenn die bandbreite nicht reicht. er gibt dem ton vorrang und deswegen faellts nicht so auf, wenn ein paar frames fehlen oder das bild fuer sekunden steht und man nicht so genau hinguckt. irgendwann macht dann auch der ton kapriolen.

Ja das ist schon Klasse, das mplayer bei Fehlern dropped. Die Wiedergabequalität bezog sich aber darauf, das mplayer genau das ebend bei mir nicht macht, vorrausgesetzt man setzt den cache. Dann gibt es überhaupt keine Fehler, bei der Wiedergabe im Gegensatz zum vlc. Wie gesagt es bezieht sich auf meine persönlichen Dauertests.

Nebenbei gefällt mir an vlc nicht, das es die app nur mit einer gui gibt, bzw. die gui immer mitgestartet wird. Außerdem wird die Übergabe der Paramater (mit der vlc eigenen syntax) auf der Konsole doch schnell sehr unübersichtlich.
Nunja, ich arbeite lieber mit der Konsole als mit der Gui.

cheers

Zitat

Also verstehe ich deine Antwort mal so, dass mehrere Instanzen von streamts nicht möglcih sind ohne dass ich selber zu block und bleistift greife und im code ein wenig dengel?

Bezogen auf die 7000er wohl jain. Im streamts Code muß man nicht zwangsläufig rumschnippseln. Ich dachte da eher an was eigenem basteln.

Zitat

Und nebenbei: VLC ist Opensource und daher nicht kostenpflichtig.

Ja das ist schon klar, oft genug aus den Sourcen übersetzt den VLC Player.
Meine Aussage auf kostenpflichtig bezog sich mehr auf einige handelsübliche Player die für die Windoof User zur Verfügung stehen.
Wie auch immer, mplayer bietet meiner Meinung nach mehr Performance beim Streamen von der Dream als VLC, egal ob unter Windows oder Linux. Aber das sind meine Erfahrungen damit. Es scheint aber auch wenige Leute zu interessieren, das mit Mplayer mal auszuprobieren und Erfahrungen zu berichten. Ich hatte ja auch schonmal irgendwo ein kleines Script zur Verfügung gestellt, das das automatische Starten des MPlayer mit den jeweiligen Programmpids ermöglicht, aber auch darauf gab es bisher keine Reaktion. Na egal, wer nicht will der hat schon oder nimmt ebend was sturr vorgesetztes. So long.

cheers

Zitat

was ist "streamts"

Streamts wird auf der Box vom inetd Daemon gestartet sobald eine Anfrage auf dem gewähltem Port kommt. Solch eine Anfrage macht zum Beispiel vlc.

Warum allerdings jeder nur mit vlc oder anderen kostenpflichtigen Tools streamt ist mir ein Rätsel. Mplayer ist dafür allermale beser geeignet. Mit einem cache von 8192 kb ist da der saubere Dauerbetrieb auch unter Windows überhaupt kein Problem selbst mit verschlüsseltem Wlan nicht. Mit Linux sowieso nicht.

Also ich kann zumindest für die 7000er sprechen. Mit der Box ist streamen und gleichzeitiges Schauen auf gleichem Sender möglich. Allerdings bietet streamts auf der 7000er nur eine Verbindung gleichzeitig an. Also wäre die Bereitstellung über mehreren Ports nicht möglich. Mir leuchtet da aber wieder eine Idee mit Hilfe eines Puffers den stream auf mehreren Ports anzubieten. Aber ich muß mich vor Ideen mal bremsen. Ich bekomme hier nichts mehr fertiggestellt. Wie das streamen bei der 7025 aussieht, keine Ahnung. Vielleicht gibt aber die Option des Twintuners noch weitere Streamingmöglichkeiten.

cheers

Ich kann dir zwar keinen richtigen Tip geben, wie du dein Problem gelöst bekommst, aber "Makefile:2191: *** missing separator. Schluss." deutet auf einen Fehler im Makefile hin.

Hast du das Makefile evtl. mit einem Editor geöffnet? Dabei kann es leicht passieren ein Makefile unbrauchbar zu machen, was dann meist mit solchen Fehlermeldungen endet. Andernfalls hilft nur selbst patchen oder auf eine Aktualisierung des CVS zu warten.

cheers

Zitat

Du meinst #ifdef wegnehmen? Aber es soll ein Grund sein, das die #ifdef's da sind.

So in etwa. Das ist ja nur die bedingte Compilierung, die im Falle der Dreambox nur die ts Option zulässt. Ich habe bei Zeiten, ca. 1 Jahr her, einfach mal probiert die TRANSFORM Option zu aktivieren und damit auch die ps Option zuzulassen. Warum das als default deaktiviert ist weiß ich nicht. Vielleicht das fehlerhafte ps Format, obwohl das auch unter X86 Platformen, mit Benutzung einer Tv Karte, Probleme bereitet.

Zitat

Client asking: http://my.dreambox.ip:31339/0,sid,pid,pid
Server answering: OK\n\r\n\r ts-stream

Ist dass was du meinst?

Das ist ja das typische Protokoll, das auch streamts verwendet. Client fragt, Server antwortet und sendet stream im nowait modus, also alles was geht.

Ist das bei Multicast bzw. Unicast auch so?

Als Gegenbeispiel mal ein kurzer Ausschnitt aus dem Protokoll des KissPlayer.

Kiss fragt: nach Dateiliste
Server Antwort: Dateiliste
Kiss fragt: erste 64 Bytes der gewählten mpeg ps datei
Server Antwort: sendet erste 64 Byte der gewählten mpeg ps datei
Kiss fragt: erstes paar 531xxx Bytes
Server Antwort: erstes paar 531xxx Bytes
Kiss fragt: letzten 531xxx Bytes
Server Antwort: letzten 531xxxBytes
Kiss fragt: erstes paar 531xxx Bytes
Server Antwort: erstes paar 531xxx Byte
Kiss fragt: zweites paar 531xxx Bytes
Server Antwort: zweites paar 531xxx Byte
Kiss fragt: drittes paar 531xxx Bytes
Server Antwort: drittes paar 531xxx Byte
...und so weiter.

Du siehst, man kann nicht einfach wie bei streamts den kompletten Stream raw durch das Netzwerk streamen. Die Dreambox muß immer auf die Anfrage des Clienten (Players) warten und das für die komplette Zeit des Streams. Dies wiederum erfordert das puffern des Tv Streams bis zum Zeitpunkt der Anforderung durch den Player.

Da wäre ein Protokoll, wie es streamts verwendet schon besser, deswegen mein Interesse am Multicast/Unicast. Wenn aber streamts schon diese Protokoll von Grund auf beherrscht, kann ich ja damit nochmal einen Versuch starten.

cheers

Zitat

Aber "-ps" ist nicht implimentiert in dem Dreambox image? Es ist in ein #ifdef und nicht inkludiert wenn es ein Dreambox ist, glaube ich.

Hehe man kann es aber so drehen, daß es für die Dream passt.

Zitat

Wenn ich Multicast streamen sende ich die gleiche Daten wie im Unicast (ein transport stream wenn ich glück habe Augen rollen ) doch mit udp multicast statt tcp.

Ob tcp oder udp wäre egal, das Protokoll interessiert mich, also:

Client asking: ......give me infos about ...and so on
Server answering: so her are some important informations ...and so on.
Client asking: ....
Server answering: ......

cheers

Ich biete Ihnen das DU an.

Zitat

Meinen Sie streamts -ts (nicht -ps)? Haben Sie mein streamts in Unicast modus probieren? Es soll ein besseres transport stream machen.

Nein ich meinet streamts -ps aus dem cvs. Damit wird kein ts stream gestreamed sondern in Echtzeit ein MPEG-PS Format erzeugt. Da mein Player, der als Client der Box dienen soll nur MPEG Streams versteht, kann ich mit den TS Streams nichts anfangen und streamts mit Option "-ps" streamt ein unsauberes MPEG PS Format, deswegen der Ausweg mit den mencoder Sourcen. Mencoder und ffmpeg zumindest packen das locker in Echtzeit auf der Dreambox.

Warum ich am Multicast Protokoll interessiert bin. Der Player beherrscht angeblich auch dieses Protokoll, "unabhängig" vom Format das gestreamt wird. Da das Protokoll des kissplayers (eine Art HTTP Protokoll) aber keinen Raw Stream empfängt sondern immer die gewünschten Bytes anfordert, ist damit ein gewisser Bufferaufwand auf der Serverseite (Dreambox9 verbunden, der den Echtzeit MPEG-PS Stream bis zur Anfrage der gewünschten Bytes zwischenbuffert. Bisher habe ich das mit perl auf der Dreambox gelöst, was aber noch nicht so exakt performed. Wenn das Multicast Protokoll in der Hinsicht etwas mehr Vorteile bringen würde, wäre das für mich evtl. interessant. Deswegen die Frage nach dem Aufbau des Protokolls.

cheers

Mich würde mal das reine Multicast Protokoll interessieren...also die Server/Client Anfragen/Antworten. Ich bin gerade dabei einen Teil des mencoder codes für die dreambox zu portieren um den TS Stream in realtime zum Mpeg-PS zu convertieren. Das soll für einen Server von nutzen sein, der für meinen Kiss DVD player die files auf der box, sowie den tv stream zur Verfügung stellt. Die streamts -ps Option bringt ein leicht fehlerhaftes Format, womit der Kiss Player nicht zurechtkommt. sonst würde es auch mit dem Code gehen. Evtl. würde ich mir mit dem Multicast Protokoll, was der Player auch beherrschen soll, das lästige Protokoll zum streamen des Players ersparen und somit den ganzen Timingaufwand.

cheers

Die Fehler weisen auf fehlende Symbole (Funktionen) in deinen libs hin. Ich habe dafür die Version 2.13 released, die in einer chroot Umgebung läuft und benötigte Sachen dazu mitführt. Diese Version läuft quasi unabhängig von dem verwendeten Image.

cheers

Zitat

... wie kann ich dann das pwd generieren ?

Ähm wo genau meinst du das ? Das lässt sich zumindest mit dem amule Startscript bewerkstelligen. Siehe auch "/hdd/aMule/bin/amule -h" oder in den aMule Threads hier im Forum. Ansonsten wüsste ich momentan nicht was dein Problem ist ?

Gruss

PS: Habe gerade gesehen, daß bei dir cut und md5sum Problem bereiten.
Da die Dream leider keine "echo -n" beherrscht gibt es dabie Probs.
Momentan komme ich nciht auf meine Box. Also wäre eine Linuxkiste hilfreich.
echo password | md5sum | cut -d '-' -f 1. Also beim Password dreambox:

~>echo -n dreambox | md5sum | cut -d '-' -f 1
~>e641d6ac68e70fcc0f5adb089dd3f1bd

1.) Evtl. Festplatte voll (Indodes beachten)? Swapfile auch aktiviert ?

2.) Eigentlich sollten die geforwardeten Ports reichen. Versuche auch mal beides zu aktivieren TCP/UDP. Stehe diesbezüglich gerade etwas auf dem Schlauch.Ich weiß aber auch, das einige Router bei dem hohen Traffic (Verbindungen) der p2p Netzwerke in die Knie gehen. Dein Netzwerk mit den 5 Geräten untermauern den Verdacht ja noch zusätzlich, zumindest wenn alle gleichzeitig laufen sollten.

3.) Ja.

4.) Die Ordner sind versteckt. Linuxspezifisch der vorangestellte Punkt der Directory. Wenn du den Modus in deinem FTP-Tool auf sichtbar setzt, sollte es auch verfügbar sein. Alternativ kann man auch zu Zugriff vom PC Samba nutzen.

5.) Bezüglich der Ports kannst du in den configs von aMule andere Ports verwenden. Diese musst du im Router dann aber auch ändern. Beachte aber die Faustregel nach der amule automatisch den UDPPort vergibt:
UDPPort = TCPPort + 3 . Also z.B. deine 4711 und 4714.
Bezüglich der Sichtbarkeit der Ordner kannst du das evtl. in den Configs ändern. Stehe ich gerade auf dem Schlauch. Ich weiß nicht ob amule die Ordner fest vergibt, es also hardcodec ist und nur bei Neucompilation zu ändern ist, aber warum?

6.) Ich glaube nicht. Man könnte evtl. eine server.met mit seinen favorisierten Servern erstellen. Aber auch hier warum? Meine Beobachtungen ergaben, dass aMule mit einer High ID immer den besten Server automatisch gewählt hat, zumindest den Server mit den meisten Connections bzw. Files.

7.) Jepp das liegt an der fehleneden gdlib. aMule liess sich zwar compilieren wieß aber nicht auf diese exakte Fehlermeldung hin. Ich finde nur irgendwie kaum noch Zeit mich mit dem aMule Port zu beschäftigen. Vielleicht mal wieder beim nächsten Release von aMule. Das Problem mit dem abgestürztem Webif kann man aber einfach beheben. Ein Restart von amuleweb hilft dabei. Also "/hdd/aMule/bin/amule -w" bzw. /hdd/amule/amule -w je nachdem welchen aMule Port du verwendest.

8.) Habe ich noch nicht getestet und kann keine Aussage dazu machen.

Soweit ich weiß läuft auf dem Topf doch kein Opensource, geschweige denn Linux oder ?

Wenn dem so ist, ist die Kaufentscheidung für die Dream in meinen Augen klar favorisiert. Allein durch die Open Source Software der Dream hat die Box wesentlich mehr Möglichkeiten als jeder andere Non Linux bzw. Non Open Source Receiver. Das sollte man auch mal bei der Kaufentscheidung erwähnen. Wie viele Geräte hatte ich schon im Einsatz, die letztendlich in der Ecke stehen, weil man an den Teilen nicht selber Hand anlegen kann, um seine speziellen Features einzubauen bzw. bei Macken der Software auf den Support der Hersteller angewiesen ist. Wenn dann nix Seitens der Hersteller passiert, bist du genauso angeschi**en.

Sicher wird es für den Topf eine große Com geben, die dafür Plugns etc. anbietet, doch diese Com gibt oder gab es für den Humax5400 auch. Troztdem, mal abgesehen vom Alter des Humax5400, würde ich mich jederzeit wieder für eine Dream entscheiden. Was ich auf meiner 7000er schon alles zum laufen gebracht habe, da kommt mit Sicherheit "kein" anderer Receiver mit. Und mich in irgendwelche preprioritäre Softwares der Receiverhersteller enzufuchsen, darauf hätte ich wohl die geringste Lust.

Klar hat die Dream auch irre Macken oder hatte sie. Dennoch ist es mit etwas Verständnis der Materie möglich die Fehler selbst auszumerzen, bzw. auf das Wissen der Dreambox Com zurückzugreifen Genügend "FAQ's" und Anleitungen für Jedermann ginbt es ja im Netz. Außerdem bietet das CVS die Möglichkeit seine eigenen Images zu bauen und Anwendung nach belieben zu integrieren.

Man sollte allerdings dafür auch schon etwas Gedult und den Willen mitbringen, mit der Box etwas mehr anzustellen, als nur TV schauen. Ansonsten braucht man auch in meinen Augen keine Dream.
Dann macht es auch jeder andere Receiver. Ich denke aber den finanziellen Mehraufwand gegenüber anderen Boxen mit selber Austattung macht die Dream locker wett.

cheers

Gründe für das fehlerhafte Ausführen deines Binarys auf der Dream sind die gestrippten libs in dem Image. Bei maken der Images werden alle Tools des Image auf verlinkte Bibliotheken, besser gesagt Funktionen überprüft. Für den Platzbedarf sorgt das phänomenale mklibs.py Script dafür, daß alle Funktionen der Bibliothken, die nicht von den Tools zur Laufzeit benötigt werden entfernt werden. Das bringt etwas Platz, hat aber den Nachteil, dass späterere, dem Image zugefügte Tools nicht mehr funktionieren, da ebend besagte Funktionen aus den libs gestrippt wurden.

Übrigens kannst du notfalls auch deine libc.so.6 auf die Dream schieben. Dann sollten die größte Probs der gelinkten Tools behoben sein. Ich bin zwar kein Fan von Bibliotheken-Versions-Mischmasch, aber in dem Fall sollte das machbar sein.

Die libc.so.6 ist übrigens keineswegs zwangsläufig 80 MB groß. Da sind nur mordsmäßig viele Debuginfos drin. Dafür sorgt unter anderem das FLAG "-ggdb3". Die Debugs kannst du aber entfernen. Adde den Pfad deines Crosscompiler zu der PATH Variable. Kopiere die libc.so.6 aus deiner Crossumgebung wohin du willst und strippe sie mit dem Befehl:

powerpc-tuxbox-linux-gnu-strip --remove-section=.comment --remove-section=.note --strip-unneeded libc.so.6

Deine libc.so.6 sollte dann so in etwa 1,2 - 1,3 MB groß sein und damit in das Image der Dream integrierbar sein.

Das ist ürbigens schon in etwa das Maximum, wie man dynamische Bibliotheken strippen kann. Versuche keine weiteren Hardcore Stripversuche, wie etwa die Option "-s". Das macht die libs unbrauchbar und damit auch dein komplettes Image.

Denke aber daran eine Kopie deiner libc zu machen. Andernfalls gehts beim nächsten Imagebauen schief!!! mklibs.py macht dann nämlich Probleme mit extrem gestripten libs.

Alternativ:

Das statische Linken funktioniert unter anderem mit dem Linkerflag "-static".
Kann also quasi zu dem CFLAG und CXXFLAG in den Makefiles gefügt werden.
So in der Art CFLAGS="-mcpu=405 -msoft-float -mmultiple -mstring -meabi -pipe -Os -static".

Ist bei kleinen Tools sicher machbar, aber bei größeren Anwendung leidet die Performance.

cheers

Zitat

Kann mir vielleicht jemand schreiben, welches Programm man für den USB-Anschluß nehmen kann -
a) unter XP
b) unter Linux?

Also erstmal wird das Abgreifen des Streams nicht ohne weiteres bei der 7020 über USB gehen. Wenn es überhaupt technisch gehen sollte, dann musst du auch vorerst was auf der Dream ändern (ein Tool, dass den Stream via USB bereitstellt, bzw. streamts.cpp patchen). Weiterhin verfügt die Dream 7020 auch nur über einen USB 1.1 Anschluß. Damit sind nicht mal TV Sender in der schlechtesten Qualität streambar. Die Bandbreite gibt's einfach nicht her.

Fazit:
Wenn schon Billigreceiver, dann mindestens mit USB 2.0.
Ich bezweifel aber, dass es einen Billigreceiver gibt, der den Stream via USB anbietet. Selber was auf dem Billigteil programmieren, wird zwangsläufig dank Closed Source nicht möglich sein, also auch dein Vorhaben nicht.

Alternativ wäre ebend die erwähnte Dream 600, die in meinen Augen auch für dein Bestreben den meisten Sinn macht oder aber das Zurückgreifen auf eine TV Karte für dein Notebook.

Gruss

Zitat

Wie starte ich es denn "manuell"?

/var/bin/amule_restart.sh &

Ein anschliessendes `ps aux` wird dir Auskunft über den laufenden Prozess geben. Ist dort kein Eintrag von amule_restart.sh enthalten, läuft das Script nicht.

Zitat

Wird das Script bei mSystemstart nicht gestartet?

Das lag unter anderem an der falschen /var/etc/init .
Berichtigt in meinem vorherigen Anhang.

Zitat

Ich habe die Dateien mit Ultraedit erstellt und dann per FTP auf die Box geschoben,...falsch?

Grundsätzlich nicht, du musst Ultra Edit aber auch erzählen, das du ein Unixformat haben willst, sonst macht der Editor default Windowsformate.
Evtl. passiert das auch durch den Transfer via ftp. Habe ich dabei auch schon oft erlebt, dass dabei Unixformate einfach nach Windoof gewandelt wurden. Am besten mit dem Editor direkt auf der Dream die Datei öffnen. Ich weiß nicht, ob das Ultraedit kann. Crimson Editor kann das.

Zitat

Sagst du mir wie? per Telnet einfach das Script ausführen?

Genau. Einfach per telnet auf die Box und siehe Punkt 1.
By the way erfährst du auch dadurch, ob das File im Unixformat ist. Bei Schwimmdowsenformaten kommt ebend eine Fehlermeldung.

cheers

Also "Funktioniert leider nicht" ist natürlich eine sagenhaft umfangreiche Aussage.

Was funktioniert nicht?
Kannst du es nicht starten ?
Wird das Script bei mSystemstart nicht gestartet?
Läuft das Script startet jedoch amule nicht ?

Kann ich sonst nicht nachvollziehen.

Ich hatte noch einen kleinen Fehler im init Script drin. Du musst den Prozess "amule_restart.sh" im Background starten. Also "/var/bin/amule_restart.sh &". Siehe auch im Anhang.

Wenn du die Dateien in dem Format auf der Dream hattest, wie aus deinem Anhang kann es nicht funktionieren. Ich hatte doch auf einen unixtauglichen Editor hingewiesen. Deine Files haben die Windows Syntax und das läuft nunmal glücklicherweise nicht auf der Dreambox. Die Dateien in meinem Anhang haben schon das passende Format, also ungeöffnet von deiner Windowsbüchse auf die Dream schieben.

Hast du das Script mal per Hand gestartet ? Was sagt die Ausgabe ?
Benutzt du auch amule mit dem Startscript /hdd/amule/bin/amule ?
Wenn nicht, wie startest du für gewöhnlich deinen Esel auf der Dream ?

cheers

Also kurz gesagt, wenn du eine 6 MBit Leitung hast, reicht das zwar locker aus um den Stream in voller Auflösung übers Internet zu empfangen. Leider kann dein Kollege (Freund) aber nur mit ca. 512 kbyte/s senden. Somit bekommt er nicht den Stream in voller Auflösung ins Netz. Es nützt also nur was, wenn er eine Uploadbandbreite von ca. 3-4 MBit/s hat oder den Stream transcoded und dir in geringerer Auflösung zur Verfügung stellt. Dazu benötigt er aber einen schnellen Rechner (Server) und die Bildqualität wird wohl sehr miserabel sein.

cheers

Da ich vermute, daß du kein cron auf der Box hast, hier ein kleines Script, daß von den üblichen Tools auf der Box unterstützt wird.

#!/bin/sh


do_amule() {
	if [ $i = '23:00:' ] ; then
		do_kill
		/hdd/amule/bin/amule
	else 
		do_kill
	fi
}


do_kill() {
	for a in amuleweb amuled ; do 
			pidof $a >/dev/null && killall $a 2>/dev/null 
			pidof $a >/dev/null && killall -9 $a 2>/dev/null
	done
}


while true ; do
	for i in '23:00:' '14:00:' ; do
		date | grep $i >/dev/null && do_amule $i
	done
	# sleep must be less than 60 second !!
	sleep 50
done

NOTE: Editiere die folgende(n) Datei(en) mit einem Unixeditor !!

1. Erstelle eine Texdatei namens amule_restart.sh und packe sie nach /var/bin.
2. Editiere deine /var/etc/init mit der Line "/var/bin/amule_restart.sh".
Wenn /var/etc/init nicht vorhanden, dann erstellen. Damit wird das Script bei jedem Start der Box mitgestartet, wenn du Interesse hast.
3. chmod 755 /var/bin/amule_restart.sh /var/etc/init nicht vergessen !!!

Ich habe es nur mal kurz im Zeitintervall weniger Minuten gestestet. Probiers aus!

cheers

Zitat

Aber eine Frage hab ich noch, wie kann ich mir in dem
Bildschirm eine Ausgabe anzeigen lassen?

Was meinst du mit Bilschirm, die Konsole der telnet Session oder den TV Monitor?

Zitat

Das liegt daran dass wenn ich den Daemon im Telnet
aufrufe, dass dann keine Eingabeaufforderung mehr kommt.

Das hat dann aber nichts mit deinem genannten Script zu tun.

Also nochmal langsam. Wann kommt keine Eingabeaufforderung mehr? Wenn du den Daemon über telnet startest und wenn ja wie wird er von dir gestartet oder beim Start über dein Script?

Zitat

Meine jetztige Frage ist, wie bekomme ich die unteren ECHOS
angezeigt oder wie bekomme ich in dem Fenster die Telnet
ausgaben angezeigt?

Ich vermute dadurch, daß der Daemon in den Background geschickt wird, ist somit die Standardausgabe in der telnet Session beendet. Das sollte aber nicht zwangsläufig so sein. Es gibt genauso gut Daemons, die auch im Background weiterhin ihre STDOUT's auf die Konsole schicken. Ich kenne dein Daemon leider nicht, sonst wüsste ich wohl mehr darüber.