Beiträge von olebowle

  • systemd: vdr.service

    Also bei mir sieht die vdr.service unter Archlinux wie folgt aus:



    Dazu noch folgende udev-Regel:

    Code
    SUBSYSTEM=="video4linux", TAG+="systemd"
SUBSYSTEM=="dvb", TAG+="systemd"


    Und es tut, wie es soll.

  • [HOWTO] Pearl DPF Easy Hacking

    Hmm, was soll ich sagen: Mit einer Ubuntu 11.04 Live-CD zeigte das Display richtig an.
    Also hab ich das Paket unter Arch jetzt nochmal neu gebaut und installiert, um die Compilerausgaben zu vergleichen.
    Dann nochmal probeweise getestet und jetzt läuft es auf einmal??


    Ich versuch die Situation nächstes Wochenende am htpc nachzustellen, da ist nämlich noch das alte Paket drauf.


    Sorry für die Unannehmlichkeiten.

  • graphlcd (base, vdr-plugin) touchcol branch (archiv)

    Das Testbild wird richtig angezeigt. Ich kann mir schlecht vorstellen, dass alle 3 LCDs denselben Treffer haben. Zumindest will ich das mal nicht hoffen.


    Als Firmware für linkdelight_3 hab ich folgendes Binary von dir benutzt: [HOWTO] Pearl DPF Easy Hacking
    Ich hab die Firmware nämlich nicht bauen können. Zunächst mal musste ich den angehängten Patch anwenden. Aber selbst dann bekomme ich beim buildall-Skript:

    Code
    Building linkdelight_3
cat: .buildno: Datei oder Verzeichnis nicht gefunden
Makefile:277: *** missing separator.  Schluss.
cat: .buildno: Datei oder Verzeichnis nicht gefunden
Makefile:277: *** missing separator.  Schluss.


    und das vermutlich bei allen LCD-Targets.


    Hier mal die gesamte Abfolge:
    - svn co https://dpf-ax.svn.sourceforge.net/svnroot/dpf-ax
    - cd dpf-ax/trunk
    - Patch anwenden
    - make (siehe angehängtes build.log)
    - cd fw
    - via Menü verbinden
    - sudo python2 identify.py /dev/sr1
    - sudo python2 fulldump.py /dev/sr1
    - via Menü ausschalten
    - Menü halten + Reset
    - anstecken
    - sudo ./hiddetach
    - sudo python2 restore.py ~/Desktop/fw_disp_linkdelight_x.bin -f (das ist wiederum dein Binary)


    Um auszuschließen, dass ich vielleicht doch eine neuere Originalversion hab, hier mal die md5sums der fulldumps:

    Code
    d19a80d1eda22dad909b3a980b7008f9  linkdelight_2_full_backup.bin
b4d35f6b9fd578242a15a3529d4a4823  linkdelight_3_full_backup.bin


    Wenn ich jetzt doch aus Versehen Version 2 und 3 vertauscht hätte (was ich bezweifle), würde das den Fehler erklären bzw. kann ich ohne Probleme einfach mal die andere Version flashen?


    Edit:
    Es hat ein TAB in Zeile 277 des Makefiles gefehlt.
    Das mit dem Bauen des Binaries wird hier unter Archlinux ohnehin nicht einfach. Denn obwohl ich sdcc installiert habe fehlt mir sowohl asx8051, als auch aslink. Ist das Binary vom o.g. Link aktuell?

  • graphlcd (base, vdr-plugin) touchcol branch (archiv)

    Hallo,


    ich bin weiter gekommen.
    Ich habe momentan keinen Zugang zum HTPC, deswegen konnte ich auch nur graphlcd-base testen.
    Das Problem scheint also nicht im Plugin zu liegen. Der Fehler zeigte sich mit showpic einfach nicht bei kleinen Bildern.
    Hab mit folgendem Befehl ein Schachbrettmuster erzeugt und angezeigt:

    Code
    convert -size 320x240 pattern:checkerboard -colors 2 -colorspace gray -normalize chessboard.png && showpic -c /etc/graphlcd.conf -d ax206dpf chessboard.png


    Vorher hab ich graphlcd-base mit imagemagick-support kompiliert.
    Die beiden angehängten Bilder zeigen, wie es ist (mit linkdelight_3) bzw. wie es sein sollte.
    Ich habe mal ausgezählt, ab welchem Pixel das Muster verschoben ist und siehe da: 8193 = 2^13 + 1.


    Ich hoffe das hilft euch weiter den Bug zu finden, wo auch immer er liegen mag.


    Vielen Dank soweit!
    olebowle

  • graphlcd (base, vdr-plugin) touchcol branch (archiv)

    Hallo,


    serdisp hatte ich vorher noch gar nicht installiert. Es reicht doch graphlcd-base und das graphlcd-Plugin?
    Jedenfalls hab ich es jetzt mal mit SDL-Support gebaut. Als Fenstermanager hab ich openbox benutzt. Softhddevice läuft jetzt also in einem Fenster. Allerdings bekomme ich aller 5 Sekunden folgende Fehlermeldung:

    Code
    Oct 28 11:24:31 localhost vdr: serdisp_directgfx_init(): unable to initialise SDL: Unable to open a console terminal


    und es popt auch kein neues Fenster auf.


    Hier nochmal ein Start/Stop-Vorgang mit den interessanten Stellen:


    Wie auf den Bildern zu sehen ist, baut sich die Menüstruktur richtig auf, wenn ich über die einzelnen Einträge springe. Wenn ich dann von ganz unten nach oben springe ist das Bild wieder chaotisch.

  • graphlcd (base, vdr-plugin) touchcol branch (archiv)

    Hallo,


    ich habe jetzt meine ersten Gehversuche mit graphlcd unternommen. Ich besitze zwei linkdelight_2 und ein linkdelight_3. Alle sind neu geflasht. Da der master branch nicht mehr baut hab ich touchcol benutzt. Alle LCDs haben eine fehlerhafte Darstellung (siehe Anhang) sowohl mit dem touchcol, als auch dem default skin.


    Der Aufruf im VDR erfolgt mit:

    Code
    -P "graphlcd -c /etc/graphlcd.conf -d ax206dpf"


    Die interessanten Stellen in /etc/graphlcd.conf sind:

    Code
    WaitMethod=3
WaitPriority=0
[ax206dpf]
Driver=ax206dpf


    Mit dem Aufruf

    Code
    showpic -c /etc/graphlcd.conf -d ax206dpf -u -i /var/lib/vdr/plugins/graphlcd/logos/replay/replay-file_l.glcd


    erhalte ich aber beispielsweise ein ordentliches Logo in der Ecke rechts unten. HAVE_AX206DPF_EXPERIMENTAL=1 ist beim Bauen auskommentiert worden. Die Akkus sind momentan noch dran. Ich vermute der Fehler liegt irgendwo im Plugin. Ist der Fehler bekannt oder hab ich etwas übersehen?


    Besten Dank im Voraus,
    olebowle

  • [softhddevice]Zischen beim Umschalten

    Hab am WE mal bisschen bisection betrieben. Bis 8039e8ae ging alles wunderbar, danach wurde es jeweils bei Steroton nach 1-2 Sekunden stumm. Ab der Revision kam ja Normalization hinzu, also nochmal schnell die Einstellungen gecheckt und siehe da Normalization war an (SoftVol aus), also ausgemacht und dann wurde es zumindest nicht mehr stumm. :)
    BTW: Funktioniert Normalization nicht ohne aktiviertes Softvol?


    Dann noch mit den AES-Parameter gespielt und jetzt (-a iec958:AES0=0x4 -p iec958:AES0=0x6) kommt nur noch selten ein kleines Störgeräusch beim Umschalten. Die Lautstärker des Stereotons hab ich auch noch an AC3 angepasst und jetzt ist es mit aktuellem Git top!


    Vielen Dank johns! :tup

  • [softhddevice]Zischen beim Umschalten

    Note: Ich habe momentan keinen physischen Zugriff zum System, deswegen ist es schwierig eine detaillierte Beschreibung abzugeben.


    Ich hab es auch mit 32527f83 testen lassen, da besteht dasselbe Problem beim Umschalten. Zusätzlich läuft bei einigen Sendern mit MP2 Audiospur (z. B. MDR und VOX), der Ton kurz an (1-2 Sekunden) und dann ist es stumm. Der Ton wird per Toslink an einen externen Verstärker übertragen und Passthrough ist aktiviert. Ist das Problem bekannt? Hab deshalb erstmal wieder ein downgrade auf 0.5.0 gemacht.


    Nächstes Wochenende kann ich hoffentlich eine detailliertere Beschreibung liefern.

  • [softhddevice]Zischen beim Umschalten

    Das Krachen hab ich bei meinem Receiver mit Version 0.5 und Passthrough auch.
    Zwischenzeitlich hab ich als Workaround bei meiner Harmony ein Makro eingerichtet, das vor dem Umschalten den Ton stumm schaltet. Das funktioniert aber auch nicht wirklich gut.
    Ich wäre froh, wenn du das Problem direkt im Plugin beseitigen könntest.

  • [Satnews] Astra-Transponder für HD-Kanäle der ARD stehen fest

    Zitat von olebowle


    Das Phänomen kann ich hier nachvollziehen. Das betrifft allerdings nur die ZDFvision-Kanäle aus holymoly's Liste. Die Bandbreite ist laut femon in gleicher Größenordnung wie bei den anderen HD-Kanälen. Die werden vermutlich noch mit dem Encoder spielen.


    OK, das war doch nicht deren Schuld. :] Eine ZDF-HD Aufnahme von heute wurde am PC korrekt abgespielt. Hab dann mal von xineliboutput auf softhddevice gewechselt (hatte ich ohnehin schon eine Weile vor) und jetzt läuft es top.

  • [Satnews] Astra-Transponder für HD-Kanäle der ARD stehen fest

    Zitat von Chickie

    Hi,


    Ich hab die Kanäle, wie von holymoly angegeben, zu meiner channels.conf hinzugefügt. WDR HD funktioniert, die anderen Kanäle teilweise aber gar nicht, teilweise sehr verpixelt, als würden sie mit extrem reduzierter Bandbreite übertragen. Ist das bei euch auch so, d.h. die drehen da noch rum?


    best,
    Chickie


    Das Phänomen kann ich hier nachvollziehen. Das betrifft allerdings nur die ZDFvision-Kanäle aus holymoly's Liste. Die Bandbreite ist laut femon in gleicher Größenordnung wie bei den anderen HD-Kanälen. Die werden vermutlich noch mit dem Encoder spielen.

  • [0.4] Nach Upgrade vom 13.03 Empfangsprobleme durch LNB-Sharing und Standbild!

    Hi,


    Zitat von mini73

    Moin!
    Vorübergehend kannst du in der order.conf aus dem Sternchen ein Minus vor dynamite machen, dann könntest du nur das Problem haben, dass der vdr schneller als deine DVB-Karten starten. Aber das wirst du dann feststellen.


    Super genau das war es. Scheint jetzt stabil zu laufen. Die beiden Tuner der DVB-Karte werden rechtzeitg erkannt. Femon läuft auch wieder.


    Vielen Dank!

  • [0.4] Nach Upgrade vom 13.03 Empfangsprobleme durch LNB-Sharing und Standbild!

    Hallo,


    auch ich bin auf testing-vdr gewechselt, um die Probleme mit dem DeviceBonding zu beseitigen. Allerdings besteht das Problem mit lost lock und timed out frontends zumindest direkt nach dem Start weiterhin. Vor allem verwundert mich:

    Code
    Mar 23 07:48:07 htpc vdr: [1142] ERROR: device '2' in device bondings '1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0' is not a cDvbDevice


    Wenn ich daraufhin in die LNB-Einstellung gehe und die Voreinstellung bestätige, ohne etwa zu ändern führt der VDR das DeviceBonding durch:

    Code
    Mar 23 08:26:52 htpc vdr: [1949] Text2Skin: menu display update thread started (pid=1168, tid=1949)
Mar 23 08:27:07 htpc vdr: [1168] OSD size changed to 1920x1080 @ 1
Mar 23 08:27:07 htpc vdr: [1168] saved setup to /var/lib/vdr/setup.conf
Mar 23 08:27:07 htpc vdr: [1168] tuner 1/0 bonded with tuner 0/0
Mar 23 08:27:07 htpc vdr: [1168] device 2 bonded with device 1


    Nun lässt mich VDR auch nur diejenigen Kanäle anwählen, welche auf derselben Ebene sind. Dies war zuvor nicht der Fall: Ich konnte jegliche Sender wählen, was natürlich zu Problemen mit nur einem Kabel führt.


    Dummerweise kann ich seit dem Wechsel auf testing-vdr nicht mehr auf femon zugreifen, folgende Meldung wird im syslog ausgeben:

    Code
    Mar 23 08:37:08 htpc vdr: [1168] ERROR: cFemonOsd::Show() cannot open frontend device.


    Wie es scheint, gibt es auch nach dem Bonding weiterhin Probleme, da ich soeben erneut timeoouts bekommen habe:

    Code
    Mar 23 08:52:50 htpc vdr: [1523] frontend 1/0 timed out while tuning to channel 0, tp 112663
Mar 23 08:52:50 htpc vdr: [1523] tuner 0/0 is now bonded master
Mar 23 08:52:59 htpc vdr: [1314] frontend 0/0 timed out while tuning to channel 0, tp 112663
Mar 23 08:52:59 htpc vdr: [1314] tuner 1/0 is now bonded master


    Hier noch meine /var/lib/vdr/setup.conf:


    Note: Das ist mein erster HTPC, den ich erst seit ein paar Tagen am Laufen hab. Ich kenne also nur das fehlerhafte Verhalten bezüglich des DeviceBondings.


    Grüße olebowle


    PS: Hier noch mein syslog: http://pastebin.com/vH8JDizQ