Posts by zirias

    Hat damit zu tun, dass manche hier der Meinung sind, irgendwelche Drittquellen für Debian verwenden zu MÜSSEN. Nix gegen das, was es da so alles gibt, aber ich habe noch nie einen zwingenden Grund dafür erlebt, daher einfach IMMER erstmal die original Debian-Pakete ausprobieren wenn etwas nicht funktionieren mag ;)

    Auch wenn DAS jetzt mit yaVDR gelöst ist nur kurz zum OP -- mit wheezy hab ich es zwar noch nicht probiert (aktuell kein Bedarf, habe noch einen Pr****** Gutschein rumliegen, bezweifle aber ein wenig, dass Sk* den noch einlöst *g*), aber bisher hatte ich NIE Schwierigkeiten, das "ominöse Plugin" mit den originalen Debian-Paketen in Betrieb zu nehmen, eben über "debianize-vdrplugin" oder so ähnlich. Drittquellen eigentlich unnötig. Sollte das mit wheezy wirklich anders sein?

    Komisch nur, dass man die Symlinks selber bauen muss. Kann man nicht einfach irgendwie eine 32bit-Version von "ldconfig" laufen lassen?


    Oh mann ... ich glaube DAS könnte tatsächlich der Kern des Übels sein. Man braucht keine 32bit-Version von ldconfig, ldconfig kommt problemlos mit multiarch klar. Nur: Wenn die Pfade, in denen die Dist 32bit-libraries ablegt, nicht in ldconfig eincompiliert sind, müssen sie explizit in /etc/ld.so.conf (bzw in /etc/ld.so.conf.d/*) genannt werden. Wahrscheinlich fehlt das :)


    Alternativ kannst du natürlich auch die Ubuntu VDR Pakete nutzen.


    Ich würde empfehlen, es IMMER erst mal mit den Paketen der Distribution selbst (falls in der gewünschten Version verfüghbar) zu probieren. Wenn DAS nicht geht, kann man immer noch andere Dinge versuchen :)


    Würde mich wundern, probiere es doch einfach mal aus "man apt-get -> --simulate"


    Würde mich ebenfalls wundern. Bei Debian ist es definitiv NICHT so, und ich kann mir nicht vorstellen, dass sich die Paketabhängigkeiten da so stark unterscheiden. Achja, NUR um herauszufinden, was mitinstalliert würde, braucht man nicht zu simulieren -- das wird sowieso vorher aufgelistet und man muss bestätigen :)

    Nach ZWEI Wochen bis zur absoluten Verzweiflung zurückdrehen, backup, vdr-sxfe selber bauen und was nicht alles, versuche ich mich jetzt an einer Neuinstallation mit Debian Wheezy.


    Das ist wahrscheinlich die sinnvollste Version.


    Quote

    ### vdpau-va-driver ###
    Installiert: 0.7.3-2
    Kandidat: 0.7.3-2 500 http://ftp.de.debian.org/debian/ wheezy/main amd64 Packages


    Vermutlich überflüssiges Paket. vdpau wird direkt viel besser unterstützt als über den umweg va-api. Schaden sollte es aber auch nicht.


    Quote

    Die Hauppauge Fernbedienung lässt sich nicht ordentlich anlernen, manche Tasten werden nicht erkannt.
    Ich vermute, die Empfindlichkeit des remote-plugin ist nicht richtig eingestellt.
    [...]


    Vorschlag: Mach einen Thread im Fernbedienungs-Forum mit ALLEN Einzelheiten (wie angeschlossen, welche Treiber geladen, lirc, ...?) Gibt dort Mitglieder, die anscheinend im Zusammenhang mit Fernbedienungen alles schon mal gesehen haben :)


    Quote

    Die Energiespar-Optionen vom Wheezy lassen sich nicht vollständig abschalten, in den Auswahllisten fehlt "nie", was dazu führt, daß nach spätestens 60min der Bildschirm schwarz wird.


    Tja, was sind denn die Optionen "von Wheezy"? Bei einem Desktop würd ich auf KDE oder Gnome tippen, aber du meinst wahrscheinlich was anderes?


    Quote

    Warum der NVIDIA-Treiber auch den RT-Kernel installiert (inux-image-3.2.0-3-rt-amd64) habe ich auch nicht wirklich verstanden.


    Du hast nvidia-kernel-3.2.0-3-rt-amd64 installiert. Installiere stattdessen nvidia-kernel-3.2.0-3-amd64 und alles ist gut (das Kernel-Modul muss eben schon zum Kernel passen). Ich glaube in der Tat nicht, dass ein rt-Kernel eine gute Wahl für einen VDR ist.


    Quote

    Im Wheezy gedit lässt sich der aumatotische Zeilenumbruch nicht abstellen, was beim Dreck-und-Drop-klicken von Checklisten sehr fiese Fehler produziert.
    (zweite Hälfte einer Zeile ist umgebrochen und wird beim tripple-klick nicht mit selektiert)


    Verstehe das jetzt nicht ganz, aber es gibt SO viele editoren. Findest sicher einen, der sich so verhält, wie du das magst.


    Quote

    ALLE Buchstaben im Wheezy sind wesentlich zu groß (gedit, Terminal, etc.)


    Sollte man doch einstellen können? Vielleicht wird die Auflösung (dpi) falsch erkannt. Oder die Schriften SOLLEN so groß sein und du verwendest den Konfigurations-Verhinderer "Gnome".


    Hm, wenn Du mal vdpau ausprobieren würdest, würde sich vieles von selbst ergeben ;)


    Hatte ich schon, allerdings damals noch mit squeeze -- das Vorgänger-Board hatte nämlich einen Nvidia Chip. "Wuhduh" war da trotzdem nichts, Treiber und vdpau libs installieren, --video=vdpau und gut. Schreib doch mal, was du so seltsames machen musstest damit es läuft? Ja, speziell die Kombination wheezy, vdr-sxfe und vdpau habe ich bisher nicht getestet und aktuell auch keine Möglichkeit dazu wegen Hardware.


    Quote

    Habe neue Punkte entdeckt:
    ... wobei ich denke, dass die nicht wheezy anzulasten sind.
    Derzeit ist es so, dass vdr-sxfe nur noch 3 CPUs verwendet. Die 4. dümpelt im idle vor sich hin.


    Wenn das ein Problem ist muss auch irgendwas anderes im argen liegen. vdr-sxfe hab ich mir was das angeht nie angeschaut, kann ich heute abend mal machen -- allerdings hab ich vor kurzem mit mplayer getestet, um zu sehen was vaapi bringt: Der decodiert bei mir bluray offenbar auf EINEM Kern (Quadcore CPU), den er ohne vaapi mit ca 85% belastet, mit vaapi sind es noch knapp 20%. Ich meine daher, vdr-sxfe dürfte eine halbwegs aktuelle CPU nicht allzusehr fordern, besonders nicht mit vdpau.


    Zum Backtrace folgendes:
    - Der crash passiert in der libGL.so.1 -- wenn du den nvidia-Treiber installiert hast ist das die von nvidia, closed source. Muss aber nicht unbedingt was heißen
    - "/usr/local/bin/vdr-sxfe-II" ?? Selbst compiliert? Probier doch bitte mal einfach die ORIGINALEN wheezy Pakete, ich kann mich nur wiederholen, die funktionieren einwandfrei.
    - Du hast offenbar Pulseaudio aktiv. Versuch mal, es zu deinstallieren -- bei mir hat das schon öfter Probleme gemacht, ein "nacktes" ALSA allerdings, bei Bedarf mit dmix, hat bisher immer gut funktioniert.
    - Der Nvidia-Treiber ist veraltet, in wheezy aktuell ist Version 304.48-1. Hast du den etwa "manuell" installiert? Falls nicht, einfach mal ein aptitude dist-upgrade machen. Falls doch -- deinstallieren, hoffen dass kein Müll zurückbleibt, offizielle wheezy-Pakete installieren.


    Sorry, aber ich werd das Gefühl nicht los, dass an deiner Installation etwas vermurkst ist. Grundregel für ein stabiles Debian-System: Bei den offiziellen Paketen bleiben so weit das nur möglich ist, nicht-Debian Dinge NUR in /usr/local oder /opt.

    Wozu überhaupt noch automatisches fsck? Ich schalte das immer ab. Mal davon ausgehend, dass das eingesetzte journaling fs stabil ist und korrekt arbeitet:

    • ohne write barriers kann noch ein Stromausfall im Betrieb für ein beschädigtes fs sorgen. Das kriegt man allerdings mit und kann dann manuell "fscken" :)
    • mit write barriers bleibt nur noch das Risiko eines Hardware-Schadens. Habe bisher einmal erlebt, dass sich eine Platte ohne Vorwarnung durch S.M.A.R.T. verabschiedet. Das war EXTREM ärgerlich, aber ich wage mal zu bezweifeln, dass ein fsck alle 30 mounts hier was gebracht hätte, das ist wohl eher unwahrscheinlich.


    Nur mal so als Anregung, für Datenverluste aufgrund dieser obszönen Idee übernehme ich natürlich keine Haftung :)

    So, da man hier ja doch oft auf Leute trifft, die auch Dinge abseits des VDR wissen: Habe folgendes diesmal sehr unwichtiges Problem. Zu reinen Testzwecken hab ich ein selbst aufgebautes Mini-GNU/Linux in einen Windows 7 Virtual PC installiert und dort ein Linux 3.5.2 mit so vielen Modulen wie nur möglich compiliert -- einfach mal sehen wie weit man es treiben kann.


    Beim Boot passiert jetzt folgendes: ata_piix meldet "Hyper-V detected" und fühlt sich deshalb nicht für die virtuelle Platte zuständig sondern will das dem hv_storvsc überlassen. Die ganzen hv_* Treiber (hv_storvsc, hv_netvsc, hv_util, ...) lassen sich aber alle nicht laden, jeweils mit der Meldung "Connection timed out" nach einiger Zeit. Ich vermute da wird versucht, über irgendwelches shared memory mit dem Host zu kommunizieren. Booten kann ich im moment mit einem Modul-Parameter für ata_piix, so dass sich das Modul doch für die Platte zuständig fühlt.


    Jetzt weiß ich natürlich, dass es Hyper-V nicht für Windows7 gibt. Die Frage ist nur: Ist damit vielleicht nur das Gesamtprodukt gemeint und die paravirtualisierten Geräte sollten trotzdem in Virtual-PC genauso gehen, schließlich meldet mein Linux ja "Hyper-V detected"? Oder ist diese Meldung ein Irrtum?

    Folgende Hardware:
    "AMD A6-3670 APU with Radeon(tm) HD Graphics", darin enthalten:
    00:01.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI BeaverCreek [Radeon HD 6530D]
    00:01.1 Audio device: Advanced Micro Devices [AMD] nee ATI BeaverCreek HDMI Audio [Radeon HD 6500D and 6400G-6600G series]


    Ich hätte gern Audio per HDMI zum AV-Receiver. Habe den bisher per TOSLink angeschlossen, funktioniert wunderbar und eigentlich wirklich nichts zu meckern, nur kriege ich auf die Art Mehrkanalton nur DD- bzw DTS-codiert zum Receiver. ALSA kann das bei Bedarf sogar "on-the-fly" codieren, klar, aber per HDMI sollte es ja unkomprimiert (PCM) möglich sein, in seltenen Fällen wäre das ne nette Sache (z.B. SA-CD Rip).


    Also dachte ich mir nichts leichter als das, ich schließe ein HDMI kabel an, zwischen PC und Receiver. Direkte Auswirkung: Sowohl KMS als auch der Xserver haben nur noch Mist gemacht, seltsame Auflösungen. Display ist per DVI angeschlossen, aber das war wohl egal X(


    Indes Ton? Keiner. Und die Text-Ausgabe von "speaker-test", dass das Gerät nur zwei Kanäle unterstützt. Nach etwas nachlesen habe ich gefunden, dass mit dem opensource radeon Treiber einfach nicht mehr als 2 Kanäle gehen (stimmt das?) -- War also an der Zeit, einen catalyst/fglrx auszuprobieren. Erstes Opfer: KMS -- die Linux-Konsole kommt jetzt im PC-XT Charme daher -- aber ok, nicht so schlimm, man kriegt sie ja nicht oft zu Gesicht. Solange ich am Receiver nicht auf den HDMI-Eingang schalte klappt auch alles mit den Auflösungen (mit fglrx noch keinen Gegentest durchgeführt).


    Ja, jetzt habe ich bessere OpenGL-Unterstützung als vorher, außerdem va-api (für XvBA) was immerhin im mplayer funktioniert ... nett.


    Aber: an der Audio-Situation hat sich nichts geändert. Laut speaker-test zwei Kanäle -- und die bleiben zu allem Überfluss auch noch stumm. Nur der Vollständigkeit halber -- da ich ALSA seit unzähligen Jahren kenne habe ich natürlich die Mixer-Einstellugen überprüft ;)


    Liegt es daran, dass das HDMI-Kabel "nur" zum AV-Receiver führt und nicht von dort aus auch noch weiter zum Display? Ich hoffe doch nicht? will mein Display nicht per HDMI anschließen, denn mein Receiver kann kein Pass-Through im standby ... und den Computer nur noch mit eingeschaltetem Receiver nutzen zu können, wäre doof.


    Andere Ideen? Hab ich was falsch gemacht, was übersehen?

    Hallo Jack, mag sein, dass die Optimierungen auf angeschlossene Boxensets auch bei Multichannel-PCM greifen (das kriege ich im Moment gar nicht verlustfrei zum Receiver, S/PDIF, HDMI Kabel liegt aber hier rum, muss ich nur mal anschließen) -- allerdings die Up- bzw Downmixing Verfahren, die an DD und/oder DTS hängen, gibt es auch wirklich nur mit denen. Und Stereo-Lautsprecher habe ich halt nicht, bei mir läuft alles über das 5.1 Boxenset.


    Könnte natürlich alles Up-/Downmixing bereits im PC machen -- Vorteil für ALSA/dmix, aber ich bin mir nicht sicher, ob das wirklich auch die gleiche Klangqualität gibt, zumal ich das dann ja selbst per routing tables in asound.conf konfigurieren muss...


    1. ich bin ein alter Dackel und tu mich schwer mit neuen Sachen ;)
    2. was heißt da fremd - den VDR von e-tobi gab es schon, da wusste debian noch nicht mal, dass es einen vdr gibt
    3. e-tobi macht einen verdammt guten Job - jetzt schon über zig Jahre. Der vdr aus seinem repo ist daugerecht aufbereitet und ich verwende seine repos seit zig Jahren. Ich habe keinen Grund, mich nach was anderem umzuschauen, denn ich bin mir ziemlich sicher, dass die anderen repos auch nicht besser sind. Wenn ein Plugin Quark ist, kann doch Tobi nix dafür!


    Das war mal, vdr gibt es schon lange offiziell in Debian und bevor ich mich hinstelle und sage wheezy ist buggy versuch ich eben erst mal die originalen Pakete von wheezy. Das ist halt so meine Idee von sowas.


    Quote

    Morone bringt das knackiger und meint gleich: ich sei doof.


    Wie soll ich das beurteilen? Nur: Bei mir funktioniert's super. Und zwar sogar ohne dass ich IRGENDWAS konfiguriert hätte.


    Quote

    Ich habe weder mit alsa noch mit vdpau Probleme. Sonst würde z.B. ffplay nicht so perfekt funktionieren.
    Was immer schlechter funktioniert ist vdr-sxfe.


    Das kann man so allgemein nicht unbedingt immer sagen. Manche Probleme wirken sich nur in bestimmten Konstellationen aus ... z.B. Dolby-Digital Ton im vdr-sxfe kann mal Probleme haben, wenn was anderes ab und zu die Soundkarte belegt.


    Quote

    Wobei ...
    ... die Einstellung des video-Treibers war von Anfang an (bei vdr-sxfe) im Argen. Mehr wuhduh als sonstwas.


    Verstehe ich auch nicht ganz, ich muss da nix einstellen, einfach --video=XXX und gut ... *?*

    die Probleme mit der Größenänderung des Fensters sind wech, wenn der Parameter --reconnect verwendet wird.
    Da ich den Parameter unter squeeze nicht brauche, gehe ich davon aus, dass der x-server oder die xinelib von Wheezy instabiler geworden sind.


    Das glaube ich nun wirklich nicht ... warum probierst du nicht als erstes mal die Pakete aus wheezy aus (statt fremder Paketquellen)? Wenn's dann immer noch nicht funktioniert würde ich wie gesagt nach Schwierigkeiten mit alsa oder (in deinem Fall, wie ich jetzt mitbekommen habe) vdpau suchen.


    Übrigens kurz zum Scaling: Ich nutze nur xv und bin eigentlich ziemlich zufrieden (tvtime deinterlacer). Wenn ich direkt davor sitze erkennt man bei SD Material interlaced zuweilen leichte Kämme, recht harmlos -- von der Couch aus definitiv nichts zu merken. Wie kann vdpau das SO viel besser machen?

    Eine dumme Frage warum sind in der Resource "duration, resolution, bitrate, ..."?
    Sind das keine Properties? Oder nur vergessen zulöschen?


    Johns


    Ne teilweise Antwort: Wenn ich die Kommentare im Source richtig verstanden habe sollen pro Metadaten-Satz mehrere Resourcen möglich sein -- und diese Properties gibt es eben PRO Resource. Allerdings hab ich nicht so ganz verstanden, warum ;)