Beiträge von Negge

Genau, du hast die deine Frage ja schon selbst beantwortet.

So ein DVB-Stream hat ja meist so ca. 4-5 MBit/sec (incl. Sound). Ein byte=8Bit.

5 Mbit/sec durch 8 Bit/Byte ~ 0,6 MByte/Sek.

Es werden also bei einem Stream so etwa 0,6 MB/sec auf die HDD geschrieben. Also sollten die 25 MByte der HD locker für 2-3 Streams parallel reichen...

Andereseits müsstest du mal prüfen, ob die HDD "Aussetzter" zwischendurch hat (indiz sind evtl. die schwankenden Daten beim hdparm)...

Hier ein paar Vergleichswerte fuer dich:

Ich hab gerade mal (bei laufendem vdr und einer laufenden Aufnahme) das hdparm -tT gemacht (ein paar mal je festplatte):

Hier die letzten Runs:

/dev/hda:
 Timing cached reads:   394 MB in  2.01 seconds = 196.34 MB/sec
 Timing buffered disk reads:  162 MB in  3.03 seconds =  53.46 MB/sec


/dev/hdb:
 Timing cached reads:   382 MB in  2.01 seconds = 190.25 MB/sec
 Timing buffered disk reads:  108 MB in  3.03 seconds =  35.66 MB/sec

Ansonsten schwankt die cached-reads-Rate bei beiden Platten etwa zwichen 375 - 400 MB in 2.01 seconds

Und die bufferd-disk-reads liegen bei hda zwischen 44 und 54 MB/sec, bei hdb zwischen 35 und 45 MB/sec

Sind beides Samsung Platten (hddtemp):

/dev/hda: SAMSUNG SP1614N: 43°C (7200 U/min)
/dev/hdb: SAMSUNG SV1604N: 39°C (5400 U/min)

Ach, und hda läuft im udma5(100 MB/sec) und hdb in udma6 (133 MB/sec). Allerdings ist das ja hauptsächlich ausschlaggebend für die maximal möglichen transferraten, die übertragen werden können. (und das die mit max. 54MB/sec bei mir auch udma4 (66 MB/sec) noch reichen würde). SOmit sollte der genaue DMA-Mode keinen Unterschied machen...

So, Secure-Apt braucht inzwischen scheinbar ein korrekt beschrieben Release-Datei mit einigen Details. Und man darf die erzeugte "Packages"-Datei scheinbar nicht mehr einfach mit gzip komprimieren (dann findet er sie nicht mehr).

Hier mein nun endlich funktionierendes kleines Scipt. Dateien liegen im Unterverzeichnis binary.

## Dateien löschen
rm binary/Release.gpg
rm binary/Release


## Packages-Datei erzeugen
#apt-ftparchive packages binary/ | gzip -9c > binary/Packages.gz
apt-ftparchive packages binary/ > binary/Packages  # gzip-komprimiert klappt nicht mit etch


## Repository-Beschreibung erzeugen. Wichtig für Apt in etch sind Suite und
## Codename.
echo "Origin: Meiner_Einer
Label: My local VDR repository
Suite: stable
Codename: binary
Architecture: i386
Components:
Description: My local self made VDR repository " > binary/Release.tmp


## Hash anhängen...
apt-ftparchive release binary/ >> binary/Release.tmp


## Erzeugen eine "tmp-Datei", damit die nacher nicht der MD5-Hash in der 
## Release-Datei von der frisch erzeugten und noch bearbeiteten Datei auftauchen.
## Umbenennen der Datei.
mv binary/Release.tmp binary/Release


## Datei mit gpg signieren.
gpg --sign -ba -o binary/Release.gpg binary/Release

Das war garnicht mal so simpel rauszufinden..

So, ich hab mich nun ne Weile mit apt-ftparchive rumgeschlagen. Prinzipiell müsste es jetzt auch funktionieren, tut es aber nicht. Die signierung klappt, aber Apt meckert:

Unable to find expected entry  Packages in Meta-index file (malformed Release file?)

Zitat

Original von 73kw
Aber leider läuft graphTFT bei mir nu nich. Hab gerade Gen2vdr 1.2 drauf gemacht und schon die Aktivierung macht respawing to fast. Der patch funkt leider auch nicht, habe hier 0.16 und der ist für 0.14... Werd mich da mal durchwurschtln...

Beste Grüße
Kalle

Hi Kalle,

das entscheidende am rotate-patch ist die fbrenderer.c

set_context_to_buffer(_resized);


imlib_context_set_image(_resized);
+ imlib_image_flip_vertical();
+ imlib_image_flip_horizontal();
UINT8 *dataptr = (UINT8 *) imlib_image_get_data_for_reading_only();

Da wird im Prinzip nur das Bild vor der Ausgabe rotiert. Funktioniert auch mit 0.16 problemlos,. Der Rest des Patches ist glaub ich nur für den entsprechenden VDR-Menü-Schalter und funktioniert bis dato sowieso noch nicht, siehe auch DVB-TVOUT: Bild 180° drehen

RepoRepo ist mir eigentlich viel zu fett und aufwendig. Das will ja nen "pool" anlegen. Ist also eher zum Mirrorn von Cds oder so gedacht.

Ich hab dagegen bisher ein simples Verzeichnis mit zwei Unterverzeichnissen "binary" und "source" benutzt, da dann enstprechend ei kompilierten Packete und Sources reingeschoben, scanpackges ausgeführt und gut war es.

Das geht mit secure-apt nun nicht mehr so simpel

Ich hätte auch nichts gegen ein kleines Skript einzuwenden, das mir die Dateien für das lokale repository automatisch updatet. Hab ich ja im pinziep auch jetzt schon genutzt.

#!/bin/sh
dpkg-scanpackages binary /dev/null | gzip -9c > binary/Packages.gz
dpkg-scansources source /dev/null | gzip -9c > source/Sources.gz

Naja, eigentlich ist der ganze Secure-Apt-krams bei einem lokalen, selbst angelgeten repository sowieso unsinnig (was soll das denn absichern). Eigentlich könnte man das dafür auch abschalten, aber soweit ich gelesen hab, kann man das wenn nur global abschalten.

Und der ganze Mist geht dann natürlich dennoch nicht. In der Release.gpg erwartet secure-apt die MD5Sums der gesammten Pakete des Repositry. Die (simple in scanpackages) erzeuget Packages.gz wird anscheinend so direkt nicht verwendet. Ich hab auch noch keine Lösung gefunden...

Hi,

seit etch ging mein lokales repository (in dem eine "rotate180"-gepatche Variante des graphtft-Plugin liegt) nicht mehr und somit war auch das graphtft-plugun nicht mehr gepinnt und wurde bei einen Update überschrieben. So ganz klar war mir der Grund bisher nicht, aber jetzt habe ich eine Lösung.

Apt-secure braucht eine "release.gpg"-Datei im repository.

Diese kann man sich folgendermaßen erzeugen:

In das Repository-Verzeichnis wechseln und dort erstmal eine unverschlüsselte release-Datei erzeugen und mit sinnvollen Werten füllen:

Archive: archive
Component: component
Origin: YourCompany
Label: YourCompany Debian repository
Architecture: architecture

Anschließend folgende befehle ausführen

Schlüssel erzeugen:

gpg --gen-key

und Datei verschlüsseln

gpg -abs -o Release.gpg Release

Anschließend muss der Key noch exportiert werden:

gpg --armor --output archiv_schluessel.gpg --export Schlüssel-ID

Die Schlüssel-ID bekommt man durch folgendermaßen angeteigt (am Beispiel von Tobias Key):

gpg --list-keys 
pub   2048R/306B6783 2004-03-18
uid                  Tobias Grimm <tobias@e-tobi.net>
uid                  Tobias Grimm <vdr@e-tobi.net>
uid                  Tobias Grimm <tobias.grimm@e-tobi.net>

Die ID ist dann 306B6783.

Anschließend muss der Key zu apt hinzugefügt werden:

apt-key add archiv_schluessel.gpg

Lesenwert dazu ist auch: http://wiki.debian.org/SecureA…51c6dade6185aa9a6823a824f

Viel Erfolg

Yup, die Links beschreiben genau das Problem.

Ich hatte das auch nochmal getest. Auch ein savedefault in der menu.lst (mit anschließendem manuellen Auswählen des EIntrags beim boot) hatte keine Auswirkung und wurde nicht gespeichert.
Mich beschleicht daher das gefühl, da hängt mit dem im mbr installierten grub zusammen, das da irgendwie nen Bug hat. Eine neue Grub-Version wird beim Update, soweit ich das gesehen hab, nicht neu im MBR installiert.

Ich habs allerdings nicht mehr weiter getestet, da ich mir den Bootbereich nicht zerschießen wollte (Risiko war mir zu hoch). Daher verwende ich einen (nicht idealen) workarround, und zwar grub-0.95 aus sarge (dank Pinning). Tut auch unter etch problemlos seinen Dienst und hat keine extra Abhängigkeiten.

Hier meine apt-preferences-Datei (hab die 0.95 gepinnt):

Package: grub
Pin: version 0.95*
Pin-Priority: 1005


Package: grub-doc
Pin: version 0.95*
Pin-Priority: 1005


Package: grub-splashimages
Pin: release v=3.1*,o=Debian
Pin-Priority: 1005

schieb.

irgendwie passiert hier nichts mehr...

Zitat

Original von e9hack
Bei grub 0.97 läßt Du nur noch 'default 2' am Anfang von menu.lst drin. In das Shut-Down-Scrpt kommt dann 'grubonce 0' rein.

So war das bei mir im Prinzip früher bei 0.95 (und debian/sarge). Grub-reboot-2 hat da auch nur grub savedefault--once irgendwie aufgerufen...

Soweit ich gelesen hab muss man bei Grub0.97 aber immer "default saved", sonst führt der immer den Eintrag unter default (also die Zahl) aus und irgnoriert andere Einstellungen.

grubonce gibt es übrigend bei mir (normales debian/etch) nicht?!?

Zitat

Das hat auch den Vorteil, das der PC nach unsauberem runterfahren (Reset, Netzstecker gezogen, ...) ohne Hilfe bootet. Grub weigert sich bei nicht sauberem File-System 'savedefault x' auszuführen. Das muß dann im Grub-editor beim booten gelöscht werden.

Wie bekommt den Grub was von einem unsauberen start mit?!? Oder unsauberen Filesystem. Das save-default wird doch schon vorm laden den kernels gesetzt. Das verstehe ich jetzt nicht?!?

Zitat

Original von wilderigel
Hab da nix geändert dran, also sollte sie original Debian grub Paket sein.

Ich hab die Dateinen gerade verglichen. Ist bei mir auch exakt dieselbe grub-reboot?!?
(bei sarge und Grub 0.95 (sagt mein Backup) lag die Datei auch noch unter /sbin/grub-reboot).
Insofern hat er die Datei beim Dist-Upgrade auch sauber erneuert. AARGS

Was mir ansonsten noch einfallen würde wäre der kernel (obwohl der ja nicht viel mit grub zu tun haben sollte). Ich nutze 2.6.16-ct-1?

Zitat

Original von HolgerR
Ich vermute mal ein "grub-set-default 0" mit anschließendem Reboot funktioniert auch nicht?

Scheinbar nicht. Zumindest hatte ich 5min später wieder zugriff. (also nach dem Reboot, der ein Halt sein sollte) Das Problem ist, das ich gerade von entfernt teste und eigentlich den VDR nur wieder schlafen legen will, geht aber nicht, komme immer wieder mit ssh an ihn ran.

Ich muss heute abend mal schauen wie sich das verhält, wenn ich wieder davor sitze...

Mistig...

wilderigel: Kannst du mal den Inhalt deiner /usr/sbin/grub-reboot posten?

Zu fürh gefreut. Geht doch nicht?!?

Grub-reboot 0 startet totzdem grub position 2 (obwohl default=saved gesetzt und der eigentlich saved=0 setzten sollte?!?

Danke, so gehts gut. (Und reproduziert das Verhalten von zuvor)

(Wilderigel hat das aber anscheinend am Wochenende auch schon ins Wiki gehackt, da hab ich ausnahmweise mal nicht geguckt. Naja, nun findet die Fourumssuche auch was )

Hi

ich habe meinen sarge auf etch geupdatet, nun hab ich aber ein Problem.

Mein Bios braucht nen Reboot, damit er die Wakup-Zeiten im NVRAM auch nutzt. Bisher klappte das auch recht gut. Beim Rebooten hat er halt "savedafault-once 1) genutzt und dann bei grub nur "halt" ausgeführt. Beim nöchsten boot startete er dann wieder mit Eintrag "2" (mit grub 0.95 aus sarge).

Bei grub 0.97 funktionierte das aber nun so nicht mehr! Der startet immer Eintrag "2", egal ob ich beim runterfahren savedefault-once setze. Das Problem ist auch bei 0.97 schon bekannt, allerdings hab ich keine Lösung gefunden. Muss ich jetzt selektiv auf den sarge-grub "downgraden", oder wie macht ihr dass?.

So, mit stunnel hab ich es nicht hinbekommen. Ich hatte zwar zeitweise einen stunnel-Dienst, der auf 443 gelauscht hat und auch an Port 80 weitergereicht hat. Allerdings kam da im Webbrowser nichts brauchbares an?

Nun hab ich Pound installiert und das geht eigentlich sehr gut. Ein paar Anmerkungen sind mir dabei noch aufgefallen.

1. Ich nutze Pound 2.x aus Etch. Die Standard-Konfig-Datei, die bei Etch dabei war, hatte nen Fehler, so das Pound nicht startete (dieses HTTP 1 -value in ListenHTTP). Stand im syslog, nachdem ich den Loglevel hochgesetzt hatte und den Pound neu startete.

2. Und nun das zweite wichtigere Problem (was bei mir etwas gedauert hatte bis ich es rausgefunden hatte). "/etc/init.d/pound restart" geht nicht (um die Konfigurationsdatei neu einzulesen). Da muss irgendwo nen Fehler in dem Skript sein. Um die config neu einzulesen muss man pound erst stoppen und dann neu starten!

3.So, hier mal der wichtige Auschnist aus der "/etc/pound/pound.cfg" (hab ich selbst auf ner andere Help-Seite zu Pound gefunden, funktioniert aber soweit gut):

ListenHTTPS
  Address 0.0.0.0
  Port    443
  Cert    "/etc/pound/server.pem"
  # pass along https hint
  AddHeader "X-Forwarded-Proto: https"
  HeadRemove "X-Forwarded-Proto"


  Service
    BackEnd
      Address 127.0.0.1
      Port    8080
    End
  End


End

Deine DXR3 läuft scheinbar nicht richtig, weil da irgendwie Dateien fehlen (ich hab allerdings keine Erfahrung mit der DXR3). Und scheinbar versucht der VDR diese als Ausgabedevice zu nutzen, und das schlägt fehl...

(ich kann mir ansonsten halt nicht erklären, warum er deine FullFeatured ansonsten nicht findet...)

Und was steht drin? Oder Problem gelöst? Wenn ja wäre schön, wenn auch andere wüsste wie du das gemacht hast...

Was sagt denn das Syslog?

Ich vermute mal, dass da irgendeine Konfigdatei des VDR nicht funktioniert und der VDR nicht starten kann, er das aber durch neu laden der DVB-Treiber zu beheben versucht (was aber nicht klappt, da nicht die DVB abgestürzt ist, sonder irgendeine Config-Datei falsch ist)...