Posts by geronimo

Quote

Nicht nur in Deutschland, sondern weltweit ;-).
Für mich (und vermutlich auch viele Plugin-Entwickler) wäre das sicherlich eine zusätzliche Motivation...

Wenn es wirklich um Motivation geht ...

... das sollte auch ohne heimfunken möglich sein.

Dazu müsstest Du nur mal den VDR mit anderen alten Naiven vergleichen und diesmal die Frage stellen: "was können andere, was der VDR nicht kann?"

Die beiden (für mich) wichtigsten:
- jede Box bietet einen Webserver, mit dem der Recorder eingestellt und gewartet werden kann. YaVDR macht es richtig, aber VDR nativ? Fehlanzeige!
- Fremde Aufnahmen - für den VDR gibt es keine fremden Aufnahmen. Er ist sich selbst genug.

Wenn ich an aktuelle Smart-TVs denke, da reicht eine USB-Platte zum Anstöpseln und ohne irgendwelche Installations- oder Konfigurations-Orgien kann ich alles abspielen, was auf Platte ist. Völlig Banane, wer es wann aufgezeichnet hat, ob es ein mkv oder ts oder mpeg ist, ob es ein Rip einer gekauften Scheibe ist, oder Bilder von einer Digikam, oder gar eine Aufnahme vom VDR ...

Es gäbe reichlich Möglichkeiten, den VDR und so die Akzeptanz zu verbessern. Mann müsste es nur wollen

Quote

Ich denke da einfach erst mal nur die nächste Iteration des Problems mit der gleichen Hardware, vermutlich der gleichen schlechten Empfangssituation auf einem der beiden Tuner bei bestimmten Transpondern und wieder Aufnahmen mit Störungen.

Meinst Du nicht, dass die Probleme, wenn es denn mit der HW zusammenhinge, im letzten Jahr auch hätten auftreten müssen?
Es gab mehrfach gleichzeitige Timer auf unterschiedlichen Transpondern, aber ich hatte nicht eine defekte Aufnahme.

Quote

..., kann ich da nur ein hausgemachtes Problem oder Fehlbedienung vermuten.

Ja klar!

Es geht ja nicht mal ums Abspielen, xbmc zeigt die Dateien ja nicht mal an.
Völlig egal, ob ich über Video einsteige und neues Medium zufügen auswähle, oder ob ich über System und den Dateimanager einsteige ...
xbmc zeigt keine der Video-Dateien an.
Alle Dateien sind Besitzer vdr.video und welt-lesbar.
MPlayer-Plugin auf die gleichen Dateien losgelassen, zeigt alle Dateien an und spielt sie auch ab.

Aber klar, da ich keine Ahnung von xbmc habe, muss es ja meine Dummheit sein.

Ist in Ordnung! Offensichtlich war noVDR doch nicht die richtige Wahl.

Gruß Gero

Quote from gda

Ist schon eine Weile her, dass ich das mal erklärt habe.

Ok, merci - ist angekommen!

Quote from seahawk1986

Bevor du jetzt wieder mit der alten Leier ...

Weiß nicht, wie Du auf das schmale Brett kommst.
Ich verwende zwar die gleiche Kiste, aber yaVDR ist bei mir eine standalone-Installation - also so, wie vermutlich bei den meisten Anwendern.
Spezial ist da garnix - außer vielleicht, dass ich Filme habe, die nicht vom VDR stammen - aber ich schätze mal, da dürfte es sicher den einen oder anderen geben, bei dem das auch zutrifft.

Übrigens: egal, was ich auch mit xbmc anstelle - es zeigt keine der Filme an.
Jetzt habe ich das mplayer-Plugin installiert und damit kann ich alle abspielen. Ob ich später wieder Ton-(versatz)Probleme bekomme, kann ich derzeit noch nicht testen. Vielleicht nächstes WE.

Gruß Gero

Quote from gda

Upps, worauf zielst du da ab? Der Vergleich hiermit passt mir nicht.

Ok, da gebe ich Dir Recht.

Wie Wikipedia schon herausstellt, wird Propaganda eher politisch verwendet. In anderen Bereichen würde man von Werbung sprechen.
Allerdings denke ich, dass bei Werbung die Diskrepanz zwischen Aussage und Wirklichkeit nicht jedem so bewusst ist, wie bei Propaganda.
Wenn ich also den Aspekt der Divergenz zwischen Aussage und Wirklichkeit herausstellen will, verwende ich gerne das Wort Propaganda - auch im nicht politischen Kontext.

Wobei ich nicht davon ausgehe, dass diese Divergenz bei Euch beabsichtigt und/oder gewollt ist. Sie ist einfach hyseterisch gewachsen. Ist ja schon ein paar Tage her, dass 0.5 freigegeben wurde.

Ich hatte angenommen, dass Du für QS-Fragen bei yaVDR zuständig wärst - aber vielleicht steht hinter der Position ja auch ein n.n. ...

Ferner habe ich mir vorgestellt, wie es wäre, wenn ich weder von Linux noch von VDR eine Ahnung gehabt hätte und den Einstieg nur mit den von Euch veröffentlichten Daten hätte bewerkstelligen sollen. Da hätte ich extrem alt ausgesehen.
Die Online-Hilfe ist ja erst erreichbar, nach erfolgreicher Installation - und wie man zu der Hilfe kommt, ist auch nicht so offensichtlich.
Ich finde, ein nicht bedienbarer Rechner nach der Installation, ist so ziemlich der Supergau für einen Einsteiger.
Eine normale Reaktion dürfte sein: so ein Scheiß - da tut ja garnix - und geht wieder zurück zu Windows.
Nur die Hartnäckigen landen irgendwann hier im Forum.

... aber vielleicht soll yaVDR auch keine Distribution mehr für Einsteiger sein?

//update:
Inzwischen habe ich erste Stresstests durchgeführt. Ich habe 3 DVB-C Karten, 2 Budget, eine FF und kann 3 HD-Sender empfangen: das Erste HD, zdf HD und Servus ...
2 HD-Aufnahmen gleichzeitig sollte also kein Thema sein (so zumindest die Theorie).

test1 und test2 sind mit den Einstellungen aufgenommen, wie yaVDR nach der Installation (incl. dist-upgrade) hochkommt.
Die Timer habe ich jeweils manuell gesetzt und zwar so, dass sie immer bei runden 15 Minuten anfangen und weitere 15 Minuten später aufhören.
Bei test1 war Timer1 für "das Erste HD" gesetzt, Timer2 für "zdf HD" und life-Bild lief auf Servus
Die passenden Syslogs im Anhang.
Wie man schon von den Zeiten ablesen kann, ist die erste Aufnahme OK, die zweite Aufnahme Schrott. Im Syslog gibt es keine Fehlermeldungen (außer von markad).

Nach dem ersten Durchlauf habe ich die Datei /etc/vdr/plugin.dvbsddevice.conf erzeugt, mit dem Inhalt: --outputonly

Anschließend den vdr angehalten und neu gestartet.
Jetzt habe ich den Test xx durchgeführt und diesmal zuerst einen Timer für das "zdf HD" erstellt und Timer2 für "das Erste HD" - life-TV war wieder Servus
Gleiches Ergebnis wie bei der ersten Runde, die Option --outputonly hat also keinerlei Verbesserung gebracht.

Nach dieser Runde habe ich in /etc/default/vdr die Optionen so angepasst, wie sie damals für mich passten:
OPTIONS="-w 60 -l 3"

Erneut den vdr angehalten und neu gestartet.
Diesmal war Timer1 für Servus, Timer2 für zdf HD und life-TV lief auf dem ersten.
Bei diesem Test waren beide Aufnahmen OK, d.h. Probleme an der Hardware können somit ausgeschlossen werden. Zumal in beiden ersten Runden zdf Schrott war und dieses Mal zdf in Ordnung war.

Leider hat die Änderung des Log-Levels keine Änderung im syslog gebracht. Alle 3 Syslogs sind fast identisch. Welchen Sinn haben dann noch unterschiedliche Loglevels?

In allen 3 Runden wurde aus dem Life-TV ein Standbild, als die Aufnahmen anfingen. Nach Beendigung der Aufnahmen kam das Life-TV nicht mehr selbstständig zum Laufen. Auch die Aktivierung des Menüs brachte keine Änderung. Ich musste erst den Sender wechseln, bevor wieder ein Life-Bild kam.

Hm ...

Gruß Gero

Quote from seahawk1986

Das hat aber eine andere Ursache.

Das ist mir klar!
Inzwischen habe ich die ganze Online-Hilfe gelesen.

... by the way: möchtest Du Rückmeldungen zur Online-Hilfe hier im Forum oder per emaille haben?

Quote

Ansonsten gebe ich dir vollkommen recht, dass die Seite mal wieder eine Auffrischung vertragen könnte, das ist bei einem Hobbyprojekt halt immer die Frage, wie die Leute im Team sich einbringen und welche Prioritäten sie dabei setzen.

Schon klar.

Nur um es ganz klar herauszustellen: ich habe mit dem Status Quo überhaupt kein Problem. Ich kann mir in den meisten Fällen selbst helfen.

Ich empfand nur eine Diskrepanz zwischen der Propaganda auf yaVDR.org und dem Verhalten bei der Installation.
Ich bin davon ausgegangen, dass Euch der Status Quo vielleicht garnicht bewusst ist. Deshalb das Feedback.

Wenn alles bekannt und gewollt ist, dann könnt Ihr diesen Fred auch einfach wieder löschen.

Quote from gda

Natürlich muss ich das so einschränken.

Müssen musst Du garnichts

Die Frage ist doch garnicht, ob ein bestimmter Empfänger unterstützt wird oder nicht, sondern ob die Tastatur noch unterstützt werden soll.
Ich denke, bei einer Neuinstallation wird an jedem Rechner eine Tastatur hängen. Der Fernbedienungsmodus wird erst aktiviert, wenn alles andere tut.
So würde zumindest ich es machen ...

//Edith:
Was das mögliche Einbinden einer Videoplatte angeht, habe ich mal ein kleines Script geschrieben. Das ermittelt alle Platten, die noch nicht in der fstab verwendet wurden. Platten, die Teil eines Raid-Verbundes sind werden ignoriert. Auf diese Weise sollte es ohne Konflike möglich sein, die fstab um einen entsprechenden Eintrag zu erweitern.

Ich habe das Script auf einem Rechner mit Raid-Verbund getestet. Es gab nur eine (von 15) Partitionen, die nicht in der fstab war und die ein Label hatte.
Im genialen Configurations-Menü könnte angeboten werden, ob die Platte per uuid oder per label eingebunden werden soll.
Werden mehrere freie Partitionen gefunden, könnte ja video.00 video.01 video.02 etc belegt werden.

Hier das Script:

#!/usr/bin/perl
use strict;
my %drives;


sub readPartitions {
  my $sysInfo = '/proc/partitions';
  my $fp;
  my $major;
  my $minor;
  my $size;
  my $name;




  if (open($fp, $sysInfo)) {
     while (my $line = <$fp> ) {
           if ($line =~ /\s+(\d+)\s+(\d+)\s+(\d+)\s+([a-zA-Z0-9]*)/) {
              $major = $1;
              $minor = $2;
              $size  = $3;
              $name  = $4;


              $drives{$name} = { name => $name,
                                 major => $major,
                                 minor => $minor,
                                 size => $size };
              if ($name =~ /([a-zA-Z]+)\d+/) {
                 my $parent = $1;


                 $drives{$name}{ parent => $drives{$parent}} if exists($drives{$parent});
                 }
              }
           }
     close($fp);
     }
}


sub readUUIDs {
  my $sysInfo = '/dev/disk/by-uuid';
  my $dir;


  if (opendir($dir, $sysInfo)) {
     while (my $entry = readdir($dir)) {
           next if $entry =~ /^\.\.?$/;
           my $target = readlink($sysInfo.'/'.$entry);


           $target =~ s/\.+\///g;
#           print('entry: '.$entry.' => '.$target."\n");
           $drives{$target}{uuid} = $entry if exists $drives{$target};
           }
     closedir($dir);
     }
}


sub readLabels {
  my $sysInfo = '/dev/disk/by-label';
  my $dir;


  if (opendir($dir, $sysInfo)) {
     while (my $entry = readdir($dir)) {
           next if $entry =~ /^\.\.?$/;
           my $target = readlink($sysInfo.'/'.$entry);


           $target =~ s/\.+\///g;
#           print('entry: '.$entry.' => '.$target."\n");
           $drives{$target}{label} = $entry if exists $drives{$target};
           }
     }
}


sub cleanup {
  my @keys = sort(keys(%drives));


  foreach my $key (@keys) {
          if ($drives{$key}{uuid} =~ /^$/ && $drives{$key}{label} =~ /^$/) {
             delete $drives{$key};
             }
          else {
             if (open(my $fp, 'grep \''.$drives{$key}{uuid}.'\' /etc/fstab |')) {
                my $chk = <$fp>;


                delete $drives{$key} if not $chk =~ /^$/;
                close($fp);
                }
             }
          }
}


sub tellPartitions {
  my @keys = sort(keys(%drives));




  foreach my $key (@keys) {
          print('drive '.$key.':');
          print("\t".$drives{$key}{major}.'/'.$drives{$key}{minor}.' - size: '.$drives{$key}{size}.' - uuid: '.$drives{$key}{uuid}.' - label: '.$drives{$key}{label}."\n");
          }
}


#
# main
#
readPartitions();
readUUIDs();
readLabels();
cleanup();
tellPartitions();

Somit wird nicht an der fstab rumgespielt und es kann trotzdem einen gewissen Kommford für den Entbenutzer geben

Gruß Gero

Moin moin,

Quote

Doch XBMC kann lokale Dateien abspielen (das geht im Datei-Modus).

Ok, ich dachte, ich wäre im Dateimodus gewesen. War auch nur ein Schnellcheck.
Werde es also nomml probieren

Quote

Sehe ich genauso und das haben wir ja auch erreicht mit allen Fernbedienungen und Empfängern die wir eingesetzt haben.

Ok, wenn Du das so einschränkst ...

Ich hatte mich hier orientiert.
Unter "First boot" sind Bildschirmfotos abgebildet. Meine Kiste blieb auf Bildschirm Nr. 2 stehen, der als "bitte warten" bezeichnet wird.

Unter "First steps" steht beispielsweise, dass wenn man keine Fernbedienung hat, bzw. die noch nicht duht, dass dann die Taste 'm' das Menü bringen würde. Das war bei mir nicht der Fall.
Ist also für mich die Frage: wird die Tastatur von yaVDR nicht mehr unterstützt (dann sollte man die Seite vielleicht anpassen), oder ist bei meiner Installation was schief gegangen.

//Edith:
habe gerade eine neue Installation in einer Virtualbox probiert - mit neu aufgesetzter VM, also ohne Altlasten .....
Resultat ist fast identisch. Unterschied: das Pausenbild blitzt nur kurz auf, danach bleibt der Bildschirm schwarz.
Es geht weder 'm' noch eine Taste des Ziffernblockes ...
Scheinbar passt die Tutorial-Seite von yaVDR.org nicht mehr zur aktuellen Installation.

Gruß Gero

Hallo zusammen,

Quote

Nimm softhddevice

Yepp, ist bei yavdr als default aktiv - habbich also im Einsatz.
Ich schrieb ja schon von den Unterschieden, die mir aufgefallen waren.

Bislang hatte ich ja am Backend ausschließlich Bild über die ff-Karte gehabt.
xineliboutput lief auf dem Server, auf dem Client sxfe (selbst übersetzt) - für mich die perfekte Lösung.

Die jetzige Installation ist das erste Mal, dass ich einen standalone HD-VDR aufsetze.

Quote

Da liegt Dein Problem mit der Tastenbelegung, Du hast die remote.conf überschrieben.

Nö - Du solltest meinen Beitrag nochmal lesen.
Das war nicht das Problem, sondern meine Lösung.
Auch wenn die nicht yaVDR konform ist, hattes damit auf jeden Fall gefunzt.

Quote

Die remote.conf ist von uns so vorgegeben, dass sie zu den vorkonfigurierten Fernbedienungen (die alle über eventlircd ihre Tastendrücke an den VDR weiterreichen) passt.

Das macht ja auch Sinn - wollte ich nicht in Frage stellen.
Irgendwo las ich, dass die Taste 'm' für das Menü funktionieren sollte.
Bei mir tat überhaupt keine (mir bekannte) Taste, somit hatte ich wohl einen Stand, der nicht geplant war.
Keine Ahnung, was schief lief - ich wusste mir zu helfen, auch wenn es nicht yaVDR-konform war.

Quote

Das steht in der Doku und folgt weitgehend der mittlerweile für den VDR vorgeschlagenen Vorgabe:

Auch das ist in Ordnung. Ich finde nur, dass eine Neuinstallation ohne größeres Lesen der Doku klappen sollte. Wer dann Anpassungen machen möchte, der ist richtig an die Doku verwiesen. Eine Neuinstallation sollte - zumindest meiner Meinung nach - ohne Doku auskommen.

Quote

halte ich überhaupt nichts davon mit Skripten an der fstab herumzuspielen oder das Aufnahmeverzeichnis auf Wechseldatenträgern unterzubringen.

Hm, Ansichtssache.
Während einer Neuinstallation wird zwangsläufig eine fstab geschrieben. Die an gefundene und/oder erfragte Gegebenheiten anpassen ist kein rumspielen, sondern gehört zur Installation. Die originale fstab wird ja auch von Skripten o.ä. erzeugt.

... und ne Festplatte ist nicht deshalb ein Wechseldatenträger, weil sie in einem Wechselrahmen drinne steckt.

Quote

Ich weiß nicht, wie viel Erfahrung du mit XBMC hast, aber bei XBMC ist es prinzipiell so, dass man einen Scraper nutzt

Einmal ausprobiert und dann für mich festgestellt, dass ich xbmc nicht brauche - also keine!

Jetzt war ich bereit, einen neuen Versuch zu wagen, weil xbmc zu yaVDR gehört. Spricht ja erstmal nix dagegen.
Das mit dem Scraper ist etwas, was ich definitiv nicht will. Der VDR bekommt bei mir nur für System-Updates Internet-Zugang. Ansonsten ist der gesperrt.
Wenn also xbmc keine lokalen Dateien abspielen kann - dann brauche ich xbmc auch nicht.
Ist die Frage, ob ich dann bei yaVDR richtig bin?

Quote

Udn Thema Netz und Platte im Server: Ich hab inzwischen überall GBit im Haus und Transferraten von ca. 90 MB/s zwischen vdr und NAS, das ist mit internen Platten auch nciht viel anders.

So spricht jemand, der es nie nach gemessen hat.
Wenn Du mal nach älteren Beiträgen von mir suchst, habe ich viele Messungen zum Thema Datentransfer gemacht.
Bei einer Terabyte-Platte liegt der Zeitunterschied zwischen Gigabit-Netzwerk und lokalem Transfer fast bei einer Stunde.
Dafür kaufe ich mir gerne einen Wechselrahmen und betätige mich selbst als Datenträger.
Es bringt nix, die maximal mögliche Transferrate zu vergleichen.
Ich habe die Vergleiche ganz pragmatisch gemessen, indem ich den Transfer der ganzen Platte habe messen lassen.
Da ergibt sich ein völlig anderes Bild, als die ganzen Benchmarks glauben lassen wollen.
Bei einem Raid-Upgrade habe ich mal 12TB am Stück kopiert - und das auch gemessen.

Von Turnschuhnetzwerk kann bei mir wohl kaum die Rede sein. Ich habe rel. viel Aufwand in Optimierung der Installation und auch der Netzkarten gesteckt, ich denke, viel mehr ist (mit vernünftigem Aufwand) nicht mehr machbar. Dazu kommt, dass wenn ich ne Terabyte-Platte übers Netz kopiere, dass dann kaum noch Bandbreite für andere übrig ist - und das ist das letzte was ich brauchen kann.

Wenn ich mich entschließen sollte, bei yaVDR zu bleiben, werde ich meine Kiste natürlich aufräumen und an die Vorgaben anpassen.
Das ist doch selbstverständlich.
Bis dahin muss ich erst noch Erfahrungen sammeln.

Gruß Gero

Hallo,

kurz vor meinem Ausstieg bin ich ja zweigleisig gefahren, um rauszufinden, welche Anwendung für mich die bessere ist. Den Ausschlag zum Ausstieg hat dann Klaus selber gegeben, als er feststellte, dass er die Internas des VDR nicht aufzuräumen gedenkt und dass er negiert, dass es (nicht wenige) Anwender gibt, die einer Client/Server-Architektur den Vorzug geben.
Ich war lange Zeit glücklich mit tvheadend. Es hat zwar nicht alle Wünsche erfüllen können (insbesondere kann es nicht gegen epgsearch anstinken), aber die Leistung war akzeptabel, das Konzept dem reinen VDR haushoch überlegen. yaVDR geht in die Richtung wie tvheadend - also wesentlich benutzerfreundlicher, als der Core. Inzwischen bewegen sich die tvheadend-Entwickler in eine Richtung, die mir nicht mehr zusagt und die ich auch nicht mittragen will. So fing ich an, über eine Rückkehr zum VDR nach zu denken.

Den Ausschlag gab Mini73 mit seinem Bericht über einen Patch des Aufnahme-Verzeichnisses. Whow - ich bin ja schon länger ein Fan von Lars, aber das ist ja wohl die genialste Idee im VDR-Umfeld der letzten 10 Jahre! Externe Ereignisse auswerten und die Liste dynamisch anpassen - Hölle, ist das geil!
War ja klar, dass Klaus die Integration in den VDR ablehnt.
Da hat mir wieder GDA gefallen, der meinte, kein Problem, dann führen wir den Patch weiter. Ja, genauso muss es sein
Wenn man jetzt dem Aufnahme-Verzeichnis noch eine Kontextsuche beibringen könnte, wie es die glazedlist-Entwickler für die Java-Welt eröffneten *träum*

Naja - dass ich ne Schwäche für das yaVDR-Team habe ist auch kein Geheimnis und so habe ich es doch tatsächlich fertig gebracht, meine Abneigung gegen Ubuntu zur Seite zu schieben, über meinen Schatten zu springen und eine Installation von yaVDR zu waagen.
Nach einem Nachmittag lief die Kiste. Nicht schlecht.
Ob ich dabei bleibe - weiß ich noch nicht. Das werden die nächsten Tage zeigen müssen.
Aber da meine Freizeit derzeit eher knapp bemessen ist, ist die Frage eigentlich nur: e-tobi oder yaVDR.

Meine Client/Server-Struktur funktioniert zufriedenstellend. Ich habe mir eine Lizenz von VideoReDo gekauft. Den Tip bekam ich hier und der war Gold wert. Das Proggy funktioniert super aus einer VM heraus (Windows gibt es bei mir nur in einer VM ohne Netzwerkzugang) und über gemeinsame Ordner kann ich Filme vom Server aus einlesen und die kodierten Ergebnisse auf einer lokalen Schrottplatte speichern ...
VideoReDo kann framebasiert schneiden und man kann einstellen, dass nur die Passagen rund um den Schnitt neu kodiert werden. Das macht es schnell.Zudem kann es Aufnahmen auf Fehler untersuchen und (in Maßen) korrigieren.
Aufnahmen die vom VDR geschnitten wurden führen immer noch zu Fehlern - egal, muss ja nicht mit VDR schneiden

Meine Erfahrungen bei der Installation habe ich mal zusammen geschrieben:
Wie gesagt - bei mir war es keine Neuinstallation, sondern eine Installtion auf einem (ehemals) funktionierenden Debian-VDR. Ich wusste also: die Hardware passt.

Nach Erstinstallation und erstem Reboot blieb der Rechner mit „Pausenbildschirm yaVDR“ stehen. Kein Hinweis, was schief gegangen sein könnte, oder was noch fehlt. Keine der bekannten Tasten funktioniert, d.h. der Rechner erscheint erstmal unbedienbar (sind die Stream-Adressen noch aktuell? Zugang zu den netten Indern war erlaubt und möglich). Die Darstellung des Mauszeigers gibt einen Hinweis darauf, dass man sich auf einer grafischen Oberfläche befindet ...
Einzig Alt-F1 hilft um auf eine Konsole zu wechseln und mit der Fehler-Analyse anzufangen.
Hier wäre es hilfreich, wenn gleich der Browser mit der yaVDR-Schnittstelle zur Bearbeitung der Einstellungen geöffnet würde.

apt-get update und apt-get dist-ugrade funktionieren ohne weitere Vorarbeit durch den Anwender, d.h. beide Schritte könnten in Erstinstallationsphase integriert werden (muss der Anwender die Schritte wirklich bei der Installation ausführen?). Dass man beides händisch ausführen muss, weiß man nur, wenn man hier über den entsprechenden Fred gestolpert ist.

Die Dokumentation ist super – es wäre schön, wenn es nicht nur einen Link auf der Startseite, sondern auch in der yaVDR-Benutzerschnittstelle gäbe. Der Link könnte ja ein neues Fenster öffnen, sodass die Benutzerschnittstelle nicht durcheinander käme. Es kann doch immer mal wieder passieren, dass man Informationsbedarf hat ...

Nach Kopieren einer funktionierenden remote.conf und channels.conf kam dann auch Bild und Ton und der VDR war in bekannter Weise wieder bedienbar. Hier fehlen offensichtlich funktionierende Vorgaben. Zumindest die Tastatur sollte mit den Tasten ala Doku/Wicky funktionieren (was bei mir nach der Grundinstallation nicht der Fall war).

Vielleicht wäre eine Migrationsunterstützung machbar, so nach dem Motto: auf Partition x liegt ein lauffähiger VDR (egal welches System). Dann könnte yaVDR doch remote.conf und channels.conf dort suchen und kopieren … ? Vielleicht könnten auch Plugin-Einstellungen übernommen werden. Hier denke ich besonders an epgsearch (was bei yavdr kein Plugin mehr ist?) und an die timers.conf. Wenn die Einstellungen von epgsearch (Kanalgruppen, Sucheinträge, etc.) übernommen werden können, dann wäre der Import der Timer natürlich überflüssig

Dann war das Verzeichnis der Aufnahmen leer.

Dabei hatte ich die Platte bereits so eingebunden, wie sie unter e-tobi's VDR funktioniert hatte (unter /var/lib/video.00 – welches unter yaVDR auch existiert). Nach einigen Checks war klar – yaVDR will die Video-Platte an anderer Stelle haben. Hm – nicht unmöglich, aber ärgerlich.

Dabei könnte auch dieser Schritt automatisiert werden. Über /proc/partitions kann abgefragt werden, welche Platten es im System gibt. Wenn es, neben den, bei der Installation verwendeten Partitionen, weitere größere Partitionen gibt, könnte doch erfragt werden, welche als Video-Pool verwendet werden soll. Anschließend könnte für diese ein fstab-Eintrag erstellt werden, der die Platte dorthin einbindet, wo yaVDR die Filme erwartet. Vielleicht könnte sogar ermittelt werden, ob die Platte ein Label hat und ob der Benutzer lieber das Label oder die UUID verwenden möchte. Ich verwende Wechselplatten als Video-Pool und da ist die Verwendung des Labels anwenderfreundlicher. Schließlich läuft der Datentransfer wesentlich schneller, wenn die Platte in den Server gesteckt wird, anstatt die Daten übers Netz zu schaufeln.

Test mit xbmc – Wechsel zwischen xbmc und vdr funktioniert hervorragend. Ebenso wie die Bedienung von xbmc per Tastatur. Soweit schon mal OK. Dann aber der Medien-Check …

Auf der Video-Platte befanden sich neben VDR-Aufnahmen auch solche anderer Ersteller, sprich mkv- und ts-Dateien kodiert in avc oder auch h264 …

XBMC erkannte keine einzige der Nicht-VDR-Aufnahmen. Wobei ich nicht nur unter Video geschaut hatte, sondern auch versuchte, Aufnahmen über den Filemanager zu importieren. Was bitte schön soll ein solcher Moloch, der keine Filme erkennt und somit auch nicht abspielen kann? Ich denke, eine solche Installation macht nur dann Sinn, wenn xbmc auch die Medien erkennen und verwalten kann, die dem VDR fremd sind. Wenn dazu noch eine Erweiterung von xbmc notwendig wäre, sollte die Erweiterung bereits bei der Installation dabei sein.

Ok, nachdem die größten Nickligkeiten überwunden waren, folgte ein Test des VDR. Soweit so gut, Skin ist auch nicht schlecht …

Was mir spontan auffiel: beim Abspielen von Aufnahmen und Sprung per Funktionstaste nach vorn oder zurück – bei Softdevice gibt es erstmal Klötzchen nach dem Sprung. Dieser Effekt tritt bei xineliboutput und sxfe nicht auf. Bei der Klötzchenbildung kommt bei mir immer das ungute Gefühl auf: hat der VDR sich jetzt aufgehängt? Vielleicht gewöhne ich mich ja noch dran.

Gerade bei Sprung in HD-Aufnahmen ist es mir mit xineliboutput öfters passiert, dass der VDR sich bei einem Sprung „verschluckt“ hatte und erstmal neu starten musste (oder wollte!?!). SXFE ist so genial, dass es wartet und sich wieder neu verbindet, sobald der VDR wieder arbeitswillig ist.

Soweit mal der Bericht.
Wie gesagt, muss erstmal schauen, wie ich die nächsten Tage (und Wochen) mit dem Ergebnis klar komme, dann wird sich zeigen, wohin mein Weg gehen wird.

Gruß Gero

Hi Günter,

mein Dip: lass Dir etwas mehr Zeit in der Vorauswahl und lese viel.

Schau mal hier bzw. hier. Dabei möchte ich Dir die Beiträge von "tinhead" (in beiden Foren) besonders ans Herz legen. Der Typ hat nicht nur ne Ahnung von der Bedienung solcher Teile, er kennt sich auch mit der Herstellung und den Nickeligkeiten dabei aus.
Besonders begeistert war ich, als ich las, dass er mal eben aus einer mehrlagigen Platine einen Schaltplan erstellt hat.
Da gehört schon etwas mehr Fingerspitzengefühl dazu - würde ich mal behaupten.

Gruß Gero

Hi Klaus,

Quote

Eigentlich wollte ich das auch gleich mit einer schönen Oberfläche zum manuellen Positionieren und speichern versehen, werde es aber für den Moment beim bloßen "Goto X" belassen, weil der Druck, der hier im Forum zum Thema "Favoritenlisten" und "konfigurierbares Hauptmenü" aufgebaut wurde, einfach nicht mehr zu ertragen ist.

Weichei!

Also - entweder ist und bleibt der VDR Deine onemanshow, dann sollte es Dir sch..onegal sein, was annere denken und schreiben!
Du hast in sowohl beruflich, wie auch im Hobbybereich viele Erfolge eingefahren - und ich denke mal, dass Du auch ohne den vdr viel Druck ausgesetzt warst. Du bist doch kein Milchbubi mehr. Wozu also das Rumgeeier? Muss schon sagen - ich hätte Dir ein dickeres Fell zugetraut
... Du magst Dich mit dem Thema positionierbare Antennen beschäftigen und eine schöne Oberfläche dazu machen
- dann tu das doch auch verdammt noch mal.
[unpolite]Scheiß auf den Rest[/unpolite]

Es wird immer Leute geben, die es nicht gut finden, was Du gerade tust - so what?

Wenn Du allerdings der comunity und den Leuten entgegenkommen willst, die den VDR als Produkt ansehen, dann solltest Du es auch richtig machen.
Nicht bissle einknicken und Dich auf was einlassen, was Dir (zumindest im Moment) keinen Spaß macht.
Wenn Produkt, dann auch Projektleiter - nur dann kannst Du Dich zurückziehen auf das, was Dir Spaß macht.
Der PL kann sich dann um das Produkt, sowie um alle Fragen der Produktwartung kümmern.
Dann würde die Einführung eines Ticketsystems Sinn machen, über das auch Feature-Requests erfasst werden können.
Auch wenn jemand anderes das (lästige) Tagesgeschäft übernimmt, kannst Du bei allen Features immer noch entscheiden, ob Du was angehen willst und wenn ja wann ...

Gruß Gero

Hi,

finde leider den alten Thread nimmer.
Wennich mir recht entsinne, war der Stand der, dass der Schnitt vom mpeg-Material inzwischen perfekt läuft, der von HD nocht nicht ganz.

Habe gerade dies hier gelesen, vielleicht ist es ja noch nicht bekannt und hilft weiter ...

Quote

Unlike the MPEG2 video streams, the H.264/AVCHD video takes some special elements into its stream structure for playback control. If some video cutter simply chops the H.264/AVCHD video stream apart, then feeds the cut movie into some post-processing pipelines, such as transport stream re-multiplexing, Blue Ray disk authorizing; then, there may(even must) arise the problems of green glitch, mozaic, or audio/video in-sync.

Gruß Gero

Hi Gerald,

da ich Dich anderweitig nicht erreichen kann, melde ich mich hier nomml.

Quote from gda

Das hört sich an, als wüsstest du schon wie Klaus das implementieren wird. Ich sehe da jetzt nicht warum sich sowas ausschließen sollte.

Nun, egal wie es implementiert wird - wenn es keine übergeordnete Instanz/Zentrale/Server gibt, lässt sich Zugriffsberechtigung nicht wirklich umsetzen.
Auch wenn mir Deine Idee der Peerlösung gefällt, peer und restriktiv geht nicht zusammen. Zumindest nicht zuverlässig.
Vergleiche nur mal yp mit kerberos unter sicherheitstechnischen Aspekten.

Die ausschließliche Verwendung von Peers ist akzeptabel in einer "laissez faire" Umgebung.

MIr gefällt der Ansatz den die Fritzbox verfolgt. Dort kann man die Kindersicherung lax handhaben und verbietet nur manchen Geräten den Zugang - oder man kehrt den Default um und dann kommen nur noch registrierte/zugelassene Kisten zu den netten Indern. So betreibe ich meine Box.
In dem Kontext hätte ich auch gerne den VDR betrieben - aber das muss ich jetzt wohl selber machen

Quote from steffen_b

Wenn kls den VDR aus SPass am Programmieren macht - dann funktioniert der Gedankengang so nicht.
1.) Projektmanagment und Leute anleiten ist nicht Programmieren
2.) Um Code von anderen dann zu übernehmen muss das Vertrauen da sein und der Stil ziemlich genau den von kls treffen.
3.) kls müsste keine Lust drauf haben den Teil selbst zu machen

Nun, wenn Klaus sich einen Projektleiter "anlachen" würde, könnte Punkt 1 abgehakt werden, ohne dass er selbst es tun muss. Wenn also menschlich schon eine Vertrauensbasis da ist, sollte der Rest doch Pillepalle sein. Zum Leute anleiten könnte eine weitere Person ins Boot geholt werden. Natürlich gelten die Vorgaben von Klaus - aber es gibt reichlich unterschiedliche Menschen mit ebenso unterschiedlichen Interessen. Diesen Umstand könnte man so nutzen, dass alle was davon haben.

Man müsste nur wollen

Für Punkt 2 wäre auch ein Projektleiter zuständig.
Ich sehe nur Vorteile in Teamarbeit - zumindest wenn die Basis stimmt.

Und der Umstand, dass man ein Ticketsystem einführt, heißt noch lange nicht, dass man keine Freude mehr am Programmieren hat. Auch sowas ließe sich organisieren.

Gruß Gero

Quote

Es wird keinen "client/server" oder "master" geben, sonder nur gleichberechtigte "peers".

Ok, nach dem statement hat sich das Thema vdr als Aufnahme-SW für mich erledigt.

Quote

Ich bin der Meinung dass auch ein Client mit EPG umgehen können muss. Wie soll man sonst bei Live-TV die interessanten Sendungen raussuchen und die Aufnahmen programmieren. Und ich bin der Meinung dass man auch an einem Client einfach mit der Fernbedienung Timer erstellen und auch wieder löschen können muss.

Nun, wenn das OSD nicht so verkorkst wäre, wäre das ja kein Problem.
Datenaustausch in einem neutralen Format mit anschließender Anzeige - sollte auch beherrschbar sein.
Dazu ist es nicht notwendig, dass die Clients EPG können müssen.

Bei der peer-Geschichte gehen mir aber zuviele Themen den Bach runter.
Wer Ableger hat, für den hat Zugriffsberechtigung und Nutzungsdauer einen anderen Stellenwert, als für alleinstehende Paschas

Insofern - bye

Gero

Quote

Aber ich sehe schon, es war ein Fehler darüber zu schreiben.

Hm, das sehe ich ganz anders

Auch wenn Klaus jetzt erstmal ausgiebig Urlaub macht, können wir uns doch trotzdem austauschen.
Wenner dann aus dem Urlaub zurück kommt, kanner selberst entscheiden, ob was bei der Diskussion dabei ist, was ihm gefallen tun täte

Quote

Ein Client ist für mich ein VDR mit Softhddevice und dem Streamdev-Client-Plugin

Yo, so ähnlich ist auch meine Auffassung.
Was mich am derzeitigen Stand eines "Client" stört ist der ganze Ballast, der mitgeschleift werden muss. Ein Client nimmt nix auf und braucht kein Timer-Handling oder EPG-Geraffel - da ließe sich viel entschlacken.

Quote

Ein anderer VDR mit der "Rescource" Streamdev-Server-Plugin wird geweckt und liefert das Bild, oder eben die Aufnahmen.

Da bin ich völlig bei Dich!
Für mich ist es auch völlig schnurz, was gestreamt wird. Das Handling kann der Streaming-Server machen. Für mich gehört Video- und Audio-Material, welches nicht vom VDR stammt genauso dazu. Die Medien könnten auch von DVD, BR oder sonstwo herkommen.

Quote

Der einzige "Konfigurations-Schritt" der nötig wäre ist, beide VDRs müssten mal zeitgleich an sein.

Das würde aber bedeuten, dass die Konfiguration lokal beim Client gespeichert wird. Ein Informationsaustausch ala DLNA ist nicht verkehrt nur ein ziemlicher Overhead. Ich denke, normalerweise wird man ein Setup einrichten und dann damit leben. Dürfte eher die Ausnahme sein, dass ständig neue Teilnehmer dazu kommen oder wech fallen ...

Quote

Außerdem habe ich schon einen Job bei dem ich das programmiere was andere wollen.

Bitte nicht falsch verstehen. Ich will hier keine Forderungen aufstellen, die andere programmieren sollen.
Ich bin durchaus bereit, mich mit einzubringen.
Aber derzeit ist der Kern des VDR für mich eher was zum abgewöhnen und animiert nicht gerade, da was für schnitzen zu wollen.

Quote

es hat sich über die Jahre bewährt dass eine Instanz im Netz die Oberhoheit hat.

Yepp, das ist aber kein Widerspruch.
Bei DLNA ist es ja auch so, dass es eine Instanz mit "Oberhoheit" gibt - nur ist die dynamisch und Maschinen könne sich an- und abmelden.
Nicht grundsätzlich verkehrt

Quote

Desto mehr Aufwand bleibt bei Klaus hängen und das halte ich für unfair.

Wenn Klaus entscheidet, Plugin-Funktionalität in den Core zu integrieren, dann ist das seine Entscheidung.
Hier von unfär zu reden ist irgendwie schräg!

Quote

Das kann einer alleine irgendwann gar nicht mehr schaffen, solange es keine Community Entwicklung ist.
Und da dies noch hoffentlich lange Zeit außer Frage steht, ...

Der Hoffnung kann ich mich nun überhaupt nicht anschließen.
Community-Entwicklung ist nicht gleichzusetzen mit schlecht und/oder Stillstand.
Schau Dir einfach mal an, was mit yaVDR alles passiert ist. Für ein besseres Beispiel für Community-Entwicklung muss man schon zeimlich lange suchen.

Bei tvh war es erst auch so, dass es eine One-man-show war. Da hat sich zu wenig bewegt und die Anwender wurden unzufrieden.
Dann hat der Entwickler sich einen Ruck gegeben und ein Team aufgestellt.
... mit dem angenehmen Seiteneffekt, dass es jetzt einen Projektleiter gibt, der sich um das administrative Geschäft kümmert. Es wurde ein Ticket-System eingeführt, über das Fehler und Wünsche geäußert werden können. So gewann der ursprüngliche Entwickler Freiraum für seine Entwicklungen. In der Absprache mit dem Projektleiter ist klar erkennbar, dass der ursprüngliche Entwickler immer noch die Veto-Kompetenz hat.
Nun - wie auch immer - seit der Umstellung auf Teamwork wurde viel Basiscode neu geschrieben und an Standards angepasst - es hat insgesamt einen enormen Schub gegeben, der Code ist sauberer und wartbarer geworden - und bei alledem hat der ursprüngliche Entwickler jetzt die Zeit, sich auf die Dinge zu konzentrieren, die ihm Spaß machen.

Was soll daran verkehrt sein?

Wenn man den VDR als Produkt ansehen würde (statt als One-man-show), würden plötzlich viele Werkzeuge und Mechanismen Sinn machen, die sich auch in anderen Projekten bewährt haben.

Gruß Gero

Moin moin,

Quote

Ich hatte eigentlich auch gehofft, erstmal ein bisschen zur Ruhe kommen zu können ...

Oups - ich dachte, seit eagle 6 in trockenen Tüchern ist, hättest Du nur noch Ruhe, würdest am Strand liegen, die Füße vom Wasser umspielen lassen, die Sonne auf den Bauch scheinen lassen und gelegentlich etwas am iPad spielen

Quote

WO ???

Falls du hier meinst, hier hat er in diesem Bereich Modrechte und keine Adminrechte.

Ok, habbich wohl wat verwexelt.
Aba egal - hauptsache Klaus kann unerwünschte Beiträge löschen. Darum gings doch - oder nich?

Quote

Irgendwie verstehe ich den Thread auch nicht wirklich!

Da bitte ich um Nachtsicht.
Ich warte seit min. 2 Jahren dass sich in Sachen Multiclient-Fähigkeit was tut. Wurde immer vertröstet, zuletzt konkreter auf die Zeit nach 2.0 ...
Jetzt ist 2.0 raus - da bin ich natürlich neugierig, was sich jetzt wohin bewegt.

Für Feature-Requests halte ich es noch viel zu früh, es sei denn, es geht weiter im Stile von kosmetischen Änderungen.
Ich sehe "jetzt" den besten Zeitpunkt, um aufzuräumen, alte Zöpfe zu entsorgen und Fehlentscheidungen aus den Anfangszeiten zu korrigieren - sprich den Kern neu zu schreiben. Dazu muss man keine neuen Features im Hinterkopf haben, sondern nur etwas globaler denken
Wenn nicht jetzt, wann dann?

Quote

Es wundert mich dass ich dies hier desoefteren lese, das geht doch bereits via extrecmenu Plugin.
Wozu sollte man Core Features einbauen, sofern es auch via Plugin geht ?

Hm, das Rad jedesmal neu erfinden halte ich auch für Kwatsch.

Dagegen erscheint es mir durchaus sinnig, gute Funktionen in den Kern zu überführen.
Neben extrecmenu wäre auch epgsearch so ein Kandidat. Meiner Ansicht nach das beste Viehtscher am VDR.

Gruß Gero

Quote

Eine der Ideen ist jetzt, dass die VDRs ihre Resourcen austauschen und die Timer optimal verteilen.

Hm, das ist eine überaus interessante Idee, allerdings sehe ich deren Einsatz eher bei handverlesenen Powerusern.
Weiß nicht wieviele Anwender mehrere VDRs parallel mit Aufnahme-Devices betreiben.
Ich denke, die Zahl der Anwender mit echtem C/S Bedarf dürfte deutlich höher sein. Kann aber sein, dass ich da falsch liege.

Wie auch immer - ich halte das für keinen Widerspruch zum dem was ich schrieb. Wenn man den jetzigen VDR aufteilt in einzelne lauffähige Komponenten könnte das Aufnahme-Modul trotzdem ein Resourcen-Sharing betreiben, bzw. noch besser: es konnte in ein Resourcensharing eingebunden werden. Ähnlich wie die Konfiguration von div. Clients würde ich die Verwaltung der Resourcen auch von einem separaten Dienst steuern lassen.
In meinem beruflichen Umfeld hat es sich bewährt, lauffähige Komponenten mit kleinem Fokus zu erstellen. So ist das Gesamtsystem beliebig skalierbar. Dienste können mehrfach aufgesetzt werden, nur mit leicht unterschiedlichem Fokus. Das Prinzip übersetzt in den VDR-Kontext würde heißen, es gäbe einen Aufnahmedienst, der von einem Transponder aufnehmen kann. Bei einer Maschine startet der Timer-Manager den Aufnahmedienst für jede Aufnahme.
Wer jetzt das System skalieren will, könnte (im anderen Extrem) für jeden Transponder einen separaten Aufnahmedienst starten (hier können mehrere Maschinen ihre Dienste im Netz anmelden). Der Timer-Manager triggert dann nur noch die Aufnahmedienste der entsprechenden Transponder.

In meinem beruflichen Umfeld hat sich eine zentrale Datenbank als Triggerbasis bewährt (ich habe das Prinzip auch bei VdrAssistant so umgesetzt). So können Dienste als Automaten laufen und die Synchronisation der Prozesse erfolgt über Statusfelder in den Datenbanktabellen. Zusätzlich lassen sich einzelne Prozesse auch auf unterschiedliche Rechner verteilen.
Eine Aufnahme über mehrere Prozesse und Rechner könnte so ablaufen:

• epgsearch erstellt einen Timer
• der Aufnahmedienst für den Transponder des Timers ändert zum Aktivierungszeitpunkt den Status des Timers und erstellt ein Aufnahmeobjekt mit Status "in Arbeit". Daneben wird die Aufnahme auf Platte gespült. Wenn der Aufnahmedienst fertig hat, wird der Status von Timer und Aufnahmeobjekt weiter geschrieben
• ein Werbungssuchdienst könnte sich die erste fertige Aufnahme krallen (Status weiterschreiben) und nach Werbeblöcken suchen. Nach Erstellung der Schnittmarken wird der Status der Aufnahme fortgeschrieben.
• ein Serien-Verwaltungsdienst könnte die Aufnahme nach einer passenden Namensregel umbenennen, nach zusätzlichen Informationen bei den netten Indern anfragen, etc.
• ein Archivierungsdienst könnte jetzt die Aufnahme auf einen anderen Rechner verschieben ... (natürlich auch wieder unter Veränderung des Status)

Diese Dienste könnten alle auf einer Maschine laufen oder alle auf unterschiedlichen Maschinen. Natürlich könnten manche Dienste auch mehrfach gestartet werden, um parallele Arbeiten zu verrichten. Jeder Dienst sieht nur die Objekte mit seinem Eingangsstatus.

Grundsatzfrage für ein Resourcensharing ist auch die Datenhaltung: will ich dezentrale Datenhaltung oder bevorzuge ich zentrale Datenhaltung und kann so meine Hardware optimal abstimmen/einsetzen.

Quote

Was ich aber ernst meinte sind die "kruden komplexen Entwickler Vorstellung", die hier leider schon wieder bei einigen durchlinsen.

Im Gegensatz zum shitstorm bedeutet brainstorming ja gerade, dass man unausgegorene Ideen zur Diskussion stellen kann.
Solche Ideen sind deshalb ja nicht verwerflich, weil sie noch nicht ausgegoren sind.
Oft sind es gerade solche Ideen, die über die Diskussion zu ganz neuer Funktionalität führen, die man sich im Vorfeld garnicht hätte erträumen können.

Gruß Gero

Quote

Es wird vmtl. nie eine öffentliche Diskussion über Features geben, das ist doch gleich ein Shitstorm ...

Hm, also das kann ich nicht nachvollziehen.

Jetzt gibt es endlich ne tolle Forums-SW mit funktionierender Ignorierliste und Klaus hat Adminrechte - was fehlt noch um eine geordnete Diskussion zustande zu bringen?

Quote

Im Prinzip fehlt nur eine gescheite Netzwerk Schnittstelle. Dann kannst du dies, was du willst. alles auslagern.

In die Richtung gehen auch meine Hoffnungen (gut, es reicht nicht aus, eine gescheite Netzwerk-Schnittstelle zu haben, man braucht schon auch ein Mehrbenutzerkonzept um Konfigurationsdaten entsprechend handhaben zu können).

Ich würde mich freuen, wenn man aus dem Monolithen eine Schar von leistungsfähigen Tuhls machen könnte, die auch separat eingesetzt werden können.
Als Kern würde ich den Part ansehen, der die Aufnahmen erstellt. Mehr Funktionalität sollte auch nicht im Kern sein.
Dann sollte es einen Client geben, der die Wiedergabe per FF ebenso beherrscht, wie die per Plugin. Ob solch ein Client lokale Aufnahmen autark abspielen kann, lasse ich mal dahingestellt sein. Solch Clients sollten sich "beliebig" viele mit einem Backend verbinden können. Backend ist nicht gleichzusetzen mit dem VDR-Kern, der die Aufnahmen erstellt. Ob man den Fall, wo Client und Backend auf einem Rechner laufen als Spezialfall bevorzugt behandelt, steht auf einem anderen Blatt.
Dann könnte man die Funktionalität wie Schnitt der Aufnahme, oder Index Neuerstellung, Umbenennen von Aufnahmen, bzw. diese verschieben auch wieder in eigenständige Executables auslagern.
Auf die Weise könnte jeder Anwender nach seinem Gusto das dort installieren, was er wo benötigt.
Ich finde es z.B. nicht einsichtig, warum mir Kanalliste und der Haufen an Scripts installiert wird, wenn ich nur ein Tuhl installieren will, welches einen Index neu erstellen kann.

Als Basis für einen Multibinaryvdr wäre es notwendig, die OSD-Objekte von ihrer VDR-Bedeutung zu trennen. Wenn das Gerüst mal neutral funktioniert, wäre es ein leichtes, es für unterschiedliche Anwendungen wieder zu verwenden.

Ich bin ein bekennender Freund von Zusammenarbeit und Synergieeffekten und nachdem der BBC seine Plattform veröffentlicht hat, würde es sicher Sinn machen, diese entweder zu nutzen oder zumindest kompatibel dazu zu arbeiten. Bei TVH wird auch entsprechend gearbeitet.
YaVDR geht ja auch in Richtung WebOberfläche und Konfigurationsmöglichkeit via Browser - ich denke, das ist auch das, was jeder Anwender heute von einer Blackbox im Netzwerk erwartet.

Quote

Daher finde ich es am besten so etwas möglichst außerhalb des VDRs zu lösen.

Das ist ein interessanter Gedanke.
- bitte nicht steinigen -
Bei tvh ist es so, dass es dort kein shutdown-Konzept gibt (wohl aber eine Anleitung im Forum, wie man es trotzdem implementieren kann).
Ich habe die Scripte von e-tobi als Basis genommen und die Scripte von tvh und das ganze verwurschtelt
Jetzt funktioniert Shutdown/Wakeup genauso komfortabel wie vorher mit dem vdr.
Ich bin überzeugt, die Scripts könnte man auch wieder rückführen sodass es mit dem vdr ohne dessen Zutun funzt.

Gruß Gero

P.S.

Quote

setzt du nun VDR ein oder nicht. In deinem andern Post von heute 6:30 erklärst du noch lang und breit wie du deine daten von einem VDR zum nächsten trägst per "Floppy-Weitwurf" und hier willst dus nicht mehr gewesen sein.

Hey, also erstmal bin ich nicht der Typ, der irgendwas nicht gewesen sein will.
Ich stehe zu meinen (Un-)Taten!
Den Rest sehe ich nicht als Widerspruch.
VDR heißt doch Video Disk Recorder - auch wenn ich jetzt eine andere Aufnahme-SW verwende, hat sich an der Verwendung des Rechners nix geändert. Habe seinerzeit überlegt, ob ich den Rechner umbenenne - aber warum? Für mich ist es immer noch "mein" VDR. An meiner Sympathie für den VDR hat sich ebensowenig geändert. Nur ist es eben so, dass für mich der Aufnahmepart der wichtigste Teil ist. Dort war der vdr zunehmend unzuverlässig. Ich bin oft wochenlang unterwegs und wenn dann Aufnahmen nicht aufgenommen wurden und es gibt keine Fehler im Log, dann ist das für mich nicht akzeptabel. Nur in diesem einen Punkt ist tvh für mich besser geeignet. Seit meinem Umstieg gab es noch keine nicht erfolgte Aufnahme. Das heißt aber nicht, dass bei tvh alles perfekt wäre.

... ob Du darüber hinaus noch was verpennt hast, entzieht sich meiner Kenntnis

Hallo,

ich sehe in 2.0 weniger ein neues Produkt, als vielmehr den Startschuss für Neues.
Endlich sind die Fesseln wech und größere Änderungen können angegangen werden.

Im Vorfeld von 2.0 wurden ja etliche Diskussionen von Klaus gestoppt.

Deshalb hier einfach mal die Frage: Wie soll es jetzt weiter gehen?
Wird es ein "öffentliches" Brainstorming für neue Ziele geben oder findet die Entwicklung auch weiterhin hinter verschlossenen Türen statt?

Auch wenn ich derzeit keinen VDR mehr einsetze, bin ich doch nach wie vor an einer Weiterentwicklung interessiert.
Wenn die Themen, die mich interessieren angegangen werden, bringe ich mich auch gerne mit ein.

Vielleicht kann man den Chor-Bereich ja auch dazu verwenden

Gruß Gero

Moin moin,

Quote

Nun habe ich mal auf die Schnelle mhddfs installiert und getestet und muss sagen, das funktioniert eigentlich problemlos. NFS und Samba funktionieren.

Genau das meinte ich.
Die OS-Werkzeuge funzen zuverlässig und im Zweifel arbeiten andere Entwickler daran.

Wer den VDR zum Datengrab machen möchte, kann z.B. auch per mount einzelne Platten für Serien oder Themenbereiche einbinden. Daneben gibt es noch die "bind" Option für den mount-Befehl - wodurch sich mehrere Verzeichnisse parallel auf eine Platte außerhalb des Video-Verzeichnisses ablegen lassen. So lässt sich der Platz erweitern ohne auf so fragwürdige Konstrukte wie vfs ausweichen zu müssen.
All dies funktioniert auch transparent für den VDR, der somit keine Spezialbehandlung für das Video-Verzeichnis braucht.

Quote

Export ist ähnlich simpel, nur will man da vermutlich ein frei wählbares Zielverzeichnis...

Bei mir ist das Datengrab ein separater Rechner. Vor Jahren war die Transferrate von Platten schon einige Größenordnungen höher, als GBit Ethernet. Das hatte zur Folge, das ich mich seither selbst als Datenträger einsetze. Ich verwende ausrangierte Raid-Platten als Aufnahme(-wechsel-)platten im VDR und wenn eine voll ist, wird sie gegen eine leere ausgetauscht. Die volle trage ich selbst zum Server, wo ich den Import dann per Fernwartung durchführe. So ein Import kann sich durchaus über mehrere Tage hinziehen - je nachdem wie es meine Zeit erlaubt. Dort laufen auch etliche Scripts, die Doubletten suchen, Aufnahmen verschieben und so werden die Aufnahmen in die bestehende Ordnung eingefügt.
Das passiert alles asynchron zum VDR und das Datengrab ist dann auch die Quelle für Streaming etc.
Das VDR-binary gibt es auf dem Server "nur" um mal einen Index neu zu erstellen oder eine Aufnahme nachträglich zu schneiden ...

Meiner Ansicht nach ist das "Kerngeschäft" des VDR die Erstellung von Aufnahmen.
Alles andere ist nice2have und kann gut auch als Plugin publiziert werden.

Gruß Gero

Quote

Aber es ist IMHO eine gute Entscheidung es aufzugeben.

Dem schließe ich mich an.
Linux bietet mehr als genug alte Naive ...

Quote

Bezgl Umbenennen und Verschieben hoffe ich auch auf ein Export/Import (Kopieren) von Aufnahmen.

Hm - und wofür soll das gut sein?
Man kann doch jetzt schon Verzeichnisse vom NAS einbinden und nach einem touch /video/.update lassen sich die Aufnahmen auch abspielen.
Gut, wenn man ein Verzeichnis mit 10 TB an Aufnahmen einbindet, dauert die Suche nach dem touch rel. lange, aber ist immer noch um vielfaches schneller als ein physischer Import.

Ich sehe (Entwickler-)Zeit als endliche Resource und gut funktionierende Räder neu zu erfinden halte ich für Verschwendung.
Verzeichnisse lassen sich exportieren und danach kann man von überall einen Ex- und Import durchführen.
Ich finde, es gibt wichtigere Themen, die auf Abarbeitung warten.

Gruß Gero