VDR goes p2p

wenn man sich die Seite zum Plugin mal ansieht, dann kann man recht schnell sehen, dass man nur das runterladen kann was man auch selber empfangen kann.
Also wenn Du selber kein Premiere hast, dann wirst Du auch kein Premiere aus dem p2p bekommen.
Klar gäbe es da Möglichkeiten. Jedoch bin ich strikt dagegen. Wenn wir das hier besprechen, dann wäre es der Todesstoß für ein interessantes Projekt bevor es wirklich gestartet ist.
Also bitte keine Frage oder Anleitungen wie man das Plugin anders benutzen kann.

AT24106

Zitat

Freue mich schon, wen der erste Premiere abonent das Plugin installiert.

Was freut dich da? Wenn ich's richtig verstanden hab können nur die, die
ein Prem-Abo haben untereinander tauschen.

wie schon einer sagte - dann gibtshalt ein "ghost" plugin, was die aufnahme
halt vorgaukelt, aber halt 99% fehlt.

-- randy

Bis die Uploadgeschwindigkeiten der DSL allg. auf verwendbares Niveau angehoben werden, ist es vorallem für "Hausgemeinschaften" interessant. Dort wo mehrere isolierte VDR-Rechner in einem 100Mbit Netz zusammen werkeln.

Die Idee zur Nutzung von "fremden" Aufnahmekapzitäten über nicht verwendete DVB-Karte ist hier sicherlich die beste Komponente. Das verteilen der Aufnahme ist allerdings aus meiner Sicht relativ simple wenn man auf bestehende P2P Strukturen (denke da an Bittorent) aufsetzt.

AleX

Hat es wer am laufen?

Georg

Bekomme beim ./configure folgende Fehlermeldung:

checking whether stripping libraries is possible... yes
appending configuration tag "F77" to libtool
checking for SHA1 in -lssl... no
configure: error: ssl not found

Was fehlt da?

Georg

Zitat

Original von armageddon
lykorn

Heisst das Du bist im Besitz der fehlenden igor-x.x.x.tar.gz?

? wie kommste denn da drauf,...ich werds bei gelegenheit mal ausprobieren
ich hab noch keins der files gezogen

Zitat

Original von mag128
checking for SHA1 in -lssl... no
configure: error: ssl not found

openssl-devel?

-- randy

small patch

--- node.cc~    2005-11-30 14:59:43.000000000 +0100
+++ node.cc     2005-12-01 14:20:14.000000000 +0100
@@ -813,7 +813,7 @@
        dbg.print(dbg.NODE, 6, "in handlemsg_data_client\n");
        ///\todo do some checking
        // set source
-       if m->source().empty()
+       if (m->source().empty())
                m->setsource(_myref);
        // send the message
        int routeret = route(m);

sonst bekommt man Fehler beim kompilieren node.cc

Zitat

Original von free-x
small patch
...

sonst bekommt man Fehler beim kompilieren node.cc

Danke, ist eingebaut. Die neue Version kommt zur vollen Stunde auf den Webserver.

Kendy

Hi,

Ich bekomm heir auch mit der 0.1.1'Er Igor Version folgende Meldung beim Kompilieren.

make
source='libigor.cc' object='libigor.lo' libtool=yes \
depfile='.deps/libigor.Plo' tmpdepfile='.deps/libigor.TPlo' \
depmode=gcc /bin/sh ./depcomp \
/bin/sh ./libtool --mode=compile g++ -DPACKAGE_NAME=\"igor\" -DPACKAGE_TARNAME=\"igor\" -DPACKAGE_VERSION=\"0.1.1\" -DPACKAGE_STRING=\"igor\ 0.1.1\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"igor\" -DVERSION=\"0.1.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBSSL=1  -I. -I.     -g -O2 -c -o libigor.lo libigor.cc
 g++ -DPACKAGE_NAME=\"igor\" -DPACKAGE_TARNAME=\"igor\" -DPACKAGE_VERSION=\"0.1.1\" "-DPACKAGE_STRING=\"igor 0.1.1\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"igor\" -DVERSION=\"0.1.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBSSL=1 -I. -I. -g -O2 -c libigor.cc -Wp,-MD,.deps/libigor.TPlo  -fPIC -DPIC -o .libs/libigor.o
In file included from libigor.cc:35:
libigor.h:80: invalid exception specifications
libigor.h:82: invalid exception specifications
libigor.cc:48: invalid exception specifications
libigor.cc:49: invalid exception specifications
libigor.cc:56: ANSI C++ forbids data member `connection' with same name as enclosing class
libigor.cc:220: confused by earlier errors, bailing out
make: *** [libigor.lo] Error 1

[EDIT:]
Achso, der gcc hat die Version 2.95.3

Bekomme weiterhin diesen Fehler, auch mit gcc version 3.0.1 (SuSE).
Hat jemand nen Tipp woran das liegen könnte?

source='libigor.cc' object='libigor.lo' libtool=yes \
depfile='.deps/libigor.Plo' tmpdepfile='.deps/libigor.TPlo' \
depmode=gcc /bin/sh ./depcomp \
/bin/sh ./libtool --mode=compile g++ -DPACKAGE_NAME=\"igor\" -DPACKAGE_TARNAME=\
"igor\" -DPACKAGE_VERSION=\"0.1\" -DPACKAGE_STRING=\"igor\ 0.1\" -DPACKAGE_BUGRE
PORT=\"\" -DPACKAGE=\"igor\" -DVERSION=\"0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES
_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -
DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE
_DLFCN_H=1 -DHAVE_LIBSSL=1  -I. -I.     -g -O2 -c -o libigor.lo libigor.cc
mkdir .libs
 g++ -DPACKAGE_NAME=\"igor\" -DPACKAGE_TARNAME=\"igor\" -DPACKAGE_VERSION=\"0.1\
" "-DPACKAGE_STRING=\"igor 0.1\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"igor\" -D
VERSION=\"0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE
_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYP
ES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBSSL=1 -I.
-I. -g -O2 -c libigor.cc -Wp,-MD,.deps/libigor.TPlo  -fPIC -DPIC -o .libs/libigo
r.o
In file included from libigor.cc:35:
libigor.h:80: invalid exception specifications
libigor.h:82: invalid exception specifications
libigor.cc:48: invalid exception specifications
libigor.cc:49: invalid exception specifications
libigor.cc:56: ANSI C++ forbids data member `connection' with same name as enclo
sing class
libigor.cc:220: confused by earlier errors, bailing out
make: *** [libigor.lo] Error 1

Möchte mal wissen, wie die das Problem gelöst haben, dass ich beim Download von einer bestimmten Sendung mehrere Anbieter haben kann. Die Dateien unterscheiden sich doch von Rechner zu Rechner. Je nachdem wie genau die Uhren gehen und wieviel Vorlauf im VDR eingestellt ist, wie der Empfang ist etc. etc.
Die gleichen Probleme musste doch auch damals schon das ShareMarks-Plugin zum Austauschen von Schnittmarken-Positionen lösen (was ist eigentlich daraus geworden?)

Cool (bzw. besser) wäre es, wenn die VIDEGOR-Entwickler die Datei GOP-weise zerlegen würden (Vielleicht kann man die Adress-Offsets der GOPs und deren eindeutige ID ja schon beim Aufnehmen in eine Index-Datei abspeichern.)
Die gesharten GOPs kann man dann problemlos zusammenfuegen auch wenn sie von verschiedenen Anwendern kommen.
Wie üblich beim Filesharing hat man dann die zig-fache Bandbreite beim Download wenn man die GOPs nicht nur von einem Rechner holen könnte, sondern von zehn oder gar hunderten von Nutzern. Das Bottleneck weil nur jeweils einer eine bestimmte Sendung uploaden kann wäre damit sehr stark verringert.

Ich hoffe jedenfalls, dass es keinen Ärger wegen dieses Plugins geben wird. Schon allein wegen der Arbeit die drinsteckt.
Mir ist noch nicht ganz klar, wie sowas als wissenschaftliche Studie durchgeht. Die Filesharing-Theorie und -Praxis ist doch hinlänglich bekannt und Implementationen gibts genug. Ok, in einer Videorekordersoftware wurde es bisher noch nicht integriert. Vielleicht gings auch mehr um den Teil mit der Timersynchronisation/Verteilung.

Gruß
Jarny

Zitat

Das Videotransport Plugin ermöglicht dieses Nachladen von Aufzeichnungen über das Netz. Dazu werden alle Aufzeichnungen pro Sender in Blöcke von je einer Minute Länge unterteilt. Diese Blöcke werden vom jeweils nächst gelegenen Videgor Rekorder geladen. Dabei werden verschiedene Blöcke typischerweise von verschiedenen Rekordern geladen, um so die Netzwerkbelastung gleichmäßig zu verteilen.

Wenn man sich die technische Doku anschaut, scheint diese Problem gelöst zu sein( Es wird aber nicht abschließend erklärt wie der Zeittakt der Minuten syncronisiert wird. Den Ansatz mit GOPs halte ich für wahrscheinlich) , die Aufnahmen werden in Blöcke von einer Minute aufgeteilt..... Es ist scheinbar richtig P2P, also auch mit Parallelen Downloads.

Interesant! Die einzelnen GOPs sind wahrscheinlich zu klein um sie sinnvoll ohne zuviel Verwaltungs-Overhead zu sharen. Deshalb haben die evtl. 120 GOPs ( ~ 1 Minute) zusammengefasst als kleinste Einheit.
Sehr interessantes Projekt.
Gruß
Jarny

Jedes Stück Sendung wird pro Sender (z.B. ARD) in Blöcke von gut einer Minute zerlegt. Weil die Uhren der Rechner nicht exakt übereinstimmen, sind diese Blöcke unterschiedlich. Jeder Block wird nun in GOPs zerlegt (i.a. 120) zu denen ein Hash berechnet wird. Die Liste der Hash-Werte wird im Peer-to-Peer System veröffentlicht. Dabei wird zu jedem Hash-Block auch eine kurze Liste einiger Rechner angelegt, die diese GOP besitzen (Stichwort Aggregation). Weil die Uhren, wie gesagt, nicht synchron sind, wird dabei auch immer eine Anpassung der Hash-Listen vorgenommen (Stichwort: Matching und Merging). I.a. wird die Hash-Liste also länger. Anhand dieser Listen kann dann die entsprechende Sendeminute geladen werden. Dabei werden mehrere Threads gestartet, die jeweils aufeinanderfolgende GOPs laden. Jeder Thread beginnt mit GOPs die eine Minute Abstand haben. So muss nicht für jede GOP eine neue Verbindung begonnen werden. Hat eine Quelle einen besseren Upstream, ist der Thread früher fertig und kann mit dem nächsten offenen Stück GOPs beginnen. Auf diese Weise mitteln sich die verschiedenen Upstream-Bandbreiten heraus. Im Prinzip könnte aber jede GOP einzeln geladen werden. Wenn z.B. eine Quelle sehr langsam ist, könnte eine andere Quelle für diese GOP gewählt werden. Da aber alle GOPs über die Abfolge der Hash-Werte eindeutig zugeordnet werden können, ergibt sich stets eine identische Kopie des originalen Datenstroms so wie er urpsrünglich gesendet wurde. (Für alle die das jetzt im Quellcode nachvollziehen wollen das kleine Eingeständnis, dass das noch nicht 100% so implementiert ist. Es soll aber in Kürze umgestellt werden.)

Willkommen im Forum und danke für die Erleuterungen.

Ich geh mal davon aus, dass du ein Projektmitarbeiter bist. Jedenfalls wünsch ich euch viel Erfolg mit dem Projekt. Ich hoffe ihr habt auch die rechtliche Seite abgeklärt. Würde mich freuen, wenn VIDEGOR populär würde. Ohne Popularität nutzt einem eine Sharing-Plattform nicht viel.
Gruß
Jarny

thomasfuhrmann
kendykutzner

Ahh, der Entwicklungschef und der Erfinder von IGOR persönlich...

Herzlich Willkommen auch vion mir :welcome, jetzt ist es mit der Ruhe vorbei... (aber bitte nicht weglaufen)

Da kann ich ja direkt ein paar Fragen loswerden:

Wie werden die Sender Identifiziert (Name ? PID ?)

Welche Ports werden für die Kommunikation genutzt ?

"Pingt" sich jeder Client seinen weg durch die Firewall oder müssen bestimmte Ports bei NAT geforwardet werden ?

Wie funktioniert das erste Finden eines anderen Clients ?

In welcher Größenordnung ist das ganze schon in Betrieb (Wohnheim scheint mir ein gutes High-Speed Testumfeld aber was ist mit DSL ?) ?

Kleiner Tip: Wenn Ihr ein Patch für LINVDR 7.0 erstellt (oder Cody bei der Erstellung helft) wird die Anzahl der Nutzer (Tester) schnell in die 100e gehen....:welcome

Ups, so schnell kann ich die vielen Fragen gar nicht beantworten. Ich versuche es mal:

1. Bei den rechtlichen Aspekten gilt wie immer in der Juristerei, es kommt auf den Einzelfall an. Bis zur ersten Abmahnung stehe ich aber auf dem Standpunkt, dass Videgor von Paragraph 44a Urheberrechtsgesetz gedeckt ist. Man kann eben nur das anschauen, was man auch hätte selbst aufnehmen können. Wenn die erste Abmahnung kommt, können wir ja Geld sammeln für einen Musterprozess.

2. Das eigentliche Peer-to-Peer-System ist der IGOR. Beim Starten gibt man einen Bootstrap-Rechner an. Momentan ist das ein Rechner hier bei uns (siehe Installationsanleitung). Das kann aber jeder IGOR Rechner sein, so dass wirklich eng begrenzte Netze entstehen können, z.B. im Wohnheim.

3. Für den IGOR gibt man auch die Ports an, die verwendet werden sollen. Wenn man von außen erreichbar sein will, muss der Netz-Port vom NAT-Gateway an den IGOR-Rechner weitergeleitet werden. Wenn der VDR innerhalb des privaten Netzes läuft muss der Client-Port nicht freigeschaltet werden. Wenn man ein privates IGOR-Netz will, schaltet man den Netz-Port auf der Firewall zu.

4. Die Übertragung der Videodaten ist getrennt von IGOR. Auch dafür müssen NAT und Firewall offen sein. Hier eine gute Lösung zu implementieren ist gerade in Arbeit. Momentan geht's also nur wenn die NAT-Box auch für den Videotransport geöffnet wird.

5. Eine LinVDR-Version wäre prima. Bis dahin wird es aber noch eine ganze Menge Bugs zu finden geben. Auch die NAT-Problematik sollte bis dahin gelöst sein. Wir freuen uns auf jeden Fall über tatkräftige Unterstützung beim Suchen der Bugs!

A propos: Wir haben ein zweites Projekt, das in wenigen Wochen Online gehen wird und das sich mit der Frage der Vernetzung von privaten Subnetzen befasst. Damit kann man dann einzelne W-LAN-Netze verbinden, so dass die Videorekorder gar nicht mehr durch den DSL-Anschluss durch müssen.

zu 5.:

ich denke das sich die LinVDR Nutzer auch jetzt schon über ein nicht ganz Bug freies Plugin freuen würden (auch andere Plugins haben noch hier und da ein paar Macken) ;-).
Außerdem würde das die Testergemeine gewalltig vergrößern. (ich würde es testen!)