Beiträge von pram

Da ja seit 2009 die Callcenter ihre Nummern übertragen müssen, kann man einfach eine Wählregel in der Fritzbox konfigurieren, welche nervende Nummern einfach an den nächsten T-Punkt im Ort weiterverbindet

... in der Anrufliste sieht man dann, dass die Gespräche teilweise 3-5 min dauern

Zitat

Also kurz gesagt: Habe ich die Möglichkeit 5 Platten gleichzeitig anzuschliessen oder liegt das Maximum bei 4? Im Gehäuse habe ich leider so gut wie keinen Platz für Controllerkarten daher alles onboard.
Die Herstellerseite bietet leider weder genaue Auskunft noch ein Handbuch zum Download, daher bin ich auf eure Erfahrungen angewiesen.

Nein, der 5. Anschluss ist meist nur eine Verbindung zum externen eSata-Anschluss.

Das ION-Board hat 4 x SATA. Wenn du eSata nutzen möchtest musst du IMHO den "orangen" Anschluss mit einem Kabel brücken.

Es gibt für SATA noch Port-Multipler, in wie weit die funktionieren, weiß ich aber nicht.

Zitat

Original von plego

Ja, hilft auch, aber Ausschaltzeit muss >5 Minuten sein. Aus, 'ne Minute warten und wieder einschalten bringt nicht das gewünschte Ergebnis. Seltsam, muss was analoges sein

Ja, kann ich irgendwie bestätigen, bei mir war der Empfang damals nicht mehr möglich. Hab die Karte aus und wieder eingebaut und seitdem geht sie wieder. Vermutlich hätte es auch gereicht, das Board einfach stromlos zu machen. Hab nur einen Reboot, sowie ausschalten probiert (liegen dann die +5V Standby noch am PCIe an?)

Gruß
Roland

strange, also nachdem ich die Karte aus und wieder eingebaut habe, geht sie wieder (kann aber auch sein, dass es daran lag, weil ich das System dabei komplett stromlos gemacht habe)

Na ja, egal. Hauptsache die Karte ist nicht defekt

hmm, hab jetzt das System neu gestartet (hab ich gestern auch mehrmals gemacht, ehrlich) jetzt wird zwar das Modul wieder geladen, aber noch kein Empfang....

Da ich immer noch den GIT-Treiber von http://projects.vdr-developer.…/show/mediapointer-dvb-s2 verwendet habe, denke ich das hier irgendwo der Hund begraben ist.

Der aktuelle Treiber liegt ja jetzt hier (oder?)
http://www.linuxtv.org/wiki/in…Media-Pointer_MP-S2%C2%B2

Gruß
Roland

Meine Karte zickt seit gestern rum:
Bei mir erscheinen die fett markierten Zeilen wie hier nicht mehr im Log: http://www.vdrportal.de/board/…?postid=859797#post859797

Das Stv6110x Modul wird auch nicht geladen und "scan" sagt /dev/dvb/adapter0/frontend0 not found.

Hat vielleicht einer einen schnellen Tipp. Debug-Output liefere ich nach Mittag nach

Übrigens: kann ich eigentlich sicher gehen, dass ich nach "git pull" und "git diff", welches nichts anzeigt einen sauberen Stand aus dem Repository habe?

Mahlzeit.
Roland

Hier die Einträge im syslog

Dec 27 12:59:00 server kernel: [  213.586940] nGene PCIE bridge driver, Copyright (C) 2005-2007 Micronas
Dec 27 12:59:00 server kernel: [  213.587020] ngene 0000:02:00.0: PCI INT A -> Link[LN0A] -> GSI 19 (level, low) -> IRQ 19
Dec 27 12:59:00 server kernel: [  213.587052] ngene: Found Media-Pointer MP-S2ý DVB-S2 Twin Tuner
Dec 27 12:59:00 server kernel: [  213.588701] ngene 0000:02:00.0: setting latency timer to 64
Dec 27 12:59:00 server kernel: [  213.588868] ngene: Device version 1
Dec 27 12:59:00 server kernel: [  213.588908] ngene: Loading built-in firmware version 17.
Dec 27 12:59:00 server kernel: [  213.600345] FW 17 buffer config
Dec 27 12:59:00 server kernel: [  213.601741] DVB: registering new adapter (nGene)
Dec 27 12:59:00 server kernel: [  213.622282] stv090x_sleep: Set STV0900 to sleep
Dec 27 12:59:00 server kernel: [  213.622463] stv090x_read_reg: Read error, Reg=[0xf1b6], Status=-5
Dec 27 12:59:00 server kernel: [  213.622471] stv090x_write_regs [0xf1b6]: fb
Dec 27 12:59:00 server kernel: [  213.622694] stv090x_write_regs: Reg=[0xf1b6], Data=[0xfb ...], Count=1, Status=-5
Dec 27 12:59:00 server kernel: [  213.622702] stv090x_sleep: I/O error
Dec 27 12:59:00 server kernel: [  213.622709] stv090x_attach: Error putting device to sleep
Dec 27 12:59:00 server kernel: [  213.623027] DVB: registering new adapter (nGene)
Dec 27 12:59:00 server kernel: [  213.623897] stv090x_sleep: Set STV0900 to sleep
Dec 27 12:59:00 server kernel: [  213.624252] stv090x_read_reg: Read error, Reg=[0xf1b6], Status=-5
Dec 27 12:59:00 server kernel: [  213.624279] stv090x_write_regs [0xf1b6]: fb
Dec 27 12:59:00 server kernel: [  213.624471] stv090x_write_regs: Reg=[0xf1b6], Data=[0xfb ...], Count=1, Status=-5
Dec 27 12:59:00 server kernel: [  213.624499] stv090x_sleep: I/O error
Dec 27 12:59:00 server kernel: [  213.624505] stv090x_attach: Error putting device to sleep

werd mich dann mal auf die Suche machen...

Mit den smartmontools (smartctl -i /dev/sda) wird dir die Seriennumer ausgegeben. Diese mit der auf dem Aufkleber vergleichen.

Leider passiert es mir auch immer wieder mal, dass sich die Laufwerke vertauschen. Dies scheint ein generelles Problem/Feature von Sata + USB Laufwerken zu sein...

zum Kopieren würde ich übrigens ddrescue (nicht verwechseln mit dd_rescue) empfehlen. da aber keine badblocks drauf sein werden geht auch dd...

Gruß
Roland

Hmm, hab wieder nur die hälfte geschrieben, die techsolo-FB ist eine HID-FB (verhält sich wie eine Tastatur) und da ist halt der "*" mal bei SHIFT+8

und soweit ich es verstanden habe, braucht man da keine eigene lirc.conf.

ich hab diese hier: http://lirc.sourceforge.net/re…input/lircd.conf.devinput

Hallo,

ich versuch gerade LIRC einzurichten, dass es mit meiner Techsolo - FB funktioniert.
Soweit so gut, nur ein paar Tasten sind "doppelt" belegt.

z.B. gibt "irw" beim Druck auf die "*" Taste folgendes aus:

000000008001002a 00 KEY_LEFTSHIFT devinput
0000000080010009 00 KEY_8 devinput
0000000080010009 01 KEY_8 devinput

Wie bring ich das jetzt dem VDR bei?

geronimo, sry, der war nicht auf dich bezogen. (Hätte besser den Smiley verwenden sollen...)
Evtl war auch meine Fragestellung nicht ganz klar, Sparkie scheints aber jetzt verstanden zu haben

Zu deinen Bedenken: Die Cups-Konfiguration wird geändert. Die Device-URI lautet z.B. dann
tea4cups://socket://1.2.3.4:9100

Da Tea4Cups meine Anforderungen eigentlich erfüllen sollte, werde ich hier mal einen Versuch starten. Falls es kein python gibt (Der Server ist leider ne Marke Uralt...) dann muss wohl C herhalten...
(Was mir sowieso besser gefallen würde...)

Gruß
Roland

Ihr versteht mich glaub ich nicht richtig.

Mein Wrapperscript funktioniert "perfekt", hier kann ich jeden Parameter auswerten usw usf.

Ich kann nur nicht das gewrappede Backend (=socket) aufrufen, da in der

int main(int argc, char *argv[])

des (vorkonfiguriertem und für mich nicht änderbaren) Backends in argv[0] eben NICHT der Name des Programms, sondern die Device-URI erwartet wird.

Ich habe aber jetzt folgendes gefunden: http://www.pykota.com/software/tea4cups
Das ist eigentlich genau das was ich brauche, hier wird das folgendermaßen gemacht:

originalbackend = os.path.join(os.path.split(sys.argv[0])[0], self.RealBackend)
        arguments = [os.environ["DEVICE_URI"]] + sys.argv[1:]
...
                os.execve(originalbackend, arguments, os.environ)

Ich hoff jetzt mal, dass auf dem "Problemserver" python installiert ist...

Gruß
Roland

Also wenn ICH Cups richtig durchschaut habe, wird in der job.c das Backend (z.B. Socket) aufgerufen.

In der von dir erwähnten Codestelle wäre also:
command = /usr/.../socket
argv[0] = socket://ip:9100
argv[1..n]... uninteressant

Ich möchte jetzt "um" den Socket ein Wrapperscript basteln, damit ich die Daten abgreifen kann. Also ein einfaches Bash-Script. Die Device URI lautet dann z.B. socketwrapper://ip:port.

anstatt "cupsJob->socket" sollte dann der Codepfad "cupsJob->socketwrapper->socket" lauten

Variablenbelegung in Cups wäre dann:

command = /usr/.../socketwrapper
argv[0] = socketwrapper://ip:9100
argv[1..n]... uninteressant

Nun wird mein Wrapper-Script aufgerufen, dies schnappt sich die Daten und ruft dann das eigentliche socket-Backend auf.

in der 1.1er steht zum Parsen der URI folgendes

/*
  * Extract the hostname and port number from the URI...
  */


  httpSeparate(argv[0], method, username, hostname, &port, resource);

hier wird die URI eben in argv[0] erwartet. Ich rufe aber das Backend aus meinem Bash-skript auf, somit steht da der Name des Backends drin.
Ab der 1.2er machen sie das etwas intelligenter, was mir aber nicht viel hilft an dieser Stelle:

/*
 * 'cupsBackendDeviceURI()' - Get the device URI for a backend.
 *
 * The "argv" argument is the argv argument passed to main(). This
 * function returns the device URI passed in the DEVICE_URI environment
 * variable or the device URI passed in argv[0], whichever is found
 * first.
 *
 * @since CUPS 1.2/Mac OS X 10.5@
 */

-> Ich werd mir wohl oder übel einen Plan-B überlegen müssen .-(

ich wollte das Script in cups als Backend angeben.
Das Script sollte dabei wiederum ein anderes Backend aufrufen und nebenbei die Daten abzweigen.

im Wesentlichen schaut es so aus

#!/bin/bash
# Druckdaten wegkopieren
cp $6 /tmp/Datenmitschnitt/
...
export DEVICE_URI="socket://druckerIP:9100"
# Druckdaten an das Socket-Backend weiterleiten
./socket $1 $2 $3 $4 $5 $6

Das Script funktioniert auch unter neuerer Cups-Version, welche die DEVICE_URI und dann argv[0] auswertet. (Leider macht das die 1.1er noch anders)

Ich schau jetzt mal ob ich das als Filter implementieren kann, weil ich an der Bash aufgegeben hab, da ich denke, dass es nicht geht.

Ja, das mit dem Link würde funktionieren, allerdings kommen in der Cups-URI Schrägstriche vor. Also es muss definitiv so was wie "foo://xyz" oder "socket://1.2.3.4" gesetzt werden können.
Da die URI bei jedem Druckauftrag geschrieben werden soll, möchte ich da nicht wild auf der Platte rum schreiben.
Leider ist die Cups-Version so alt, dass die Umgebungsvariable $DEVICE_URI nicht vorrangig als URI ausgewertet wird, sondern $0
Ein Update ist nicht möglich. Ansonsten wäre es eh kein Problem.

in Cups wird das Script übrigens mit folgendem Code aufgerufen

...
      argv[0] = job->printer->sanitized_device_uri; // <-- Wie geht das in nem Bash script


      filterfds[slot][0] = -1;
      filterfds[slot][1] = -1;


      pid = cupsdStartProcess(command, argv, envp, filterfds[!slot][0],
                filterfds[slot][1], job->status_pipes[1],
                job->back_pipes[1], job->side_pipes[1],
                backroot, job->profile, job, &(job->backend));
...

Leider steht das Zielprogramm fest (ist ein altes Cups-Backend) und es erwartet in $0 einen Inhalt wie "foo://xyz"

$0 ist normalerweise der Name des Scriptes, d.h. wenn ich einen Link auf foo.sh mache (ln -s foo.sh bar.sh) und dann "./bar.sh" aufrufe, dann wird auch "./bar.sh" ausgegeben. (also der Parameter lässt sich modifizieren)

Dies wird soweit ich auch von busybox ausgenutzt, damit die nur 1 Binary brauchen

Hallo liebe Scriptexperten, ist es möglich per Bash irgendwie den Parameter $0 per Bash-Script zu setzen.

Ich hab z.B ein file foo.sh

#!/bin/bash
echo $0

Ein Aufruf von "./foo.sh" printet dann auch "./foo.sh"

Ich möchte jetzt in Etwa folgendes machen:
export $0 = "Hello World" ### mir ist klar das das nicht geht
./foo.sh

Und nun soll "Hello World" von foo.sh ausgegeben werden.

Gruß
Roland

Also ich hab gestern mal ~ 1 Std getestet
Umschaltzeiten SD 1-2 sec, Diseqc geht, abgestürzt ist mir auch noch nix, konnte sogar die Module mehrmals laden/entladen

HD konnte ich leider nicht testen, da das Xine-Plugin das nicht mitgemacht hat :-|

Könnte man durch Ausbau/Veringerrung der Delays im stv090x das Tuning noch schneller machen?

Und wo eird eigentlich das diseqc-Timing geregelt? Soweit ich weiß, benötigt ein Full-Diseqc Command ~150msec. Durch Abschalten oder Verwendung von mini-diseqc ließe sich hier evtl auch noch was optimieren

(ich muss aber jetzt erst mal vdr + xine + vdpau richtig zum laufen bringen bis ich wieder testen kann )

Gruß
Roland

diseqc hab ich mal kurz angetestet, mit "scan" kann ich nun zw. Astra/Eutelsat umschalten.

VDR kann ich grad nicht testen, weil wieder mal was nicht compiliert

gut gemacht

Wie oft kannst du die Module eigentlich laden/entladen? Bei mir gehts nach ner Weile nicht mehr, angeblich zu wenig RAM. Dies hängt meines Empfindens auch von der Dauer ab,wie lange das Modul geladen war. Evtl. ist da noch wo ein Puffer der nicht korrekt freigegeben ist...

Werd mich dann mal meinem Diseqc Problem widmen, vielleicht kann ich das auch noch lösen