[vdr] [ANNOUNCE] videgor-0.0.3

Hey,

1. dvdrvidtrans geht hier immer noch nicht, hat einer Tip`s? :

make[1]: Entering directory `/usr/local/src/vdr-1.3.37dvdrtest/PLUGINS/src/dvdrvidtrans-0.1.1'
g++ -g -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvdrvidtrans"' -I../../.. -I/usr/local/src/DVB/include dvdrvidtrans.c
dvdrvidtrans.c: In member function `void
vdrrecordings::processsnippetlist(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >)':
dvdrvidtrans.c:1403: warning: unused variable `char currentsnippet[4096]'
dvdrvidtrans.c: In member function `int vdrrecordings::startsending(unsigned
int, unsigned int, unsigned int, fileandpos*)':
dvdrvidtrans.c:1104: warning: `int vidfp' might be used uninitialized in this
function
dvdrvidtrans.c: In member function `virtual void
serverthread::csubserverthread::Action()':
dvdrvidtrans.c:1562: warning: `ssize_t justsent' might be used uninitialized in
this function
dvdrvidtrans.c: In member function `int
vdrrecordings::done(std::basic_string<char, std::char_traits<char>,
std::allocator<char> >, int)':
dvdrvidtrans.c:748: warning: `cRecording*rec' might be used uninitialized in
this function
dvdrvidtrans.c: In member function `int
vdrrecordings::cut(std::basic_string<char, std::char_traits<char>,
std::allocator<char> >)':
dvdrvidtrans.c:1249: warning: `uint32_t wheretocut' might be used uninitialized
in this function
g++ -g -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvdrvidtrans"' -I../../.. -I/usr/local/src/DVB/include parsefile.c
g++ -g -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvdrvidtrans"' -I../../.. -I/usr/local/src/DVB/include findhash.c
g++ -g -O2 -Wall -Woverloaded-virtual -shared dvdrvidtrans.o parsefile.o findhash.o -ligor -o libvdr-dvdrvidtrans.so
make[1]: Leaving directory `/usr/local/src/vdr-1.3.37dvdrtest/PLUGINS/src/dvdrvidtrans-0.1.1'

2. dvdrepg, warning MAINMENUENTRY , macht das was aus? :
make[1]: Entering directory `/usr/local/src/vdr-1.3.37dvdrtest/PLUGINS/src/dvdrepg-0.8.0'
g++ -g -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvdrepg"' -I../../.. -I/usr/local/src/DVB/include dvdrepg.cpp
g++ -g -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvdrepg"' -I../../.. -I/usr/local/src/DVB/include controller.cpp
g++ -g -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvdrepg"' -I../../.. -I/usr/local/src/DVB/include epgigor_interface.cpp
g++ -g -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvdrepg"' -I../../.. -I/usr/local/src/DVB/include vdrepg_interface.cpp
g++ -g -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvdrepg"' -I../../.. -I/usr/local/src/DVB/include osdmenu_dvdrepg.cpp
osdmenu_dvdrepg.h:32: warning: `const char*MAINMENUENTRY' defined but not used
g++ -g -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvdrepg"' -I../../.. -I/usr/local/src/DVB/include epgtypes.cpp
g++ -g -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvdrepg"' -I../../.. -I/usr/local/src/DVB/include blockentry.cpp
g++ -g -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvdrepg"' -I../../.. -I/usr/local/src/DVB/include kv_parsing.cpp
g++ -g -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvdrepg"' -I../../.. -I/usr/local/src/DVB/include misc.cpp
g++ -g -O2 -Wall -Woverloaded-virtual -shared -ligor dvdrepg.o controller.o epgigor_interface.o vdrepg_interface.o osdmenu_dvdrepg.o epgtypes.o blockentry.o kv_parsing.o misc.o -o libvdr-dvdrepg.so
make[1]: Leaving directory `/usr/local/src/vdr-1.3.37dvdrtest/PLUGINS/src/dvdrepg-0.8.0'

gcc version 3.3.4 (pre 3.3.5 20040809)

also ich hab hier nur dsl
zwar 1500 aber ich glaube before hier nicht effektive komprimiert wird, lohnt sich der spass nicht !

wieso willst du komprimieren ? das wäre doch viel zu aufwendig .... deshalb ist igor ja ein p2p client. Damit man sich die einzelnen Teile von mehreren Systemen runterladen kann. Dadurch wird es dann schnell. Aber wenn keiner mitmacht, dann bleibt es natürlich langsam.

bis denn
jabba

ähmm ja ganz einfach weil z.b. ne halbe stunde serie gleich 1,5 gb gross sind (is jetzt geschätzt dürfte aber hinkommen)

naja, aber dann wird das ganz schön kompliziert. auf jedem client system muß dann die aufnahme komprimiert werden, damit dann teile davon übers netz übertragen werden können, am zielsystem muß das ganze dann wieder zusammengesetzt werden und dann wieder dekomprimiert werden, damit der vdr das wieder ohne zusatzplugin abspielen kann.
Ich seh darin eigentlich nicht die aufgabe des dvdrtrans plugins sondern dann eher am vdr direkt, daß der alles in einem anderen Format abspeichert.
und wenn ich bedenke wielange ich daran sitzen würde nur einen Serienteil zu konvertieren nach divx oder so, dann lad ich lieber ein paar stunden länger. Die Belastung wäre mir dann für mein System zu groß.

bis denn
jabba

ps. deutsche Sprache schwere Sprache

Hi Jabba,

ob das so kompliziert ist weiß ich nicht. Bei deinem Ansatz sicherlich schon, aber was wäre, wenn man die einzelnen Schnipsel komprimiert??

Ich kenne mich mit dem Kram nicht wirklich aus, sondern hab' mein Wissen mehr hier aus dem Forum.

Jedoch werden die Filme doch in einzelne Schnipsel unterteilt (hießen die GOPs?). Wenn man nun jedes Schnipsel komprimiert (wenn das überhaupt noch möglich ist) und vor dem zusammensetzen wieder dekomprimiert hätte man vielleicht schon was gewonnen. Wie gesagt ich rede hier von Komprimieren mit RAR, ZIP, etc. und nicht transkodieren a la DivX, etc.

Da ich aber nicht weiß, wie groß die Schnipsel sind, noch wie 'komprimierungsfähig' diese Schnipsel sind, wäre hier jetzt jemand anderes gefragt.

Grüße,
McMorning

man kann die daten auch on the fly komprimieren. in java gibt es z.b. gzip streams mit denen man daten on the fly komprimieren kann. emule komprimiert daten z.b. auch. und so doof fänd ich die idee eigentlich auch nicht. mpeg2 ist schließlich nicht das mass aller dinge.

Hi, video daten, auch mpeg2, sind ja schon in einer weise komprimiert, vorgegeben durch den MPEG2 Standard.
Ein weiteres komprimieren der Videodatei mit irgendeinem Verfahren bringt höchstens
minimale Verkleinerung. Die liegt so bei ca. 2%. Und 2% von 2GB sind nicht wirklich viel, die man dadurch vielleicht sparen würde. Und je kleiner so einer Schnipsel ist, umso größer Schlagen dann overhead durch Komprimierungszusatzinformationen und Protokoll zu buche.
Also würde der ansatz mit vorher die Schnipsel komprimieren nichts bringen.
Endweder du konvertierst das Video in ein anderes Format oder du behälst die größe bei und erhöhst die Geschwindigkeit des P2P Netzes durch genügend Redundante Aufnahmen.

bis denn
Jabba

ps. anders würde das natürlich bei EPG daten aussehen. Die könnte man vorher oder onthefly komprimieren und hätte dadurch weniger zu übertragen. Komprimieren bringt viel bei Texten, PDF, PS, teilweise auch Programmen, aber bei Bildern z.B. JPG, PNG bringt es nicht mehr viel, da daß schon komprimierungsformate sind, genau wie divx,mpg usw

pps. ich muß echt wieder mehr auf meine Rechtschreibung achten

MPEG-Video lässt sich so gut wie nicht verlustlos komprimieren, gzip & Co fallen also aus.

MPEG2-Transcoding, wie man es von DVD-Kopierern kennt (die sog. Compressed Domain Transcoder), liefern abhängig von der Bitrate schon bei geringer Rekompression starke Artefakte. Und da DVB-S ja schon teilweise mit nur noch 2,8 MBit/s übertragen wird und das Bild dann schon schrecklich ist, wird das recht schnell richtig übel, wenn´s noch weiter komprimiert wird.
Einzige Alternativen für eine Rekompression wären z.B. MPEG-4-ASP (=DivX, XviD), da kann man´s vielleicht um 50% komprimieren, bis es deutlich schlechter wird. MPEG-4-AVC (=H.264) dürfte am effektivsten sein und das Quellmaterial halbieren.

Aber dennoch: Es ist ein Verlust, die Kompression zeitaufwändig, und wenn dann die Tools nicht die beste Qualität liefern oder im falschen Farbraum arbeiten (Stichwort: Farbsprünge), dann ist es vielleicht besser, wenn man sich dann wirklich "alternativer" P2P-Quellen bedient. Man braucht sich nur den einen oder anderen DivX anschauen, bei dem der Kodierer nicht gewusst hat, dass Fernsehen interlaced übertragen wird, oder der jede zweite Zeile einfach gelöscht oder einen billigen Deinterlacer genommen hat.
Mir ist es daher ehrlich gesagt lieber, wenn´s in Originalqualität bleibt. Klar, der Download dauert wirklich lange, wenn es zu wenige Quellen gibt, und 192 kBit/s-256 kBit/s Upstream scheinen leider (noch) der DSL-Standard zu sein. Aber wenn sich Igor weiter verbreitet hat, dann kann es wirklich eine interessante Sache werden.

Vielleicht wäre es für den Anfang nicht schlecht, wenn man die Qualität auswählen könnte. So könnten User mit einer dicken Internet-Leitung einstellen, dass sie generell nur unkomprimiertes Material empfangen wollen. Optimal wäre eine progressive Lösung: Je mehr gedownloaded wird, umso besser wird die Qualität. Aber dass lässt sich wohl nicht mit MPEG2 machen, es sei denn, man kodiert den Film zwei Mal und konfiguriert: Lade es mir in 2 Stufen herunter, zunächst in schlechter, dann in bester Qualität. Die Sendung ist früher da, und wenn man sie auf DVD archivieren will, wartet man einfach länger...

Jörg

edit: oops, da war einer schneller

sorry nächstes mal laß ich Dir den Vorrang... Hast es ja deutlich genauer als ich bschrieben

mal ne frage, hat das schon wer im einsatz in einem hausnetz??? so von wegen 3VDR's mit je einer Karte und die anderen nichtgenutzten VDR's übernehmen die aufnahme und sperren damit nicht die einzige karte im wohnzimmer VDR???

Oder sit das nicht möglich, dachte dies aus dem c't beitrag gelesen zu haben...

Zitat

Original von linuxdep
mal ne frage, hat das schon wer im einsatz in einem hausnetz???

leider noch nicht, scheiter ja immer noch am dvdrvidtrans, siehe oben

HI,

Zitat

Original von linuxdep
mal ne frage, hat das schon wer im einsatz in einem hausnetz??? so von wegen 3VDR's mit je einer Karte und die anderen nichtgenutzten VDR's übernehmen die aufnahme und sperren damit nicht die einzige karte im wohnzimmer VDR???

ähhhh, das geht doch schon auch so mit plain-vanilla-VDR ohne Probleme. Zumindestens mach ich das so, der VDR-Server im Keller versorgt den rest und vice versa. Wo soll das Problem sein, oder verstehe ich da etwas nicht?

cu,
BC

Also irgendwie bekomme ich keine Verbindung mit igor hin
in dem logfile steht folgendes

1134160517.622526 NODE5:node_init
1134160517.623728 CONN5:connection with fd 4 changed state from EMPTY to LISTEN
1134160517.625330 CONN5:connection with fd 5 changed state from EMPTY to LISTEN
1134160517.627101 NODE5:bootstrap in progress
1134160517.627130 CONN4:try connecting to host vdr.ira.uka.de and port 11073
1134160517.715170 CONN5:connection with fd 6 changed state from EMPTY to OPENING
1134160517.717099 NODE5:node_init_done; ref: (90c9b2c4da4fefda0f28a0fa1e3fe9bdfe4abb2c t2x.dyndns.org:11073), net_listen: t2x.dyndns.org:11073, client_listen: t2x.dyndns.org:11072
1134160517.717139 DFLT5:back to main, starting main loop
1134160517.768872 CONN5:connection with fd 6 changed state from OPENING to READY
1134160517.769108 CONN5:write to fd 6 returned Connection refused, closing connection
1134160517.769321 NODE5:closing connection with cbhandle 3 and wcbhandle 0
1134160517.769386 CONN5:connection with fd 6 changed state from READY to CLOSED
1134160517.769402 CONN5:the just closed connection (fd 6) sent 0 bytes in 1 messages and received 0 bytes in 0 messages. 0/141 bytes are left for recv/send
1134160517.819778 NODE3:no connection left, exiting now
1134160517.819804 NODE5:shutting down node
1134160517.819812 NODE5:dumping connection table
1134160517.819820 NODE5:dumping connection table finished
1134160517.819854 CONN5:connection with fd 4 changed state from LISTEN to CLOSED
1134160517.819867 CONN5:the just closed connection (fd 4) sent 0 bytes in 0 messages and received 0 bytes in 0 messages. 0/0 bytes are left for recv/send
1134160517.819898 CONN5:connection with fd 5 changed state from LISTEN to CLOSED
1134160517.819912 CONN5:the just closed connection (fd 5) sent 0 bytes in 0 messages and received 0 bytes in 0 messages. 0/0 bytes are left for recv/send
1134160517.819926 NODE5:node shutdown complete
1134160517.819934 NODE5:NODE stat: Sent 0 bytes in 1 messages; Received 0 bytes in 0 messages; Used 1 connections
1134160517.819948  CBL3:nothing found in callbacklist, returning 0
1134160517.819958  CBL5:CBL statistics: average fds found 1.666667, average timers found 2.000000, average mintimer val 0.075492

Ich hab so das gefuehl, dass liegt an meinem fqdn namen. Da hab ich mir noch nie wirklich gedanken darueber gemacht.
wenn ich dydns.org verwende was muss ich denn dann als domainname eintragen? t2x.dyndns.org oder was anderes.
Mein Rechnername ist dann auch nochmal T2x.
Was kommt dann in die /etc/hosts ???

Vielen Dank
t2x

Zitat

Original von Django
HI,

ähhhh, das geht doch schon auch so mit plain-vanilla-VDR ohne Probleme. Zumindestens mach ich das so, der VDR-Server im Keller versorgt den rest und vice versa. Wo soll das Problem sein, oder verstehe ich da etwas nicht?

cu,
BC

Hallo Django,

diese Funktion fände ich evtl. sinnvoll:
"D-VDR-VIDEOTRANS überträgt Aufzeichnungen zwischen den Videorekordern".
Einfach Aufnahme(n) anwählen, mit FB, und schwupps auf einen anderen vdr kopieren/verschieben.

Nur mit genau dem plugin habe ich ja noch Probs und so wie es aussieht, lohnt sich wohl der ganze Aufwand/ Overhead für mich nicht um beim jetzigen Stand weiter zu probieren/testen.

Hatte mit auch mehr drunter vorgestellt, da ich aber keine Screenshots gefunden hatte, war es mir halt mal ein kleiner Versuch wert.

PS: Gibt es eigentlich schon die Möglichkeit einen vdr bei gleicher Bedienung komplett fernzusteuern?
Sprich im Menü baut man sich eine Auswahl: vdr-lokal,vdr2,vdr3, etc.
Nachdem man darauf wechselt, bedient man den entspr. vdr und bekommt natürlich auch das Bild von diesem?

Habedieehre!

Zitat

Original von celica
diese Funktion fände ich evtl. sinnvoll:
"D-VDR-VIDEOTRANS überträgt Aufzeichnungen zwischen den Videorekordern".
Einfach Aufnahme(n) anwählen, mit FB, und schwupps ...

... ankucken. Also wenn ich auf meinem "kleinen" TecVDR die Aufnahmen mir auswähle, dann sehe ich zum einen die lokalen Aufzeichnung auf dessen Platte, oder auch die anderen Aufzeichnungen, die auf dem Server liegen. Brauche nix- hin oder herkopieren, nur einfach die OK oder die Taste ROT drücken, das wars.

Pfiade,
BC

Hallo,

ich finde das Thema höchst interessant (und äußerst brisant -;)

leider bekomme ich dvdrsched nicht unter 1.3.37 übersetzt. Sowohl mit BP als auch mit minimalem VDR gibts folgenden Abbruch. VDR ist einwandfrei gepatcht

Zitat

make[1]: Entering directory `/usr/local/src/vdr-1.3.37-test/PLUGINS/src/dvdrsched-0.0.1'
g++ -Wall -Woverloaded-virtual -g -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvdrsched"' -DDEBUGSCHED -I../../.. -I../../../../DVB/include threads.cpp
threads.cpp: In member function ‘void cMainThread::handle_suppress(const cSchedMsgSuppress&)’:
threads.cpp:162: error: ‘log2’ was not declared in this scope
threads.cpp: In member function ‘void cMainThread::handle_timer(std::list<timer, std::allocator<timer> >)’:
threads.cpp:268: error: ‘log’ was not declared in this scope
make[1]: *** [threads.o] Fehler 1
make[1]: Leaving directory `/usr/local/src/vdr-1.3.37-test/PLUGINS/src/dvdrsched-0.0.1'

Alles anzeigen

Distri: SuSE 10, cvs-dvb-kernel

Gruß bacman

Ich frage mich wie das funktionieren soll. Wenn ich was aufnehme und wer anders wills sehen, kann ers beim ersten mal nur von mir alleine ziehen - wie soll das von anderen gehen? Woher will der Client wissen, wo er anfangen soll? Nicht bei jedem geht die Aufnahme genau beim gleichen Frame los und läuft auch exakt so lange - also könnte man Aufnahmen keine eindeutige MD5sum oder sonstwas zu ordnen.

Die Technik die hinter dem Projekt steckt wurde hier <klick> auf Seite 2 erklärt.
Gruß
Jarny