Posts by schubsi

GuteMine

Danke für die Tipps, habe das Skript etwas umgemodelt:

1. Das Auslesen des LED-Status erfolgt nur 1 mal pro Durchlauf

#!/bin/sh
while [ 1 ]; do


led1=`cat /proc/tRNA/led/ledgr`
led2=`cat /proc/tRNA/led/ledrd`

2. Bevor ein Schreibzugriff erfolgt, wird erst verglichen, ob der gewünschte Wert nicht bereits gesetzt ist:

if [ "$led2" = "0" ]; then
            # do nothing
            echo >/dev/null 2>&1
        else
            echo 0 > /proc/tRNA/led/ledrd
        fi

3. Bei Status Aufnahme wird nicht Wert 2 (für Blinken) geschrieben, sondern Wert "1" für Dauerleuchten. Da das adenn.ko beim Zustand "Blinken" ständig Schreibzugriffe macht, kam es zu den beschriebenen Fehlern der Smartcard.

Ich hatte die Befürchtung, dass bei massiven fehlerhaften Schreibzugriffen auf die Smartcard diese geschrottet werden könnte, daher verzichte ich lieber auf das informative Blinken.

Ferner habe ich nun die Abo-Karte mittels Smartreader+ an meinen Linuxserver gekoppelt, um mal zuschauen, ob die Probleme (Aussetzer) weg sind, wenn der interne Kartenleser nicht mehr verwendet wird. Hatte jedoch noch keine Zeit, dies ausgiebig zu testen...

-==[Schubsi]==-

Verantwortlich für die Aussetzer ist offensichtlich das adenin.ko, das Modul, welches die LEDs ansteuert.
Es kollidiert offensichtlich beim Hardwarezugriff mit den schreibenden Zugriffen der CAM /dev/sci0)

Nur wenn die Schreibzugriffe ganz abgestellt werden, gibt es keine Aussetzer mehr. Hab mir erstmal damit beholfen, die Schreibzugriffe zu minimieren und den Status der roten LED auf Dauerleuchten statt blinken zu setzen.

Ich werde es mal beobachten...

-==[Schubsi]==-

adenin

Quote

Das blinken wird sicher nicht langsamer

Genau das war mein Ansatz: Auch wenn es keine "Statusänderung der Box" gibt, wird permanent geschrieben, mein Plan:

Wenn led status 1 hat und es soll "1" geschrieben werden, dann lass es einfach sein.

Ich erhoffe mir durch weniger Schreibzugriffe auf /proc/tRNA/led/ledxx weniger Konfliktsituationen, während emms der Karte in /dev/sci0 verarbeitet werden, weil stattdessen z. B. nur sleeps durchgeführt werden.

Ich habe gestern auf der Kommandozeile mit

if [ 'grep 1 /proc/tRNA/led/ledgr | wc -l' -eq 0 ]; then echo 'ja';fi

experimentiert, erhalte aber den Fehler

[: grep 1 /proc/tRNA/led/ledgr | wc -l: bad number

Ist abgeschrieben, ohne zu wissen, was ich da eigentlich mache, schon klar, aber ich habe ja schon zugegeben, dass ich mit der shell zu wenig Erfahrungen habe...

Deshalb ja meine Bitte, mir nen Tipp zu geben, wie ich den Status von /proc/tRNA/led/ledxx mit einer if-Anweisung abfragen kann, um dann abzuzweigen...

GuteMine

Quote

mach mal top in telnet um zu sehen wer dir da wirklich die CPU wegfrisst.

Habe ich bereits gemacht, keine Auffälligkeiten erkennbar, habe auch keine "aufregenden" Sachen zusätzlich zu laufen, CCcam macht im Höchstfall 13% load, der Rest so gut wie gar nichts.

Meine Analyse ergab, wenn das recorderled.sh nicht läuft, bleiben auch die Aussetzer aus, ergo könnens eigentlich nur die regelmäßigen Schreibzugriffe auf die LEDs sein, die da stören. Und die könnte man reduzieren, weil sich der Status während einer Aufnahme selten ändern dürfte (bis auf seltenes EIN/AUS der Box)...

Komme alleine nicht weiter, Hühühühülfe!

-==[Schubsi]==-

adenin

Quote

schubsi
Ich denke mal eher, das cccam sich daran stört, das noch jemand das Netzwerk benutzt.
Da kann ich aber nichts daran ändern.

Du meinst den WGET-Befehl? Ansonsten war bei meinen Tests nämlich kein weiterer Netzwerkzugriff (DBOX2 war aus).

Ich habe die Hoffnung, dass der Schreibzugriff auf die LED /proc/tRNA/led/ledxx im Sekundentakt stören könnte, genau dann wenn auf /dev/sci0 geschrieben werden soll... (das wäre die Rettung für dieses Feature).

Ein Workaround wäre, den Status von /proc/tRNA/led/ledxx vorher abzufragen, bevor ein erneuter Schreibzugriff erfolgt. Allerdings lege ich mir zur Zeit bei der IF-Zeile die Karten, hab zu wenig Erfahrung mit der Shell :-/

Kannst Du mich bitte in die richtige Richtung "schubsen"?

-==[Schubsi]==-

Moins...

Ich muss den Thread hier nochmal aufwärmen:

Seit dem Kartenwechsel von P* damals (letztes Jahr) gabs immer wieder mal Aussetzer (5-7 Sekunden) bei Aufnahmen, mal häufiger, mal seltener.

Habs nun analysiert und festgestellt, dass es mit großer Wahrscheinlichkeit an der blinkenden LED liegt. Entferne ich das Skript, kann ich - zumindest vorerst - keine Aussetzer mehr feststellen.

Die von mir verwendete CCcam (mit -dv im Telnet gestartet) meldet, dass bei diesen Aussetzern die Verbindung zum /dev/sci0 verloren geht, der Kartenleser wird resettet, die Karte neu gefunden und wieder hinzugefügt, dann funktionierts wieder ne Weile, mal länger, mal kürzer. Ich vermute nen Zusammenhang zwischen dem Blinken (Zugriffe auf /dev/tRNA) und den Zugriffen auf das /dev/sci0 (vermutlich schreibend - also EMMs).

Vor dem Kartenwechsel war es deutlich seltener, dass solche Aussetzer auftraten, da ist es mir nie aufgefallen, aber seit die Schlüsseldaten häufiger wechseln (früher xx Sekunden, jetzt 7 Sekunden - Quelle weiß ich nicht mehr, habs mal irgendwo aufgeschnappt), passierts immer häufiger, letztens 5 mal in einer 45 minütigen Aufnahme, das ist ärgerlich, weil die Aufnahmen zerhackstückt werden.

Kann das jemand nachvollziehen und/oder bestätigen?

Schade, war ein witziges und informatives Feature!

-==[Schubsi]==-

Moins...

Keine Ahnung, obs mit ner Sat-Abo-Karte auch so problemlos funktioniert, aber meine K02 (Kabel) Karte funktioniert, allerdings mit ner alternativen Software, nicht mit der Standard-Firmware...

-==[Schubsi]==-

Hi adenin

Quote

Original von adenin
Noch ein paar Verbesserungen.
...
Hab noch mal alles zusammen gepackt und die Source dazu gelegt.

Cool! Klasse! Danke!

Im Anleitungs-PDF ist ne Winzigkeit verkehrt: Die modules.dep liegt eine Ebene tiefer, also /lib/modules/2.6.12, war aber kein Problem...

TOP! Krissu 100 Punkte von mir!

-==[Schubsi]==-