Beiträge von bakaroo

Okay das wäre natürlich auch ein Weg, aber vermutlich keiner, der bei mir erste Wahl wäre. ZFS das zugrundeliegendes Filesystem zu nutzen, wäre schon eine einfache und pragmatische Lösung, wirft dann aber andere Hürden auf die ich persönlich nicht nehmen möchte. ZFS bedingt FreeBSD. Gibts als NAS schon sogar zum "zusammenklicken", schließt aber den VDR aus. Demzufolge brauchst du ein NAS und entweder einen weiteren Server-VDR oder die VDRs als full-Device.

Von den vielen Geräten wollte ich eigentlich weg, ohne den Komfort der lokalen VDRs einzubüßen. Ein extra NAS wäre eine weitere ausgewachsene Maschine.

Auch behandelt das auch nur die Symptome und nicht die Ursache.

Richtig ist: Die Angabe der Kopiergeschwindigkeit hat wenig mit der Leseleistung der Aufnahmeverzeichnisse zu tun. Da hilft tatsächlich ein großer Cache fürs Filesystem. Aber die Kopiergeschwindigkeit zeigt, daß es eine normale 1000BaseT-Verbindung ist, die ihren heimüblichen Nettodurchsatz schafft, hier also nicht das Nadelöhr ist.

Wenn aber von den Clients gar kein DirectoryScan notwendig ist, sondern, wie M-Reiner beschrieb, ein Serverdienst (ich lege mich mal nicht auf den VDR selbst fest) diese Liste hält, und den Clients seitenweise vorgekaut gibt, ist der Arbeits- und Speicheraufwand auf der Clientseite fast gleich null. (Okay, Seitenabfrage per SQL o.ä. senden, Ergebnis anzeigen.. das sind schon ein paar Millisekunden). Und es ist skalierbar.

Beim Essen habe ich ein wenig darüber gegrübelt.

-recordings.c bekommt einen Umschalter, um zwischen herkömmlichen dirScan und Verzeichnisdienstabfrage umzukonfigurieren.

-der neue Codebereich bekommt eine Funktion zur Abfrage je Bildschirmseite. Dazu muß er wissen, wieviele Zeilen je OSD-Menuseite bei eingestellter Schriftgröße er darstellen kann. (daraus wird beim VDR-Start Schrittweite und Abfragelimit errechnet). Er braucht dann auch nur Speicher für diese eine Seite. (ggf drei für ein Prefetch in jede Richtung).

-Er bekommt per gesonderter Abfage Infos über Gesamtkapazität in MB und Minuten.

-Noch nicht ganz klar ist, wo überall Änderungen wg Dateioperationen notwendig werden (Umbenennen, Schneiden, Aufnahmeliste aktualisieren, weil ein anderer VDR Operationen durchführt etc). Hier sehe ich eine riesen Rattenschwanz an Kleinständerungen auf mich zukommen - von Änderungen in Plugins will ich noch nichtmal reden.

-Auf Serverseite könnte entweder der VDRserver das via SVDRP übermitteln und selbst verwalten (womit das Problem aber nur hierher verschoben wird) oder aber ein extra Dienst/Plugin schruppt über das Aufnahmeverzeichnis und legt alles in SQL oder LDAP ab. Damit wäre auch ein unabhängiger Zugriffsweg für Kodi und Konsorten offen.

Hab ich was übersehen?

Richtig, man kann natürlich einen neuen Server kaufen. (hier war ein älterer AthlonX4 mit DDR2-Board am Start. Leider waren und sind DDR2-RAMs >1GB eher ungebräuchlich gewesen).

Aber in der jetzigen Fassung vonRecordings.c wird sowohl beim Server als auch bei den Clients dieselbe Strategie zum Erstellen der Aufnahmeliste gemacht. Demzufolge benötigen auch die Clients entsprechend RAM und Zeit. Bei X86-PCs geht das nachzurüsten, aber was passiert mit ClientVDRs auf Raspi oder CoreELEC-Basis?

Lediglich die Beschreibung auszulagern sollte zumindest die RAM-Last drücken, aber ich sehe das nur als halben Weg. Ein VDR muß immer noch durch den vollständigen Verzeichnisbaum durch und sich per 'stat' die Dateigröße der .ts-Dateien holen, das Aufnahmedatum aus dem darüberliegenden "xxx.rec/del"Verzeichnisnamen holen und dann zum nächsten Eintrag in der Verzeichnisliste gehen.

Worst Case:

Wenn dann noch der VDR nicht nur die Aufnahmen bereithält, sondern gleichzeitig noch als NAS dient (was zwar nichts mit den Aufgaben des VDR-Servers zu tun hat, ich aber nicht für abwegig halte), liegen dort auch Verzeichnisse und Dateien anderer Art, wobei der VDR diese Verzeichnisse ebenfalls erfolglos aber zeitraubend) durchkämmt.

Klar kann man in so einem Fall empfehlen, ein getrenntes Samba-Share bzw ein extra-NFS-Export zu machen, aber das bedarf auf Clientseite ein extra mount (= Extra Unterverzeichnis) bzw einen extra Laufwerksbuchstaben.

Mal die Hand hoch: wer betreibt den VDR als Server für andere Clients (VDR, Kodi oder Sonstwas) und hat _nicht_ auch andere Archive im gleichen Share?

Klar kann man in so einem Fall empfehlen, ein getrenntes Samba-Share bzw ein extra-NFS-Export zu machen. aber das bedarf auf Clientseite ein extra mount (= Extra Unterverzeichnis) bzw einen extra Laufwerksbuchstaben.

kamel5: nein die Platten laufen ohne Probleme, sie haben allesamt keine nennenswerten Fehler (im Sinne von im syslog eingetragenen Fehlermeldungen; lediglich smartmon gibt schon Zahlen Richtung Null gehend raus - die neuesten sind es nicht).

Die Dateisysteme sind fehlerfrei und der Datendurchsatz selbst ist auch okay. Es ist auch nicht das Problem der Platten, Dateisysteme, oder Konfig, sondern einfach nur die Summe der zu bearbeitenden Datenverzeichnisse.

Auf den beiden kleinen VDRs läuft normalerweise ein einfaches EasyVdr5 mit 1x streamvdr-Client bzw einer alten ein-Kanal-Terratec (?) und einer lokalen 4TB bzw 6TB-Platte. Damit gibt es auch keine Probleme. Auf den kleinen läuft auch nichts anderes, selbst Cups, avahi und NetworkManager samt all seiner sinnlosen Helferlein sind dort raus.

Ich hatte unter der Woche nur alle mal zusammengesteckt in eine Kiste und dabei obiges beobachtet.

Ich gehe also mal von euren Infos aus, daß es dahingehend noch nichts gibt, aber es ein paar vergleichbare Erfahrungen gibt.

Dann werde ich wohl mal den Quelltext lesen müssen, einen Plan machen und schauen, ob ich das dann auch umgesetzt krieg.

Nachtrag:

> Apropos Ladedauer: bei mir dauert das einlesen vom Server (ca.11000 Aufnahmen) etwa 1min (nach einem Server Neustart). Wenn der Server Cache befüllt ist, weniger als die Hälfte der Zeit.

Ähm, nach meinen Verständnis lädt ein VDR-Client die Aufnahmeliste nicht vom vom VDR-Server (hier als Programm gemeint), sondern holt sie sich aus dem Verzeichnisbaum des angebotenen Share, quasi per opendir(). Daß ein VDR-Server den kompletten Verzeichnisbaum im Filesystem-Buffer hat, würde ich mal optimistisch als "Zufall" betrachten.

Ich denke auch nicht, daß das 2GB Ram ausmacht, aber Pi mal Daumen 0,5-1KB Ram je Aufzeichnung kann man rechnen:

Verzeichnisbaum je Aufzeichnung (beinhaltet Name und Auzeichnungsdatum), Beschreibung aus info.vdr, etc.

Aber wenn eine Maschine nur zusammen 2GB hat, muß dort das gesante OS, alle aktiven Dienste und Buffer, der VDR ansich und ggf noch Dinge wie VDRadmin, Lighthttpd, Samba, etc rein. Ein normaler x86-Ubuntu-VDR braucht schon ca 1,5GB. Dann noch va 16-256MB für Grafikspeicherfenster und andere IO-Ranges abziehen, schon füllt sich Swap.

Der Server hat eine Aufnahmeliste in seinem VDR liegend. Von daher kein Unterschied zum Client-VDR.

Richtig ist, daß das scheibenweise Importieren womöglich die Lösung ist. Von daher ja das "SELECT ... LIMIT 12", es liefert dann die Liste seitenweise an den VDR.

Dazu müsste aber recordings.c so umgebaut werden, daß die Liste nicht per "full Directoryscan to Ram", sondern OnDemand in Scheiben geliefert werden. Damit hat aber der VDR keinen Überblick mehr über die Gesamtheit der Aufzeichnungen, was wiedrum Änderungen an der Gesamtanzeige "xxx Minuten Frei" oder der Verwaltung alter Aufnahmen bei begrenzten Platz notwendig macht. Ein ziemlicher Rattenschwanz.

Auf den Festplatten sind normale ext4 und xfs Dateisysteme, je (alten) Client zw. 4-8TB brutto, basierend auf Ubuntu und Debian. Diese Platten habe ich spasseshalber mal in eine Kiste gepackt, mit einer dieser VDRs gestartet, die anderen lokal in Unterverzeicnissen unter Video hinzugemountet sowie per nfs4 exportiert. Ergo: alles ganz normal.

An einem Client dann probeweise per NFS-Client als Aufnahmeverezeichnis gemountet und auf diese Weise einem VDR mal den ganzen Stapel an Aufzeichnungen vorgehalten. Obwohl der zu messende Datendurchsatz (6,5 GB in unter zwei Minuten per cp von remote file zu local file) mehr als ausreichend ist, ist ein Verzeichnisscan in der Größe nicht wirklich was für Ungeduldige.

Hallo,

Nachdem ich nun den Plan gefasst hatte, unsere diversen VDR-Maschinen zusammenzufassen (grundsätzlich alle EPG + Aufnahmen zentral (nfs) + Nur ein Aufnahme-VDR mit dann 4+2 Eingängen, andere VDR nur noch Clients), musste ich feststellen, daß ein Laden der Aufnahmeliste ewig braucht - ca 7min) und die die Clients dann den RAM ziemlich voll nehmen.

Okay das sind dann bei mir ca 24TB mit ca 8000 Aufnahmen.

Auch schaffen die VDRs es nicht, beim Einschalten sich eine vollständige Liste zu holen. Sie benötigen mindestens 1x "Aufnahmeliste aktualisieren". Und die beiden kleinen mit nur 2GB RAM stürzen dann gelegentlich mal ab.

Meine Überlegung ist nun, die Aufnahmeliste in den SQL-Server zu packen, der schon fürs EPG rumwerkelt.

So könnte ein "SELECT * from Recordings LIMIT p,12 Order by Date" (wobei hier p ein vielfaches von 12 ist, als Seitenzähler).

sich problemlos häppchenweise die Liste holen. Die Gesamtzahl an Aufnahmen und -stunden liesse sich dabei auch einfach ablegen.

Gibt es sowas eventuell schon oder muß ich mich mal über recordings.c hermachen?

Hm, Gardena hat den Vorteil daß man es in eigentlich allen Baumärkten vorrätig hat, wenn man mal was braucht.

Und Gardena hat den Nachteil, daß man diesen Vorteil im Vergleich zu Mitbewerbern sehr oft nutzen muß, um Ausfälle zu kompensieren.

Die Rainbird-Sachen sind natürlich nicht für Gartenschlauch-Liebhaber gedacht, sondern es sind fixe Installationen, die dann mal einfach ein, zwei Jahrzehnte problemlos durchhalten. Merke: wenn du Freude am Immer-wieder-Regner-umstellen hast, dann ist Gardena dein Freund.

Wenn du lieber nur 1x pro Jahr Frostschutz betreiben willst, aber der Rest so laufen soll wie die Wasserversorgung in Küche und Bad (inkl Vorprogrammierung etc) dann ist Rainbird, Hunter oder Teredo dein Freund)

Das bedeutet aber auch 1x Wasserleitung (PE-Rohr) zu jeder Regnerstelle legen - unterirdisch. Kann man mit Spaten machen oder sich technische Hilfsmittel besorgen. Das zusammenbauen ist einfach.

Du kannst je nach Wasserverhältnisse mehrere Regner an einen Strang klemmen. jeder zu schaltene Strang bekommt ein Magnetventil an passender Stelle.

Kostenübersicht:

Versenkregner: "3504"/"5004" ca 12-15EUR pro Stück. max 10/15m Reichweite

"1800" 4EUR/st. max 5m Reichweite

Verbindung von PE-Rohrabzweiger zu Regner. Machs dir einfach und nimm hier die Flex-Schläuche von Rainbird bzw Hunter.:

30cm Flexschlauch+ 2 gewinkelte Anschlußstücken. =zusammen 2 eur /Regner

HV oder DV - Magnetventil 20Eur/stk je Kreis. Dazu am besten diese grüngedecktelten Boxen.

bei den Verteilerkästeninhalten lass mal Rainbird & Co links liegen, ich hab da bei den Israelis was

gefunden: "Tavlit" (gibts auch hier in DE)

T-stück +Verschraubung =7EUR je Abgang. Und schön kompakt für problemlosen Einsatz in so ner Box.

Verrohrung mit normalem PE-Rohr+ den blauen Verschraubungen.

Verbuddeln auf 2x Spatentiefe reicht i.d.R.

Hier mal mein Beispiel für 1000m2 Grundstück mit Rainbird-Regnern, damit du ungefähr siehst, was auf dich zukommt.

4x 3504+ 12x 1800er. =100EUR inkl Flex-Regneranschlüsse

8x Magnetvertile =220Eur inkl Tavlit-Verschraubungen

+ 3 kästen+ PE-verrohrung.+1 Rolle Telefonkabel zur Ansteuerung

+ DIY-Steuerung mit AVR. (selbstverständlich in eagle gezeichnet :))

Das fing so 2011 rum an und ist seitdem Stück für Stück übers Grundstück erweitert worden, zuletzt 2016.

Ich glaube, ich habe ein Magnetventil gewechselt (selbst schuld), und bei drei Regnern andere Düsen aufgeschraubt.

Ansonsten 1x pro Jahr in Betrieb und ausser Betrieb nehmen. Für letzteres brauchst du einen Kompressor.

Ich hab hier von jeder Verschraubung und jeden Regner 2x Reserve. _das_ war Geldverschwendung.

Danke euch zwei, Das mit dem femon hab ich auch schonmal gelesen, aber irgendwie vergessen.

Szap ist schon das was ich gesucht hab. Kleine Hürde: es wird zwingend eine channels.conf gebraucht. Findet man aber nicht an den üblichen Stellen.

Könnte man sich mittels scan auf der VDR-Channels bauen - wenn man denn noch einen Vdr 1.6 oder älter nutzt....

Eine brauchbare Anleitung, wie die Datei aussehen soll,gibts in der Doku auch nicht. Ich bin in einem russischem Forum fündig grworden und hab mir dann aus der aktuellen Astra-Liste 4 Sender gesucht, die jeweils die Kombinationen aus H/V und L/H abdecken.

T5:12480:v:0:27500:1535:1536:51
srv:12663:h:0:22000:1110:1111:13110
123TV:10802:h:0:22000:767:0:5502
LTC:10847:v:0:22000:171:124:30108

gehört in /home/$user/.szap/channels.conf

dann geht:

szap -a 0 -f 0 T5

wobei der Wert hinter f für 0.. 1/ 3/ 7 ... der Nummer des Frontends und damit der F-Buchse ist.

Nein, es geht um das Steuersignal aus dem DVB-Karten / Sat-Receivern / SatIP-Konvertern raus zu den Multischaltern/LNBs.

Das, welches zwischen H/V und High/Low bzw DiseqC 1-4 umschaltet.

Mit welchen Softwaretools kann man _testweise_ gezielt die einzelnen Forntends Ein- und Umschalten?

Hallo,

Gibt es eine Möglichkeit, die DVB-Karten, die der VDR unterstützt, testweise ohne VDR einzuschalten und jedes Frontend einzeln anzusteuern?

Ich würde gern checken, ob die Ebenen-Umschaltung bei allen F-Buchsen funktioniert.

Ich habe mich schon mit w_scan, szap und dvb-fe-tools versucht, aber ich bekomme trotz laut lsmod geladener Module keine LNB-Spannung aus den Karten.

Ich habe das nun mit TBS-6902, 6982 und 6985 (also SAA7160 und Lattice XP2 als FPGA-Bridge wie bei den Cine S2 V7) probiert.

Als Testdisplay habe ich hier einen Spaun TP216, aber ohne VDR bleibt der dunkel und mit VDR schaltet nur das Frontend, was zum TV-schauen genutzt wird.

Alle Karten scheinen sonst unter VDRs zu laufen (zumindest kann ich TV sehen + gleichzeitig eine Sendung eines Tranponders anderer Ebenen aufzeichnen).

Gruß

Bakaroo

Die Settings passen so zu meinen. Gestern getestet: Analog-Audio, mit Kopfhörer und extra aus dem Schrank ausgebauten AVReceiver. Ergebnis: Ton gleich.

Heute hab ich es gefunden. Wenn ich das vom X86 wiedergebe, benutzt der PananasonicTV die Toneinstellungen nach Profil "Benutzer" mit eingestellten Eq. Beim Raspi ist das Profil in TV "standard". mit flacher Kurve. Tausche ich beide HDMI-Anschlüsse, wechselt das Setting mit dem Quellgerät.

WTF!

Ggf. sind da evtl verschiedene eeid-Stettings auf dem HDMI-Pfad, aber so viel Forschung will ich da nicht betreiben. Damit kann ich leben, sehr gut sogar. Also zurück zum GCC-Herd - Plugins backen.

Gruß

Bakaroo

denke, ja

Ich habe das git gestern nochmal neu gezogen: https://github.com/reufer/rpihddevice.git

und gegen einen ebenfalls gestern gezogenen vdr-2.3.6 gebaut. Die src-Dateien des rpihddevice-Plugin haben allesamt das Datum 11.02.2023 13:06.

Also quasi ofenfrisch gebacken und noch immer warm.

an settings habe ich in der Setup.conf nur folgendes gefunden:

UseDolbyDigital = 1

rpihddevice.AudioFormat = 1

rpihddevice.AudioPort = 1

Das Ganze läuft auf einem Rpi 1 B+ mit 512MB RAM mit aktivierter Mpeg2-Lizenz

Neben rpihddevice ist da nur noch streamdev als plugin gebaut - alles auf einem Standard-Debain-stretch laufend.

Hier noch ein Testschnipsel.: https://filebin.net/1zpjo34i3cceo1nm

Damit sollte das nachvollziehbar sein.

Jaja das ist ein Luxusproblem, aber wenn man sich den Schnipsel anschaut und -hört, das fällt definitv in die Kategorie "geht ja gar nicht".

Hi, mir ist was merkwürdiges aufgefallen. im direkten Vergleich zwischen einen vdr-client auf dem Raspi mit rpihddevice und einem x86 mit Nvidia GT710+ vdpau+softhddevice.

der Klang auf dem Raspi ist merklich dumpfer. So dumpf, daß es z.b. bei Arte/3Sat-Konzertmitschnitten unangenehm auffällt. Lässt sich da irgendwas machen?

Ich sehe, daß im rpihddevice-sourecode FFmeg erwähnt wird. ggf muß ich mir das mal genauer anschauen, habe aber mit der ganzen Kette wenig Erfahrung.

Getestet im A/B -Vergleich_ ein TV-mitschitt von guter Soundqualität ( in diesem Falle "Eric Clapton Slowhand at 70"), abgespielt auf dem Raspi und dem x86. Ausgabe jeweils per HDMI (auch audio) an das gleiche TV-Gerät (Panasonic TV). mit gleichen Einstellungen am TV (auch mal die Eingänge getauscht). Ergo: Datenmaterial und Ausgabe jenseits HDMI-Buchse ist identisch. Am VDR ist eingestellt "Audio via Stereo-PCM", auch probiert: "Passthrough".

Aufgefallen war es als in obiger Aufnahme eine Nahaufnahme des Schlagzeugs kam und der Drummer mit dem Schlagstöcken das HighHat bediente. Auf dem X86 war das zu hören, auf dem Raspi nicht. Ich schneide mal die paar Sekunden als .ts-file zusammen und lade die mal hoch.

Gruß

Bakaroo

Hallo,

Nach Einstellung von easyvdr und Tests alternativer Distris bin ich nun an dem Punkt, mir einen VDR.Client (wieder) selbst aufzusatteln.

Einen älteren Raspi 1B+ rausgekramt, Staub abgewischt, ein "frisches" Debian Stretch auf eine SD gemalt, per git mir die Quellen von VDR, Rpihddevice und Streamdev

nebst einigen anderen Libs, Debs und Plugis geholt und vor einigen Tagen
"make REMOTE=LIRC && sudo make install"

angestubst...

Heraus kam ein Startbarer VDR, der per rpihddevice auch ein bild auf dem TV wirft, und mit einem per setup.conf (+Co) konfigurierten Streamdev-client auch tatsächlich ein Fersehprogramm wiedergibt.

Es kommt auch kurz das LCARS OSD, aber der VDR lässt sich nich tper Tastatur steuern.

Okay, Haube auf:

1.der vdr wird zur Zeit manuell per runvdr gestartet:

der relevandte Teil:

export LANG=de_DE.utf8
export LC_COLLATE=de_DE.utf8
export VDR_CHARSET_OVERRIDE=ISO-8859-9
setterm -clear -cursor off > /dev/tty7; chvt 7;
VDRKONSOLE="< /dev/tty7"
VDRPRG="/usr/local/bin/vdr"
VDROPTIONS="-w 60  -l 3 -u vdr -c /var/lib/vdr -s /usr/local/bin/vdrpoweroff.sh"
# For other options see manpage vdr.1
VDRPLUGINS="-P rpihddevice -P streamdev-client"

also ziemlich standard.

ein remote.conf habe ich auch mit den üblichen:                                               

KBD.Down       00000000001B5B42
KBD.Menu       000000000000006D   
KBD.Ok         000000000000000D
KBD.Back       000000000000007F
....

Wenn ich die Datei aus den Config-Verzeichnis lösche, kommt auch die Anfrage nach dem Anlernen der Fernbedienung KBD, also wird die Datei erkannt

Auch das syslog ist trotz level 3 nicht wirklich erhellend. (siehe Anhang)

Hat jemand noch eine Idee, welche Schraube ich übersehen haben könnte?

Gruß

Bakaroo

Auch ich trauere dem easy-vdr nach. Eine der besten (in den Augen vieler _die_ beste) auf VDR ausgerichtete Distri.

Ich habe mir gerade den Mirror des Forums angeschaut, da ich was nachschlagen wollte. Aber ich musste feststellen, daß viele Unterforen nicht funktionieren. (wenn man bespielsweise /Hardware/Eingabe-Devices auswählt, lässt sich keiner der Beiträge öffnen).

Ich würde mich hinsetzen wollen und die Beiträge zur FAQs zusammenfassen (okay wird auch etwas dauern) . Damit liesse sich dann ggf auch hier dem Wiki etwas gute tun. Hat jemand noch das Forum vollständig? Ich habe da noch etwas Webspace übrig, sodaß es in der Zwischenzeit auch öffentlich read-only für alle zugänglich sein kann, bis das FAQ steht.

Ah deshalb gibts beim Aufruf von easy-vdr jetzt die Cloudflare-typischen Javascript-Müll "made in India": "Haupsache der Kunde (Cloudflare) kriegt seine Werkzeuge, ob seine Kunden CPU-Lasten von 4x100% im Browser haben ist uns egal".

Ich weiß, daß viele Webseitenbetreiber übertrieben gesprochen nach dem Motto "Hauptsache Ruhe, zur Not auch vor dem eigenen Besucher" vorgehen, weil die Webseiten nur nebenbei gepflegt werden. Dabei kann man (wenn der Hoster kompetent ist und mitmacht) das ganze oftmals wesentlich einfacher lösen.

Was für Probleme (also was für aggressive Anfragen) hast du denn? ggf kann dir auch so geholfen werden...

Hi Gemeinde,

Wer von Euch den VDR nicht nur zum Aufzeichnen nutzt, sondern dessen Material auch auf DVD brennt, kennt das Problem: Wie kann ich die DVDs ordentlich wegpacken? Ich denke mal, daß Ihr dazu wie ich halt Leerboxen für DVDs kauft und die damit ins DVD-Regal stellt. Und wie schafft ihr es, daß die Einlegeblätter vernünftig aussehen?

Ich habe hier ein kleines Perl-Script, was ich mit euch teilen möchte:
http://www.geocities.com/bakaroo2001/dvd-case.pl
Es druckt DVD-Box-Inlays gleich stapelweise. Dazu erwartet es eine Textdatei namens DVDLIST.CSV (ja, die kann man z.B. mit Excel erstellen) in der alle zu druckenden Inlays aufgeführt sind. Die Datei hat folgenden Aufbau:
Pro Zeile ein Blatt, je zwei Filme, Beiträge [whatever] durch Semikolon getrennt pro Zeile - für entweder zwei Filme pro DVD oder zwei DVDs pro Box. Natürlich könnt Ihr auch zwei DVDs mit je zwei Filmen zusammenpacken - Hauptsache, Ihr überschreitet nicht die Textlänge von 66 Zeichen.
So könnt Ihr in einem Rutsch gleich Dutzende von DVD-Box-Inlays drucken, die dann ausschneiden und mit DVD und -Box zusammenpacken.
Die Druckausgabe erfolgt an den Standarddrucker des Systems, Ausgegeben wird lupenreines Postscript auf DIN-A4.Wer also keinen Postsript-Laserdrucker hat, sollte also Ghostsript oder ähnliches zwischenschalten - CUPS erledigt das übrigens automatisch.
Es ist nicht gerade besonders schön, aber es erfüllt seinen Zweck - vielleicht stiftet es ja jemanden zu weiteren Untaten an

Gruß
Bakaroo

Richtig, ich hatte zwar die entsprechenden rpms installiert (SuSe10) allerdings die devel-Pakete vergessen. Das fällt wohl unter PEPKAC: Problem exists between keyboard and chair

Danke sagt
Bakaroo

Irgendwie hab ich das Gefühl, das da eine Datei fehlt.
Beim Kompilieren erhalte ich stets die Fehlermeldung

"make[1]: *** No rule to make target `mad.h', needed by `mp3.o'. Stop."

Logisch, denn diese Datei gibt es nicht
Habe ich irgendwas verpasst?

Gruß
Bakaroo

Jetzt brauch ich mal eure Hilfe.
Hier rennt ein selbstgebackener vdr 1.4.0 auf einer suse 10.0. Er zeichnet auf, spielt die Aufzeichnungen ab, kommt auch mit anderen Plugins klar. Nur mit dem burn-Plugin 0.1.0-pre11 klappt es nicht.
Wenn ich einen Film mit [rot:wählen] auswähle, bekomme ich kurz die Meldung "Aufzeichnung wird analysiert..." der Film in die Jobliste eingetragen aber dort keine Audio- oder Videospuren angezeigt
Stattdessen bekomme ich auf der LinuxConsole, auf der ich runvdr startete die Meldung "Can not open /video/%4400_-_Die_Rückkehrer/2006-05-09.03.37.50.99.rec001.vdr: no such file or directory"

Die Meldung selbst ist eigentlich selbstredend: es fehlt der slash / zwischen ...50.99.rec und 001.vdr - aber wo muß ich das korrigieren?

Gruß
bakaroo