Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: VDR Portal. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Sonntag, 29. Mai 2005, 14:58

[ANNOUNCE] ffnetdev plugin 0.0.1

Hallo allerseits,

ich habe ein kleines Plugin zusammengebastelt, dass ich Euch nicht länger vorenthalten möchte. ;-)
Vielleicht kann der ein oder andere ja etwas damit anfangen oder hat evtl. noch weitere Ideen zur Verbesserung.
Bis jetzt existiert hier nur ein rudimentärer Dreambox Client für das Plugin.

Kurze Beschreibung auf deutsch:
Dieses Plugin soll eine Art "Full-Featured DVB device emulation über das Netzwerk" sein. (Mir ist leider keine bessere Bezeichnung eingefallen. :D ) VDR sieht also ein weiteres Device, dass MPEG2 Playback und ein OSD unterstützt. Nur werden diese Daten über das Netzwerk an einen Client gesendet.

Das Plugin verfolgt also einen ganz anderen Ansatz als das streamdev-Plugin . Anstatt auf einem potentiellen Client einen "ausgewachsenen" Client zu schreiben, soll ein "einfacher" Client herhalten, der nur den Empfang des TS und die Anzeige des bereits fertigen OSD übernehmen soll.

Ich kann das Plugin mit meiner Dreambox 5620S momentan ohne größere Probleme benutzen. Ich habe dazu einen kleinen nativen Client (kein Enigma Plugin!) für die DM zusammengebastelt.
Um der Frage vorwegzugreifen: Warum sollte man eine Dreambox für sowas benutzen???Bekloppt! :-)
1. ich habe an diesem Ort keinen SAT-Anschluss, aber Netzwerk. :-)
2. ich nehme lieber eine Dreambox5620 oder 500 als eine MediaMVP, weil dort die Software-Unterstützung besser ist und alle Anschlüsse schon vorhanden sind(SPDIF, etc....)

Also viel Spass damit!
Nicht vergessen: Es handelt sich dabei, um einen ersten Versuch!!!

Gruss,
Nano

---schnipp---

This is a "plugin" for the Video Disk Recorder (VDR).

Written by: Christian Cier-Zniewski <c.cier@gmx.de>
some code taken from: Sascha Volkenandt's streamdev plugin <sascha@akv-soft.de>

Project's homepage: http://nano.gmxhome.de/ffnetdev/

See the file COPYING for license information.

!!! WARNING !!!
The code of this plugin is alpha quality. So expect it to have all kinds of bugs.
If it crashes your machine, do not blame me. You have been warned!!! :-)
!!! WARNING !!!

------------
Description:
------------

The purpose of this plugin is to provide an "easy" way of connecting possible streaming clients
to VDR by emulating a full featured DVB device over the network.
So the first thing that has to be written for the desired client is the code which receives the OSD bitmap
and transfers it into the streaming client's framebuffer.
The second thing is the TS receiver module. Assuming that the streaming client provides MPEG2 hardware decoding
you must find a way of sending the TS to hardware demuxer or demultiplex it in software if the client's CPU is powerful
enough.

A multi client environment can look as follows:
--------------------------------------------------------------------
---powerful Server with one main VDR process and streamdev-server---
--------------------------------------------------------------------
- -
- -
---------------------------------------------------- ----------------------------
-2nd VDR process with streamdev-client and ffnetdev- - 3rd VDR process and so on-
---------------------------------------------------- ----------------------------

Each streaming client gets its own (perhaps customized) VDR.


--------
Details:
--------

The plugin creates two listening TCP sockets:
-one for remote control and OSD
-one for TS streaming to the client

OSD (and text2skin)
-------------------
The OSD is transfered using a rfb style protocol (aka VNC). See rfbproto.h for details.
You can also use the text2skin plugin to get a nice skinned OSD.
BUT BE AWARE that the current code only supports ONE BIG AREA (method CanHandleAreas).
This limitation is due to the fact that my current and only client (a Dreambox 5620S) only
supports an 8-bit palette based framebuffer.
So if you want to use the text2skin plugin you have to change the desired skin to only use ONE
<window> tag with the greatest bounding rectangle the skin wants to draw in. bpp should be set 8 bits.

TS streaming
------------
The PES packets are multiplexed into a TS by the plugins own very simple PES2TS remux code.
No PAT/PMT insertion is currently being done.
The two TS PIDs for Audio and Video PIDs have fixed values. So changing a channel does not result in a change
of the TS PIDs.

Existing clients
----------------
-Dreambox 5620S (simple native client, it is NOT an enigma plugin!)

--------------
Prerequisites:
--------------
This plugin only works for VDR versions >=1.3.7, because of changes in the OSD code.

Installation:
-------------

Install ffnetdev like any other plugin. In this example I assume that you have
changed to the folder where the VDR sourcecode is located, and that it is
version 0.0.1 of the plugin you wish to install.

root@linux # cd PLUGINS/src
root@linux # wget http://nano.gmxhome.de/ffnetdev/vdr-ffnetdev-0.0.1.tgz
root@linux # tar -xfz vdr-ffnetdev-0.0.1.tgz
root@linux # cd ../..
root@linux # make plugins
root@linux # ./vdr -P ffnetdev

2

Sonntag, 29. Mai 2005, 15:56

Hi,
ich bekommen beim Compilieren die Meldungen:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
make[1]: Entering directory `/vdr/vdr-1.3.24/PLUGINS/src/ffnetdev-0.0.1'
g++ -W -Woverloaded-virtual -O2 -c -D_GNU_SOURCE -I../../../include -I../../../../DVB/include -I. -o ffnetdev.o ffnetdev.c
In file included from worker.h:16,
                 from ffnetdev.c:12:
netosd.h:27: parse error before `&'
netosd.h:27: stray '\' in program
netosd.h:28: stray '\' in program
netosd.h:38: destructors must be member functions
netosd.h:38: virtual outside class declaration
netosd.h:39: virtual outside class declaration
netosd.h:40: virtual outside class declaration
netosd.h:42: parse error before `}'
netosd.h:49: syntax error before `*'
ffnetdev.c: In method `class cOsd * cNetOSDProvider::CreateOsd(int, int)':
ffnetdev.c:32: parse error before `('
make[1]: *** [ffnetdev.o] Error 1
make[1]: Leaving directory `/vdr/vdr-1.3.24/PLUGINS/src/ffnetdev-0.0.1'


Hmm, sagt mir gar nix!
Vielleicht jemand anderem?

Spoiler Spoiler

Server: 16 GB RAM; 16TB HDD; Ubuntu 14.04

Client 1: Intel Dual E2200, 2GB RAM, 250GB SSD, NOVA T 500, TT 1500 DVB-C, 2 x TT S3200 Ubuntu 14.04

Client 2: AMD AM2 E1650, 1GB RAM, 200GB HDD, TT 1500 DVB-C, YaVDR-0.5.0

4 x Raspberry Pi - Rasbian Jessie VDR 2.2.0

olafhenkel

Erleuchteter

Beiträge: 2 765

Wohnort: Dormagen (NRW, bei Köln)

Beruf: Bürotippse bei nem Klempner

  • Nachricht senden

3

Sonntag, 29. Mai 2005, 16:19

Mal ne dumme Frage...

Tach,

das Ding würde doch auf ner MVP eh vermutlich gar nicht laufen, oder vertue ich mich da ? Wie sollte das dann gehen ???

Greets Olaf
Ollie jetzt auch im Internet !!! ->> www.ohms.ws << VDR mit ASUS A7V8X-X, Athlon XP 2 Ghz, 512 MB DDR-RAM und gentoo 2008.0 Linux, ner Menge Platten (1 TB), 2 Brennern und Karten-Vollausstattung (1 X Nexus 4 MB Mod, 3 x Nova, 1 PVR 350) , TFT/Sony PSOne, Nvidia Graka und und und * Linux - wir geben ihrem Computer das Leben zurück *

4

Sonntag, 29. Mai 2005, 16:31

Moin,

also was den Fehler bei Kompileren angeht, muss ich hier mal weiter erforschen.

Ich habe das Plugin zuletzt mit vdr-1.3.23 getestet und mit gcc version 3.3.4 (pre 3.3.5 20040809) kompiliert (SuSE9.2).

Olaf:
Das Plugin läuft ja quasi auf dem VDR Server "im Keller" und liefert Dir schon ein gerendertes OSD.

Die MediaMVP, die übrigens den gleichen Prozessor benutzt wie die kleinen Dreamboxen, muss ja "nur" das OSD darstellen, durch kopieren der Bitmap-Updates in den Framebuffer. Den TS, den das ffnetdev Plugin liefert, sollte man "einfach" in den Hardware-Demuxer der MediaMVP schreiben können. Nur liegt gerade hier bei der MediaMVP der Hase im Pfeffer. Mein letzter Stand ist, dass es mit dem /dev/pvr device der MediaMVP nicht so richtig geklappt hat. Ich kann mich auch irren.

Die Idee dieses Plugins ist also, dass der Server im Keller alles vorkauen soll und der "doofe" Client nur noch darstellen soll.

Ich werde den Dreambox Client auch noch auf die Webseite packen, wenn ich den Code ein wenig aufgeräumt habe. :-)

Du bräuchtest also für Deine MediaMVP also zunächst erst einmal einen Client, der zum ffnetdev Plugin passt. Noch gibt es keinen....

5

Sonntag, 29. Mai 2005, 16:38

RE: [ANNOUNCE] ffnetdev plugin 0.0.1

Versteh ich das richtig, das ich z.B. in meinem Arbeitszimmer meinen Linuxrechner als Client für den vdr im Wohnzimmer laufen lassen kann? Oder geht das NUR mit der Dreambox?

Ich also einen ganz normalen vdr installiere der dann aber nicht auf eine DVB Karte zugreift sondern auf dein 'DVB Device over network'?

Das wäre schon mal ne coole Sache ;)

6

Sonntag, 29. Mai 2005, 16:44

xpix:

Öhm. Das, was Du machen möchtest, geht doch schon längst, oder?

Pack auf Deinen Wohnzimmer VDR das Streamdev-(Server)-Plugin und installiere Dir auf Deinen Linux Client PC den VDR mit Streamdev-(Client)-Plugin.
Zusätzlich dann noch das Softdevice Plugin.
ODER: verzichte auf diese beiden Plugins und schau Dir die Netzwerk-Version des Xine Plugins an.

Man könnte aber auch für einen normalen Linux oder Windows PC einen Client schreiben, der dann das OSD des VDR Wohnzimmer Rechners darstellt und den TS des ffnetdev Plugin abspielt.

7

Sonntag, 29. Mai 2005, 16:45

RE: [ANNOUNCE] ffnetdev plugin 0.0.1

Hallo,

wäre diese Geschichte auch mit ner D-Box II machbar?
FSC Esprimo P5625 AMD Athlon X2 4400 | VDR-SERVER | Centos 7 Kernel-4.4.19 | DVBSky S952 v2 & DVBSKy S950 v3 | VDR-2.2.0 | dummydevice, streamdev-server, etc.
Raspbery Pi 1 Model B + | Debian wheezy Kernel-3.18.8-v7+ | VDR-2.2.0 | epgsearch, remotetimers, skinsoppalusikka, svdrpservice, mailbox, rpihddevice, sleeptimer, undelete, osdteletext, streamdev-client
Raspbery Pi 2 - Model B | Debian jessie Kernel-4.1.15-v7+ | VDR-2.2.0 | epgsearch, remotetimers, skinsoppalusikka, svdrpservice, mailbox, rpihddevice, sleeptimer, undelete, osdteletext, streamdev-client

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »armageddon« (29. Mai 2005, 16:45)


8

Sonntag, 29. Mai 2005, 16:54

armageddon:

puh, gute Frage. (hab keine dbox2)
Also das OSD in den Framebuffer einzuschauffeln wird wohl kein Problem sein.
Ich weiss nicht, wie es mit dem Abspielen von TS ausschaut.
Wie macht das denn der dbox2 Movieplayer?
Demuxt der den TS in Software oder wird der TS in die Hardware geschickt?

9

Sonntag, 29. Mai 2005, 18:09

Zitat

Original von Nano
armageddon:

puh, gute Frage. (hab keine dbox2)
Also das OSD in den Framebuffer einzuschauffeln wird wohl kein Problem sein.
Ich weiss nicht, wie es mit dem Abspielen von TS ausschaut.
Wie macht das denn der dbox2 Movieplayer?
Demuxt der den TS in Software oder wird der TS in die Hardware geschickt?


Tja, hab mal so 'nen bisschen gegoogelt, aber auf diese Frage ob die DBox in
Soft oder Hardware demuxt keine Antwort gefunden.

War ja auch erst mal so ein Gedanke da es die Kabelboxen für nen Appel und Ei gibt.
FSC Esprimo P5625 AMD Athlon X2 4400 | VDR-SERVER | Centos 7 Kernel-4.4.19 | DVBSky S952 v2 & DVBSKy S950 v3 | VDR-2.2.0 | dummydevice, streamdev-server, etc.
Raspbery Pi 1 Model B + | Debian wheezy Kernel-3.18.8-v7+ | VDR-2.2.0 | epgsearch, remotetimers, skinsoppalusikka, svdrpservice, mailbox, rpihddevice, sleeptimer, undelete, osdteletext, streamdev-client
Raspbery Pi 2 - Model B | Debian jessie Kernel-4.1.15-v7+ | VDR-2.2.0 | epgsearch, remotetimers, skinsoppalusikka, svdrpservice, mailbox, rpihddevice, sleeptimer, undelete, osdteletext, streamdev-client

10

Montag, 30. Mai 2005, 11:46

Also einen "echten" TS kann man soweit ich weiß direkt auf die Hardware geben.
Zumindest TS-Files, welche direkt von der DBox gestreamt wurden, aber auch andere MPEG-Files, die man mit ProjectX in einen TS umgewandelt hat.

Das PES-Format der .vdr-Files kann man mit dem DBox Movieplayer allerdings nicht direkt abspielen.
Diese muß man vorher mit ProjectX in einen TS umwandeln.

Wenn das Plugin also wirklich TS und nicht PES verwendet, sollte das kein Problem sein.
Nadelöhr könnte aber wie immer der 10MBit-Netzwerk-Port werden.

Bei WalMart gibt's die Kabel-Teile übrigens für 39,- Öhre.

Gruß,

Pacemaker

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »pacemaker« (30. Mai 2005, 11:47)


11

Montag, 30. Mai 2005, 12:03

Zitat

Original von pacemaker
Also einen "echten" TS kann man soweit ich weiß direkt auf die Hardware geben.
Zumindest TS-Files, welche direkt von der DBox gestreamt wurden, aber auch andere MPEG-Files, die man mit ProjectX in einen TS umgewandelt hat.

Das PES-Format der .vdr-Files kann man mit dem DBox Movieplayer allerdings nicht direkt abspielen.
Diese muß man vorher mit ProjectX in einen TS umwandeln.

Wenn das Plugin also wirklich TS und nicht PES verwendet, sollte das kein Problem sein.
Nadelöhr könnte aber wie immer der 10MBit-Netzwerk-Port werden.

Bei WalMart gibt's die Kabel-Teile übrigens für 39,- Öhre.

Gruß,

Pacemaker


Wobei TS nicht gleich TS ist.
Meines Wissens kann man die mit einer Dream aufgezeichneten Files nicht
mit der Dbox abspielen. Oder irre ich mich? :rolleyes:
FSC Esprimo P5625 AMD Athlon X2 4400 | VDR-SERVER | Centos 7 Kernel-4.4.19 | DVBSky S952 v2 & DVBSKy S950 v3 | VDR-2.2.0 | dummydevice, streamdev-server, etc.
Raspbery Pi 1 Model B + | Debian wheezy Kernel-3.18.8-v7+ | VDR-2.2.0 | epgsearch, remotetimers, skinsoppalusikka, svdrpservice, mailbox, rpihddevice, sleeptimer, undelete, osdteletext, streamdev-client
Raspbery Pi 2 - Model B | Debian jessie Kernel-4.1.15-v7+ | VDR-2.2.0 | epgsearch, remotetimers, skinsoppalusikka, svdrpservice, mailbox, rpihddevice, sleeptimer, undelete, osdteletext, streamdev-client

12

Montag, 30. Mai 2005, 12:31

Das ffnetdev Plugin erzeugt aus dem Audio- und Video-PES einen TS, wobei sich das Muxen auf das Zerhacken der PES Pakete in kleine TS Pakete beschränkt. Die Hardware Demuxer der IBM STB scheinen damit ganz gut zurechtzukommen. Beim Dreambox Client habe ich die PCR PID gleich der Video PID gesetzt.

Ich habe aber beispielsweise gelesen, dass die Siemens M740 Box solche einfachen TS nicht richtig abspielt, weil die ganze PCR Geschichte im TS Adaptation Field nicht vorhanden ist(ganz grob).

Der Autor, der VDR auf dieser M740 zum Laufen gebracht hat, war u.a. auch damit beschäftigt einen Remuxer zu schreiben, der "bessere" TS baut.

Den IBM STB Chips scheinen jedenfalls die PTS der PES auszureichen, um synchron wiederzugeben.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Nano« (30. Mai 2005, 12:32)


13

Montag, 30. Mai 2005, 13:01

Zitat

Original von armageddon

Wobei TS nicht gleich TS ist.
Meines Wissens kann man die mit einer Dream aufgezeichneten Files nicht
mit der Dbox abspielen. Oder irre ich mich? :rolleyes:


Jo, leider.

Wäre es vielleich möglich, irgendwo einen Test-Schnipsel zur Verfügung zu stellen um das mal testen zu können? Müsste ja auch nicht lang sein.

Wäre auf jeden Fall geil, wenn das funktionieren würde. Ein Plugin für Neutrino zu coden sollte eigentlich dann auch nicht mehr soooo schwierig sein. Bin mir sicher, daß sich da auch im Berlios Board User finden würden, die sowas verwirklichen können. Nebenbei gäbe es dann ja auch ein Plugin, das für Enigma auf DBox/Dreambox verwendet werden könnte. Und WalMart wäre endlich seine DBoxen los... ;)

Gruß,

Pacemaker

14

Montag, 30. Mai 2005, 14:38

Vielleicht helfen ja die Diskusionen im Tuxboxforum weiter?

Da gibt's auch nen VDR-diff für die Dbox da kann man doch bestimmt einiges an Wissen herausziehen.
FSC Esprimo P5625 AMD Athlon X2 4400 | VDR-SERVER | Centos 7 Kernel-4.4.19 | DVBSky S952 v2 & DVBSKy S950 v3 | VDR-2.2.0 | dummydevice, streamdev-server, etc.
Raspbery Pi 1 Model B + | Debian wheezy Kernel-3.18.8-v7+ | VDR-2.2.0 | epgsearch, remotetimers, skinsoppalusikka, svdrpservice, mailbox, rpihddevice, sleeptimer, undelete, osdteletext, streamdev-client
Raspbery Pi 2 - Model B | Debian jessie Kernel-4.1.15-v7+ | VDR-2.2.0 | epgsearch, remotetimers, skinsoppalusikka, svdrpservice, mailbox, rpihddevice, sleeptimer, undelete, osdteletext, streamdev-client

15

Montag, 30. Mai 2005, 15:16

@nano
Hört sich gut an dein Plugin. Hab ne DM7000, würde ganz gerne dein
Plugin testen. Wie schauts den mit dem Client für die Dream (7000) aus??

Vielen Dank für deine Antwort
Gigabyte GA-M720-US3, AMD X3 400e, GT220 Pailt, 4GB RAM, Tevii S470, debian squeeze und alles selber gebaut.
Dreambox

16

Montag, 30. Mai 2005, 15:58

@nano

Ich hoffe Du bist nicht böse, daß ich hier umtriebig bin, aber Dein Plugin macht mich ganz wuschig :rolleyes: ;)

Ich hab mal im Tuxbox-Forum einen Link auf dieses Posting gesetzt. Vielleicht melden sich ja Entwickler von dort, die gerne ein Neutrino/Enigma Plugin realisieren würden.

Hier der Link:

http://forum.tuxbox.org/forum/viewtopic.php?t=27737

17

Mittwoch, 1. Juni 2005, 20:58

@pacemaker:

kein Problem. :-)
Ich wünsche mir ja, dass der ein oder andere etwas Sinnvolles damit anfangen kann. :-)
Ich würde mir beispielsweise einen Client für den XBMC wünschen. :D

Zu dem TS-Schnipsel:
#define OSDPORT 20001
#define STREAMPORT 20002

Installiere doch einfach dieses Plugin, setze das FFnetdev Device als Primary Device und nimm netcat, um Dich per TCP auf Port 20002 zu connecten. Sobald Du verbunden bist, bekommst Du den mometan ausgewählten Kanal als TS zugesendet.
#define TS_VPID 99
#define TS_APID 100
Die PIDs des Streams sind fix und haben die o.g. Werte.

Die beiden Ports funktionieren (momentan) unabhängig voneinander. Man muss sich nicht mit dem OSD Port verbinden, um einen TS zu bekommen auf dem anderen Port.

Das OSD Protokoll ist momentan auch recht easy gehalten:

Vom RFB Protokoll werden nur 3 Nachrichtentypen benutzt.

-rfbFramebufferUpdateMsg: enthält die Anzahl der zu übertragendenen Teil-Bitmaps.

-rfbFramebufferUpdateRectHeader: muss direkt der UpdateMsg folgen. Enthält die Breite, Höhe, X und Y Position der Bitmap. Es folgen soviele Kombis aus Header+Bitmap, wie es in der UpdateMsg angegeben wurde.
(momentan immer 1)

-rfbSetColourMapEntries: setzt die ARGB Werte der jeweiligen Paletten-einträge. Hier wurde das RFB Protokoll um den Alpha-Wert einfach erweitert. Die Message enthält den Start-Index und die Anzahl der Farben, die gesetzt werden sollen. Nach diesem Header folgen die 16-Bit Werte für A,R,G,B in der Reihenfolge.

Das war's schon. :-)

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Nano« (1. Juni 2005, 21:14)


18

Mittwoch, 1. Juni 2005, 21:05

Das Plugin lässt sich ohne Probleme mit vdr-1.3.25 compilieren.

Der Fehler beim Kompilieren hängt wohl mit dem Compiler zusammen.

Habe gerade gesehen, dass die Files nicht richtig im Unix Format sind. Mach doch mal ein dos2unix. Vielleicht verschwindet dann wenigstens der Fehler mit dem stray "\".

@morlock:

Der Dreambox Client ist für die DM5620S. Da die Dream-Jungs für die kleinen Boxen die DVB API nicht erneuert haben, müsstest Du den Client an die API 3 anpassen. Ich habe den Client mit nem aktuellen Image mit 2.6er Kernel getestet. Kompiliert habe ich den Client mit einem aktuellen CDK. Die ganz allten CDK (rel_1.0.0) machten bei mir Probleme, weil die libpthread nicht wie dokumentiert, funktionierte.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Nano« (1. Juni 2005, 21:13)


19

Donnerstag, 2. Juni 2005, 08:09

Ahhh, OK. Werd ich mal ausprobieren.
Das Plugin hab ich schonmal compilieren können (ohne Fehlermeldungen übrigens). Mal schaun, wann ich Zeit hab.

Apropos XBMC. Das wäre natürlich auch geil. Wobei mir ein noiseless Client wie die DBox oder Dreambox trotzdem lieber ist. Aber nicht nur wegen der Lautstärke. Ich habe gemerkt, daß die Bildqualität der Hardware-MPEG-Chips bei interlaced Material deutlich besser ist. Merkt man am besten bei Laufschrift. XBMC kann da leider nicht mithalten.

Dann noch zwei Fragen:

Gibt es einen Standard-RFB-Client, der mit Deinem Plugin klar kommt? Nur so zum testen.

Würde es Dir was ausmachen, den Source für den Dreambox-Client auch zu veröffentlichen? Würde sicherlich bei der Portierung helfen.

Meine Idee war, das VNC-Plugin als Ausgangsbasis zu verwenden. Mal schaun.

Gruß,

pacemaker

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »pacemaker« (2. Juni 2005, 08:15)


20

Donnerstag, 2. Juni 2005, 09:24

@Nano
den Client könnte ich selbst anpassen für die 7000, wäre schön wenn du mir deine Sourcen bzw. Ideen mal zukommen last. Muß ja nicht alles
neu machen.

Tschau
Gigabyte GA-M720-US3, AMD X3 400e, GT220 Pailt, 4GB RAM, Tevii S470, debian squeeze und alles selber gebaut.
Dreambox

Immortal Romance Spielautomat