Hat sich schon erledigt... das Modul war einfach fest in den Kernel einkompiliert... sorry!
Jetzt muss ich nur mal schauen, warum sich dann DMA nicht aktivieren lässt...
Hat sich schon erledigt... das Modul war einfach fest in den Kernel einkompiliert... sorry!
Jetzt muss ich nur mal schauen, warum sich dann DMA nicht aktivieren lässt...
Hallo,
ich bin kürzlich von Kernel 2.6.12-ct-1 auf eine selbst kompilierte Version 2.6.24.4 umgestiegen. Das System läuft auch soweit, nur lässt sich leider bei den IDE-Geräten der DMA-Modus nicht aktivieren (Meldung HDIO_SET_DMA failed: Operation not permitted).
Als Ursache vermute ich das Fehlen des Moduls libata.ko. Ich weiß nicht, warum es beim Kompilieren des Kernels nicht erzeugt wird. libata.o wird in drivers/ata erstellt... In der menuconfig habe ich keine wirklich passende Option gefunden... Kann ich das Erstellen des Moduls irgendwie durch einen manuellen config-Eintrag erzwingen?
MfG
Sebastian
Ah, das war's! Genau genommen wurde die Datei mplayer in /usr/share/vdr-plugin-mplayer schon ordnungsgemäß aktualisiert, aber ich hatte in der Konfiguration des Plugins noch eine alte, von mir angepasste mplayer.sh eingetragen... mit dem richtigen Skript funktioniert es jetzt wieder.
Danke für die schnelle Hilfe!
MfG
Sebastian
Hallo,
nach einem Update meines VDR-Systems (aktualisierung auf Etch und Kernel 2.6.24.4) funktioniert mal wieder der mplayer nicht mehr so, wie er soll :(. Nach etwas Nachforschen mit den DEBUG-Variablen und einem Aufruf über die Kommandozeile erhielt ich die Meldung, dass es die Option -vop nicht mehr gibt und man stattdessen -vf verwenden sollte. Ich habe das also in der mplayer.sh entsprechend geändert.
Leider funktioniert es damit aber immer noch nicht - die Ausgabe von mplayer lautet jetzt:
Starting playback...
VDec: vo config request - 576 x 304 (preferred colorspace: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
Opening video filter: [lavc]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
[mpeg1video @ 0xb6cd09a8]removing common factors from framerate
VO: [mpegpes] 576x304 => 576x304 Mpeg PES
DVB: height=304 not supported (try 240/480 (ntsc) or 288/576 (pal)
FATAL: Cannot initialize video driver.
VDec: vo config request - 576 x 304 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
Could not open codec.
FATAL: Cannot initialize video driver.
FATAL: Could not initialize video filters (-vf) or video output (-vo).
Alles anzeigen
Damit bin ich nun leider mit meinen Ideen am Ende - weiß jemand Rat?
Danke,
Sebastian
P.S.: Mein System: Debian Etch mit Kernel 2.6.24.4, VDR 1.4.7 (eTobi testing), mplayer Version dev-SVN-rUNKNOWN-4.1.2, Ausgabe-Device ist eine Technotrend DVB-C FF Rev. 2.1
Hallo,
ich habe gerade auf die aktuelle testing VDR-Version (1.3.49-1ctvdr2) aktualisiert und bin jetzt auf ein kleines Problem gestoßen:
Vor dem Upgrade war es so, dass ich durch kurzes Pausieren der Wiedergabe manchmal (z.B. durch kurze Bildfehler von DVB-T Aufnahmen bei Gewitter) vorhandene Asynchronität von Bild und Ton beheben konnte.
Nach dem Update ist es nun gewissermaßen genau umgekehrt: Wenn ich nach der Pause die Wiedergabe fortsetze, gibt es einen spürbaren Versatz, der erst nach Abbruch und Neustart der Wiedergabe verschwindet.
Weiß jemand einen Rat, woran das liegen könnte und wie ich es vielleicht beheben kann?
Mein System: Shuttle SN41G2 mit Kernel 2.6.12-ct-1, Technotrend DVB-C 2.1 Premium und Terratec Cinergy T² für DVB-T
Danke,
Sebastian
In der fstab steht nichts von beidem, sondern nur
/dev/hdb /media/cdrom0 iso9660 ro,user,noauto 0 0
Es sind ja auch einfach nur Symlinks auf /media/cdrom (welches selbst wiederum nach /media/cdrom0 gelinkt ist...).
Auch von den Rechten her sind natürlich beide gleich:
vdr-sk:/# ll | grep media
lrwxrwxrwx 1 root root 11 2006-01-09 22:32 cdrom -> media/cdrom
lrwxrwxrwx 1 root root 11 2006-01-11 19:17 dvd -> media/cdrom
drwxr-xr-x 4 root root 1024 2006-01-09 22:32 media
Und von der Shell aus klappt's mit "mount /dvd" genauso gut wie mit "mount /cdrom" - nur halt vom Plugin aus nicht. Ich finde das wirklich sehr seltsam...
MfG
Sebastian
Hallo,
ich habe gerade ein seltsames Verhalten des MPlayer-Plugins beim Mounten eines Datenträgers im DVD-Laufwerk festgestellt:
Ich habe unter / zwei symbolische Links /cdrom und /dvd - beide verweisen auf /media/cdrom. Das Mounten klappt aber nur dann, wenn ich in der mplayersources.conf die Zeile
/cdrom;DVD;1
benutze. Mit
/dvd;DVD;1
hingegen bekomme ich nur "Einbinden fehlgeschlagen"...
Hat jemand eine Idee, woran das liegen könnte? Ich dachte eigentlich, dass die beiden Symlinks völlig gleichberechtigt sein sollten...
Ach ja: c't-VDR 4.5 auf Kernel 2.6.12.
MfG
Sebastian
Hallo,
ich stehe gerade vor dem gleichen Problem...
Zitatansonsten hat es mir im Falle von vdr2mpg geholfen "vdrsync" mit dem Parameter "-m panteltje" anzuweisen, dass nun tcmplex-panteltje verwendet werden soll
An welcher Stelle genau hast Du denn das "-m panteltje" eingefügt?
MfG
Sebastian
sorry, ich war mit dem Posting wohl etwas vorschnell... eine Suche per Google führte mich zur Lösung, auch ein Beitrag hier aus dem Forum
Zur Wiedergabe sollte das falsche DVB-Gerät benutzt werden... Die Lösung war einfach, in vdrmplayer.sh.conf die Zeile
VO="mpegpes"
in
VO="mpegpes:card=2"
zu ändern...
Damit klappt die Wiedergabe jetzt wunderbar *freu*
MfG
Sebastian
Hallo,
hat es schon jemand geschafft, unter der neuen Version 4.5 das MPlayer-Plug-In zum laufen zu bringen? Ich habe es einfach über ctvdrcfg installiert, und da auch gleich das Paket mplayer-386 und diverse Libs mit installiert wurden, dachte ich, dass es inzwischen ganz einfach funktioniert...
Aber wenn ich z.B. eine AVI-Datei abspielen möchte, wird nur der Bilschirm kurz schwarz und dann bin ich wieder im normalen TV-Programm :(. Im syslog steht dies hier:
Jan 10 23:01:48 localhost vdr[6014]: mplayer: mplayer child started (pid=6014)
Jan 10 23:01:48 localhost logger: *** Starting mplayer.sh Version 0.8.6
Jan 10 23:01:48 localhost vdr[6015]: mplayer: player thread started (pid=6015)
Jan 10 23:01:48 localhost logger: *** DEBUG: Variable CFGFIL has value "/etc/vdr/plugins/vdrmplayer.sh.conf"
Jan 10 23:01:48 localhost logger: *** Use Option USERDEF at your own risk!
Jan 10 23:01:48 localhost lircd 0.7.1pre2[4222]: accepted new client on /dev/lircd
Jan 10 23:01:48 localhost lircd 0.7.1pre2[4222]: removed client
Jan 10 23:01:49 localhost logger: *** INFO: Source Video has Resolution of 672 x 352 ...
Jan 10 23:01:49 localhost logger: *** INFO: For Sqare Pixels we would scale to 640 x 335 ...
Jan 10 23:01:52 localhost vdr[6015]: mplayer: player thread ended (pid=6015)
Hat jemand eine Idee, was da schiefläuft?
Danke,
Sebastian
ZitatOriginal von wilderigel
Fehler von ctvdr4, sollte lt Hinweisen auf der Heise Seite in ctvdr4.5 behoben sein?
offenbar nicht... jedenfalls habe ich das CD-Image von ftp://ftp.heise.de/pub/ct/projekte/vdr45/isos/ctvdr.iso benutzt
ZitatStell das Device in /etc/lirc/hardware.conf auf /dev/lirc/0 oder /dev/lirc0
Musst halt schauen, welches Device da ist.
Lt deinem Log Auszug: /dev/lirc/0
super - genau das war's - danke!!
MfG
Sebastian
Hallo,
ich habe gestern meinen VDR mit der aktuellen c't-Distribution 4.5 neu aufgesetzt - läuft auch ganz gut, bis auf ein sehr seltsames Problem mit LIRC:
Nach dem Booten funktioniert die Fernbedienung zuerst nicht, obwohl der LIRC-daemon mit S19lirc in /etc/rc2.d gestartet wird. Laut ps -A läuft auch kein lirc-Prozess. Wenn ich dann aber
/etc/init.d/vdr stop
/ets/init.d/lirc start
/etc/init.d/vdr start
ausführe, funktioniert es anschließend...
Woran könnte das liegen - warum klappt es nicht gleich beim ersten Anlauf während des Bootens?
Danke schonmal,
MfG
Sebastian
P.S.: Hier noch ein Ausschnitt aus /var/log/syslog zu dem Fehler:
Jan 10 18:11:30 localhost kernel: lirc_dev: IR Remote Control driver registered, at major 61
Jan 10 18:11:30 localhost kernel: lirc_serial: no version for "lirc_unregister_plugin" found: kernel tainted.
Jan 10 18:11:31 localhost kernel: lirc_serial: auto-detected active low receiver
Jan 10 18:11:31 localhost kernel: lirc_dev: lirc_register_plugin:sample_rate: 0
Jan 10 18:11:31 localhost lircd 0.7.1pre2[4016]: lircd(any) ready
Jan 10 18:11:33 localhost udev[4162]: configured rule in '/etc/udev/rules.d/030_lirc.rules[1]' applied, added symlink 'lirc%n'
Jan 10 18:11:33 localhost udev[4162]: configured rule in '/etc/udev/rules.d/030_lirc.rules[1]' applied, 'lirc0' becomes 'lirc/%n'
Jan 10 18:11:33 localhost udev[4162]: creating device node '/dev/lirc/0'
Jan 10 18:11:50 localhost lircd 0.7.1pre2[4016]: accepted new client on /dev/lircd
Jan 10 18:11:50 localhost lircd 0.7.1pre2[4016]: could not open /dev/lirc
Jan 10 18:11:50 localhost lircd 0.7.1pre2[4016]: default_init(): Is a directory
Jan 10 18:11:50 localhost lircd 0.7.1pre2[4016]: caught signal
Jan 10 18:11:50 localhost vdr[5236]: ERROR: lircd connection lost
Alles anzeigen
P.P.S.: Das System läuft mit Kernel 2.6.12-ct-1 und VDR 1.3.37
Hallo,
falls jemand das gleiche Problem hat - ich habe doch noch eine Lösung gefunden:
Einfach am Ende des stop-Teils von /etc/init.d/hotplug die Zeile
rmmod ohci_hcd
einfügen. Ist wahrscheinlich nicht besonders elegant, aber bei mir ist das Problem damit behoben...
MfG
Sebastian
Hallo,
danke für die Antworten!
Einen passenden Jumper konnte ich in der Dokumentation des Mainboards leider nicht finden. Im BIOS gibt es die Option "USB Resume From S3", aber die war schon auf Disabled...
Etwas neues habe ich allerdings: Direkt vor dem Ausschalten ist auf dem Bildschirm noch die Meldung "ohci_hcd [Zahlen]:remote wakeup" zu sehen, die allerdings nicht in /var/log/messages auftaucht. Das muss sich doch irgendwie ausschalten lassen...
Mein Mainboard ist ein Shuttle FN41 mit nForce2-Chipsatz.
MfG
Sebastian
Hallo,
ich hoffe, die Frage ist nicht zu dämlich :), aber ich frage mich, ob das so richtig ist:
Ich habe mir eine cinergyT2 USB-2.0-Box zugelegt, um sie mit dem VDR zu nutzen. Das ganze funktioniert auch sehr gut, nur eine Sache verwundert mich: Wenn ich den Rechner herunterfahre, bleibt die LED an der cinergyT2 an, obwohl das System ausgeschaltet ist. Es ist sogar so, dass sie sich direkt vor dem Ausschalten des Rechners wieder einschaltet, wenn ich den VDR manuell beende und die DVB-Treiber entlade (danach ist sie zunächst aus....)
Ist das normal? Auch wenn ja, kann man das irgendwie ändern? (Gefällt mir nämlich nicht).
Ach ja: Ich benutze c't-VDR2, Kernel 2.6.7 und DVB-Treiber aus dem CVS.
Danke schonmal,
Sebastian
Hallo,
ich denke auch darüber nach, mir so eine Box zu holen. Auf http://vaasa.wi-bw.tfh-wildau.de/~pboettch/index.php steht allerdings:
"Using the device as a slave device in vdr, was not working for me. Some work has to be done (patches and comments are very welcome).
Klingt leider nich so gut... Hat es von Euch hier inzwischen jemand geschafft, das Ding mit dem VDR zu nutzen?
Sebastian
Hallo (nochmal),
ich habe den "Schuldigen" doch noch gefunden: hotplug! Ein Eintrag von forcedeth in /etc/hotplug/blacklist hat tatsächlich dazu geführt, dass der Treiber nicht mehr geladen wird.
MfG
Sebastian
Hallo mrmoe,
erstmal sorry, dass ich mich so lange nicht mehr gemeldet habe. Ich bin vor ein paar Tagen umgezogen und hatte bis vor kurzem keinen Internet-Zugang.
Leider hat auch generate-modprobe.conf nicht geholfen ;(. Ich habe das Skript aus /usr/share/doc/module-init-tools/examples geholt, wie von Dir beschrieben ausgeführt und neu gebootet. Doch forcedeth ist immer noch da... Ich verstehe das langsam wirklich nicht mehr - was veranlasst das System bloß, diesen verd*** Treiber zu laden?!
MfG
Sebastian
Hallo,
ok, installiert sind die schon, aber wie benutze ich die? Sind das nicht einfach die insmod, rmmod, lsmod-Befehle?
Mein Problem ist, dass der forcedeth-Treiber beim booten geladen wird, obwohl nirgendwo steht, dass dies gemacht werden soll und ich discover auch extra angewiesen habe, forcedeth zu überspringen...
MfG
Sebastian
Hallo mrmoe,
danke für den Hinweis! Leider gelange ich einfach nicht in das Untermenü /kernel/drivers/net. Wenn ich den Eintrag auswähle, steht da nur kurz "Bitte warten Sie, während die Module erkannt werden." und dann bin ich doch wieder im Hauptmenü...
Ach ja, ich benutze den Kernel 2.6.7
MfG
Sebastian