Posts by tomglx

Bin jetzt endlich mal zum weiteren testen gekommen.
Ich habe einen vdr mit 1x ff 1.5, 1x tt 3200 und 2x ff 1.3 Karten.
Das ganze hängt an ankaro Multiswitchen die wiederum an zwei quattro LNBs
für Astra und Hotbird hängen. Kein Rotor im Einsatz.

Mit dem multiproto und multiproto_plus Treibern + vdr 1.7.0 habe ich nahzu keinerlei
Locking Probleme.

Mit dem s2-lipianin Treiber ist das ganz anders. Zumindest wenn man mal nach
szap-s2 geht. Auf der ff 1.5 bekomme ich nun keine Locks auf horizontaler
polarisation, dafür geht's auf vertikaler. Auf der TT3200 bekomme ich mit szap-s2
gar keinen Lock. Nun wirds komisch. Auf beiden ff 1.3 bekomme ich sofort und
problemlos Locks. Auf allen Kanälen, DVB-S2 mal ausgenommen.

Scheint wohl doch ein Problem des Treibers zu sein. Denn wenn ich bei szap-s2
mit der -l Option (LNB Type) rumspiele, bekomme ich zu Anfang einmal einen
Lock. Danach ist wieder Essig.

Hallo,

bei mir klappt's irgendwie nicht so richtig. Ich habe einen vdr 1.7.0
mit den extpatch 62 + s2-lipianin treiber am laufen. Ich bekomme
komischerweise überhaupt keinen Lock auf allen Sendern mit
vertikaler polarisation. Arte und ORF HD tuns auch nicht, obwohl
die auf horizontaler polarisation laufen. Premiere HD, Anixe und
Astra HD tun es aber.

Der Treiber hg clone ist von gestern Abend. derot Patches scheinen
da schon drin zu sein. Bekam entsprechende Meldungen beim
Versuch zu patchen.

Hat irgendjemand eine Erklärung für das Problem mit der vertikalen
Polarisation?

Gruss, Thomas

Hallo Thomas,

es bleibt auch bei mir dabei. Ich nehme 2x Bleche.

Gruss, Thomas

Hallo,
ich schlage mich seit einiger Zeit mit einem sporadisch auftretendem Problem
herum. Ich habe hier einen vdr mit einer FF 1.5, 2x FF V1.3 und einer TT
3200 Karte. Zus. noch eine reel eHD Karte.

Ich benutze den neuesten multiproto_plus Treiber aus dem hg repo. Darauf
läuft ein vdr 1.7.0 mit reelbox plugin.

Wenn ich Aufnahmen ansehe und zurück in den Live Mode wechsele, oder
einfach nur nach dem Umschalten, kommt es zu shortened Packets von
der V1.5 Karte. Das führt zu den üblichen TS Continuity und Repacker
Fehlern beim vdr. Tritt das Problem auf, bleibt es auch über folgende
zappings erhalten. Die Umschaltvorgänge gelingen aber. So viel ist aus
den Bild- und Tonfragmenten noch zu erkennen.

Ein Neustart des vdrs alleine beseitigt das Problem nicht. Ich muss noch
den dvb-ttpci neu laden, dann ist das Problem wieder weg. Ich hatte
schon Hitzeprobleme im Verdacht, aber warum hilft dann ein einfaches
neu Laden des Treibers? Außerdem habe ich testweise die Lüfter auf
volle Leistung gestellt. Die Temperatur ist zwar massiv runter gegangen,
aber das Problem nicht weg.

Hatte auch schon diverse andere HW Kollisionen im Verdacht. z. B.
mit dem i2c Treiber für das HW Monitoring. War es auch nicht.
Andere diseqc Konfiguration genutzt, wg. Tuning Problemen bei
der TT3200, hat auch nix genutzt.

Das Problem beschränkt sich auch immer nur auf eine Karte. Starte
ich Aufnahmen, die auch die anderen Karten einbeziehen, sind diese
in Ordnung. Schalte ich auf HD Känale, sind auch diese in Ordnung,
weil er ja da die TT 3200 nutzen muss. Schalte ich auf verschlüsselte
Kanäle muss er ebenfalls auf eine andere Karte und auch das geht.

Starte ich eine Aufnahme, nimmt er von der bewussten Karte auch
nur Schrott auf. Ein HW Tausch der Karten um deren Nutzungsreihen-
folge zu ändern, nutzt auch nichts. Das ganze kommt dann auch mit
z. B. einer FF V1.3 vor. Es ist immer die erste Karte, da der vdr diese
ja immer zuerst nutzt.

Der Treiber meldet übrigens nichts. Manchmal reist der Datenstrom
auch komplett ab und es kommt gar kein Bild mehr. Auch beim
multiproto Treiber läßt sich das reproduzieren.

Hat jemand irgendwelche Tipps, wie ich das weiter eingrenzen bzw.
lösen könnte? Hat jemand schon mal ähnliche Probleme gehabt?

Gruss, Thomas

Hi,

mich beunruhigt viel mehr, dass Klaus schon seit Monaten keine Updates
mehr für den vdr rausbringt. Wenigstens bei der 1.7.0 sollte sich doch mal
etwas tun, oder? Vielleicht eine 1.7.1?

Wenigstens Fehler könnten doch mal beseitigt werden.

Hallo GBruno,

völlig andere Baustelle. Ich habe auf einem Fedora 9 System
installiert. Deshalb meinte ich auch die dort vorhandenen
Distri Kernel. Mit dem ct-vdr gar nicht zu vergleichen. Darin
haben sie ja alles an, was es gibt.

Nur eben ich nicht, mit meinem vanilla kernel. Das war dann
auch der Grund und ebenfalls der Unterschied.

Gruss, Thomas

Hi,

ich hatte ähnliche Probleme. Lag an der Konfiguration meines
vanilla Kernels. Mit dem Distri Kerneln gings. Das brachte mich auf
die Spur.

Es fehlten Teile aus dem ACPI Support.
Es sollte beim dmesg auf jeden Fall
ACPI: (supports S0 S1 S3 S4 S5)
ACPI: RTC can wake from S4
erscheinen.

cat /sys/power/state sollte
standby mem disk
ergeben.

CPU Hotplug Support muss auch an sein.

Gruss,
Thomas

Hallo,

der Vor- und Rücklauf über die eHD ist bei mir nahezu unbenutzbar. Er ist
viel zu schnell und es werden deshalb nur wenige Bilder angezeigt. Es gibt
einen Haufen framedrops. Ist das normal, oder habe nur ich ein Problem?

Das Aktivieren der verschiedenen Vorlaufgeschwindigkeiten im vdr bringt
leider auch nicht viel Linderung.

Kann man das irgendwie bremsen?

Grüsse,
Thomas

thorsten.gehrig

char *XineLib::GetSetupLang() const
{
--> return "de";

Diese Zeile in XineLib.c eingefügt?

Quote

auf meiner eHD ist da bereits ein winckel mit gewinde auf der karte, da braucht es nur ein loch direkt auf dem blech

Ist auf meiner auch so.

Hallo,
zu meiner Konfig:
Kernel 2.6.25.13 vanilla mit rtc_cmos support und ohne enhanced RTC Support
alternativ
Kernel 2.6.25.11 aus der Distri (Fedora 9).

Wakeup on RTC Alarm im Bios habe ich aus. ACPI 2.0 Support ist an.
Wakup über die BIOS Einstellungen funktioniert, aus Linux heraus nicht.

Ich führe zum Testen aus:
echo 0 > /sys/class/rtc/rtc0/wakealarm
echo $(( $(date +%s) + 300 )) > /sys/class/rtc/rtc0/wakealarm

cat /proc/driver/rtc
zeigt auch die gesetzte Zeit.

Die BIOS Systemuhr läuft nach UTC Zeit, also - 2 Stunden. Im /proc/driver/rtc
zeigt er allerdings UTC + 2 Stunden als Jetztzeit an.

Der hwclock Befehl wird vor dem obigen Setzen ausgeführt. Die Variante im
System halt Skript habe ich bereits deaktiviert.

Was kann man tun? Hat vielleicht jemand eine nvram-wakeup Konfiguration
für das Board?

Gruss und vielen Dank im voraus,
Thomas

Hi,

ich würde auch eines abnehmen.

EDIT: OK. Ich erhöhe auf 2.

Gruss, Thomas

Ich kann da nur beisteuern, dass ich drei FF Karten habe. Zwei TT 1.3 und eine
TT 1.5. Wobei letztere die primäre Karte ist und die Kartennummer 3 hat. Diese
Karte ist auf 4 MB gemodded worden und läuft auch mit entsprechender FW.

Als Kernel kommt ein 2.6.25.2 zum Einsatz, der mit Tickless+1000Hz und
PREEMPT übersetzt wurde. Das beeinflusst das Threading Verhalten möglicherweise
erheblich und damit auch die Reproduzierbarkeit bei anderen vdr Installationen.

amair

Hallo,

der Fehler tritt logischerweise nur bei eingeschaltetem Anti-Aliasing auf, da
der Abbruch innerhalb der AntiAliasing Routine im font.c geschieht. Allerdings
ist diese nicht direkt schuld. Ihr werden Daten untergeschoben, die inkonsistent
sind. Das diese Inkonsistent sind, liegt eben daran, dass ein anderer Thread
dafür zuständig ist, die Daten bereit zu stellen, an denen die Routine abbricht.

Der Thread in dem die Routine abbricht, müsste länger warten. Tut er aber nicht,
weil ein Thread-Lock Problem da ist. Vermute ich jedenfalls.

Gruss, Thomas

Hallo,

ich muss meine Aussage zurücknehmen. Nachdem ich jetzt endlich mal Zeit zum
ausführlichen Testen hatte, ergibt sich eine andere Situation.

Selbst mit einem, bis auf die Mainmenuhooks, ungepatchten vdr, der nur mit
skinenigma, epgsearch und remote plugin läuft, tritt der Fehler reproduzierbar
auf.

Erst wenn man skinenigmang wegläßt, geht auch der Fehler weg.

Ich vermute also ein Problem mit dem Threadhandling vom skinenigmang. Das
habe ich seit anfang an im Verdacht gehabt, habe mich beim Testen nur selbst
ausgetrickst.

Gruss, Thomas

Hi,

denselben Fehler habe ich auch. Ich habe es soweit eingrenzen können, das es
bei mir ein Patch aus dem VDR Extensions Pack 60 ist. Ich habe nur noch
nicht rausfinden können, welcher.

Es wäre schön, wenn du bestätigen könntest, ob du einen gepatchen oder
ungepatchen vdr einsetzt und ob sich das Problem mit einem ungepatchten
vdr ebenfalls nicht reproduzieren läßt.

Gruss, Thomas

Hi,

wahrscheinlich übersehe ich es bloss, aber wie erhält man die originale
Aufnahmeübersicht zurück? Auch nach dem Entfernen einer CD/DVD, die
originale vdr Aufnahmen enthält, setzt das Plugin die Aufnahmeübersicht
nicht zurück.

Ich setze mediad 0.1.0 mit vdr 1.6.0 auf Fedora Core 8 ein. Da ist dann
hal 0.5.10 im Einsatz. Das sollte doch die Anforderungen erfüllen. Der
hald läuft und erkennt neu eingelegte Medien korrekt. Ich werde ja
auch jedesmal gefragt, ob ich Abspielen möchte.

Was übersehe ich? Bin für jeden Tipp dankbar.

Gruss, Thomas

Hi,

noch ein Problemchen. Bei den Previous Wareagle Icons muss:
#define ICON_BAR_FULL 0xFF
durch
#define ICON_BAR_FULL 0x7F
ersetzt werden. Sonst funktioniert die Progressbaranzeige
nicht richtig.

Gruss, Thomas

Hi,

danke für die Hilfe. Vielleicht hätte es ein
#if VDRVERSNUM > 10500
...
#else

aber auch getan.

Gruss, Thomas

Hallo,

gute Arbeit.

Leider zeigt es mir die Wareagle Icons unter vdr 1.4.7 nun nicht mehr
an. Mit der 0.9.23 ging das noch.

Muss man noch etwas tun?

Gruss,
Thomas