Hallo Jondalar,
ich bin jetzt auch schon leicht genervt und ich überlege auf Windows (Mediacenter mit XP) zu wechseln.
Gruß tcash
Hallo Jondalar,
ich bin jetzt auch schon leicht genervt und ich überlege auf Windows (Mediacenter mit XP) zu wechseln.
Gruß tcash
Hallo Eisbaer128,
ich habe die Probleme nur, wenn vdr-sxfe mit läuft (unter Xbmc nur Navigationssound), als Test habe ich mal XBMC einzelnt gebootet und dann geht der Sound ohne Probleme.
Unter XBMC habe ich schon alle möglichen Einstellungen getestet, aber ohne Erfolg.
Wie ist bei Dir die TV Qualität mit SD Sendern, ich hatte zum Vergleich mal Easyvdr und was soll ich sagen zwische Ubuntu und Easyvdr liegen Welten zu Gunsten von Easyvdr.
Gruß tcash
Hallo tcash,
Dann sollte es wohl wie von mir vermutet an einer Blockierung der Soundkarte durch den anderen Prozess liegen. Ich habe damit zwar keine Erfahrung, aber schau Dir doch mal alsa dmix an damit sollte man das hinbekommen. Hier z.B. ein Link zu einem Howto:
http://alsa.opensrc.org/home/w…ndex.php?title=DmixPlugin
Zur Bildqualität: Ich habe keinen wirklichen Vergleich aber da die Software ja die selbe ist kann es nur an den Voreinstellungen für X Server oder xinelibout (z.B: deinterlacer) liegen. Ich bin eigentlich ziemlich zufrieden, der Deinterlacer den ich eingestellt habe ist noch nicht so wirklich das ware aber ich bin ja eh gerade dabei das ganze auf VDPAU umzustellen deshalb habe ich da keine Zeit reingesteckt.
Hallo Eisbaer128,
danke für den Tip wegen dem Soundproblem. Ich habe meinen VDR erst einmal still gelegt, wegen der Qualität vom SD Sendern, bei mir waren ständig kleine ruckler und Ton knackser drin. Bei meiner config_xineliboutput Datei habe ich folgende Einstellungen vorgenommen
engine.buffers.video_num_frames:5000
video.output.vdpau_deinterlace_method:temporal
Aber an der bescheidenen Anzeige hat sich nichts geändert, wäre es möglich wenn Du mir deine Einstellungen mal postest?
Ich verwende Xine-VDPAU 261 und NVIDIA-Linux-x86-185.18.14.
Dann habe ich noch festgestellt, das unter XBMC kein File (720p, 1080i und 1080p) mit vdpau abgespielt bekomme, wenn ich o drücke bekomme ich nur folgende Anzeige.
vq:xxx dc: ff-mpeg4
Wie sieht es bei Dir mit vdpau und xbmc aus?
Danke schon im Voraus.
Gruß tcash
Hallo tcash,
Also xbmc fuktioniert bei mir ziemlich gut mit VDPAU. Achtung wird in xbmc nur für HDTV verwendet. Per xbmc Infoanzeige wird vdpau bei HDTV Aufnahmen verwendet und ich sehe auch nur eine sehr niedrige Prozessorlast auch bei 1080p Material. Ich habe zwar einen aktuellen xbmc pvr-testing am laufen das ging aber auch schon vorher mit der ganz normalen 9.04 Release. HDTV Fernsehen geht damit auch aber umschalten zwischen HDTV Kanälen für noch mi sehr hoher Wahrscheinlichkeit zu einem Crash.
Beim xinelibout bin ich noch nicht zu einer laufenden VDPAU Version gekommen, ich kann deine Frage also nicht wirklich beantworten, das aktuelle xinelibout passt aber noch nicht wirklich gut zu meinem vdr 1.7.8.
Hat jemand mit dem Mini auch ab und an das Problem, dass der kleine nicht herunter fährt?
Installiert ist bei mir Kernel 2.6.29.2 und die NVIDIA Treiber 180.60.
Wenn der Shutdown nicht klappt, steht im LOG folgendes:
Jul 14 05:04:46 freevdr kernel: [39045.548005] BUG: soft lockup - CPU#0 stuck for 61s! [Xorg:5814]
Jul 14 05:04:46 freevdr kernel: [39045.548005] Modules linked in: video output sbs sbshc pci_slot lp parport snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_oss ipv6 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device cx24116 snd nvidia(P) soundcore agpgart pcspkr applesmc snd_page_alloc dvb_usb_dw2102 shpchp pci_hotplug dvb_usb dvb_core rtc_cmos rtc_core rtc_lib i2c_core joydev ohci1394 ieee1394 ssb pcmcia pcmcia_core forcedeth
Jul 14 05:04:46 freevdr kernel: [39045.548005]
Jul 14 05:04:46 freevdr kernel: [39045.548005] Pid: 5814, comm: Xorg Tainted: P (2.6.29.2 #1) Macmini3,1
Jul 14 05:04:46 freevdr kernel: [39045.548005] EIP: 0060:[<f92fea20>] EFLAGS: 00203293 CPU: 0
Jul 14 05:04:46 freevdr kernel: [39045.548005] EIP is at _nv003235rm+0xe4/0x1ee [nvidia]
Jul 14 05:04:46 freevdr kernel: [39045.548005] EAX: 00043490 EBX: 00000020 ECX: 00000562 EDX: f9745000
Jul 14 05:04:46 freevdr kernel: [39045.548005] ESI: f62e9000 EDI: f619da50 EBP: f65d3f84 ESP: f655fe18
Jul 14 05:04:46 freevdr kernel: [39045.548005] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Jul 14 05:04:46 freevdr kernel: [39045.548005] CR0: 8005003b CR2: ac468000 CR3: 360b0000 CR4: 000406d0
Jul 14 05:04:46 freevdr kernel: [39045.548005] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
Jul 14 05:04:46 freevdr kernel: [39045.548005] DR6: ffff0ff0 DR7: 00000400
Jul 14 05:04:46 freevdr kernel: [39045.548005] Call Trace:
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<f92fdcb1>] ? _nv003232rm+0x8a/0x249 [nvidia]
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<f92fd4b8>] ? _nv003245rm+0x1d1/0x2c9 [nvidia]
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<f92f93a5>] ? _nv006026rm+0x4e/0x75 [nvidia]
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<f9199dd5>] ? _nv003189rm+0x195/0x601 [nvidia]
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<c0104629>] ? math_state_restore+0x49/0x90
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<f936b596>] ? rm_ioctl+0x3e/0x6d [nvidia]
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<c0104629>] ? math_state_restore+0x49/0x90
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<f941324e>] ? nv_kern_ioctl+0x19e/0x450 [nvidia]
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<c0104629>] ? math_state_restore+0x49/0x90
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<f9413538>] ? nv_kern_unlocked_ioctl+0x18/0x20 [nvidia]
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<f9413520>] ? nv_kern_unlocked_ioctl+0x0/0x20 [nvidia]
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<c01a15ab>] ? vfs_ioctl+0x2b/0xa0
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<c01a1b0b>] ? do_vfs_ioctl+0x7b/0x5f0
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<f9410f51>] ? nv_kern_vma_release+0xc1/0x130 [nvidia]
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<c017e0b6>] ? remove_vma+0x46/0x60
Jul 14 05:04:46 freevdr last message repeated 2 times
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<c017efbb>] ? do_munmap+0x22b/0x280
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<c01a20bd>] ? sys_ioctl+0x3d/0x70
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<c01033d1>] ? sysenter_do_call+0x12/0x25
Jul 14 05:04:46 freevdr kernel: [39045.548005] [<c0104629>] ? math_state_restore+0x49/0x90
Display More
Das wiederholt sich dann jede Minute.
Ich habe gerade mal die NVIDIA Treiber 185.18 installiert, in der Hoffnung, dass der Fehler verschwindet.
Edit: Habe gerade gelesen, dass der Kernelparameter "noapic" helfen könnte.
EDIT2: Ist keine Lösung, da dann der Soundchip nicht mehr gefunden wird.
Gruß
QuoteOriginal von Eisbaer128
Reboot ist ein bekanntes Thema.
Shutdown geht reboot geht nicht mit allen neuen Mac Minis. Scheint auch noch so zu sein mit einem neuen 2.3.30 Kernel aus dem 9.10 Alpha Ubuntu. Es gibt dazu ein Feher Ticket bei Ubuntu aber keine Lösung. Nehme das noch in die Liste der Probleme auf.
Reboot geht mit
"reboot=pci"
z.B. bei mir aus /boot/grub/menu.lst
title Ubuntu 9.04, kernel 2.6.29.2
kernel /boot/vmlinuz-2.6.29.2 root=/dev/sda2 ro reboot=pci
initrd /boot/initrd.img-2.6.29.2
Hallo Celica,
Danke für die Information, aber bei meinem Mac Mini hilft das nichts. Beim Reboot bleibt er immer noch hängen.
Gerade nochmal getestet, nach 4Tagen uptime > reboot, kein Problem.
Hatte aber auch schon mal Probs mit reboot, wenn sich vdr-sxfe weghängt,
(Bild nur noch im XBMC) dann ging komischerweise kein reboot mehr.
Wo und warum das dann nicht geht habe ich noch nicht genauer analysiert.
Könnte sein das evtl. mehrere vdr-sxfe Processe dann vorhanden sind und vorher gekillt werden müssten?
QuoteOriginal von Eisbaer128
Hallo Celica,
Danke für die Information, aber bei meinem Mac Mini hilft das nichts. Beim Reboot bleibt er immer noch hängen.
Ich habe dein script für mein system angepasst. Nutze als Frontend Xine und dein script erkennt erfolgreich das laufende programm und schaltet auch zwischen xbmc und xine-vdr hin und her. Ich habe aber folgendes problem: wenn dein script xine-vdr startet dann hängt das script in einer art warteschleife und ich kann per irexec kein weiteres starten. erst wenn ich xine per hand beende dann läuft dein script weiter. was mache ich hier falsch??
mein script:
#!/bin/bash
XBMC="/usr/bin/xbmc -fs"
VDR="/usr/bin/vdr-sxfe xvdr:tcp://localhost:37890 --nokbd --lirc --fullscreen --reconnect --syslog --post tvtime:method=Linear,cheap_mode=1,pulldown=0,use_progressive_frame_flag=1"
#PIDFILE=/var/run/xine.pid
if [ "`ps -ef | grep -v grep | grep 'xine -V'`" != "" ];then
echo "VDR application is running => starting XBMC ..."
killall xine
sleep 1
/usr/bin/xbmc
elif [ "`ps -ef | grep -v grep | grep '/usr/bin/xbmc'`" != "" ];then
echo "XBMC application is running => starting VDR ..."
killall xbmc-bin
else
echo "no application is running => starting VDR ..."
xine -V vdpau -f -g --no-splash --post tvtime:method=use_vo_driver --post vdr_video --post vdr_audio --post vdr "netvdr://127.0.0.1#demux:mpeg_pes"
fi
Gibt es hier schon ne Lösung?
Genau so ein Script suche ich auch um den easyVDR mit XBMC zu betreiben.
Bitkit
Problem gefunden, man sollte richtig lesen.
"begin
prog = irexec
remote = MacMini
button = F1
config = /usr/local/bin/switchtv & \n
"end
Das "& \n" in der .lircrc war das Problem. Zur verständissfrage, was bedeutet das: & \n
"\n" bedeutet Newline oder Line feed (Zeilenumbruch oder Zeilenvorschub) und ist ein Steuerzeichen. Hast Du die Datei mal mit einem Windows Editor bearbeitet? Dann passiert so etwas ganz gerne. Das & hat damit aber wiederum nichts zu tun.
Habe alles im ubuntu mit "nano" bearbeitet. Wenn ich das "& \n" weglasse, dann kann ich das script einmal ausführen. Beim zweiten Druck auf die Taste reagiert "irexec" nicht mehr. Komisch. Aber eigentlich auch egal, denn jetzt funktioniert es wie es soll.
QuoteOriginal von Asta
Habe alles im ubuntu mit "nano" bearbeitet. Wenn ich das "& \n" weglasse, dann kann ich das script einmal ausführen. Beim zweiten Druck auf die Taste reagiert "irexec" nicht mehr. Komisch. Aber eigentlich auch egal, denn jetzt funktioniert es wie es soll.
switchtv wird mit dem & im Hintergrund ausgeführt und irexec ist sofort wieder bereit ein weiteren Tastendruck zu bearbeiten. Ohne das & wartet irexec auf die Beendigung von switchtv, die aber wohl nicht passiert, deshalb gibt es keine Reaktion von irexec mehr. Ich kenne switchtv nicht, vom Namen würde ich eigentlich nicht erwarten, dass er sich nie beendet, seltsam.
Gerald
Mein neues Script:
#!/bin/bash
XBMC="/usr/bin/xbmc -fs"
VDR="/usr/bin/xine -V vdpau -f -g --no-splash --post tvtime:method=use_vo_driver --post vdr_video --post vdr_audio --post vdr "netvdr://127.0.0.1#demux:mpeg_pes""
PIDFILE=/home/user/xine.pid
if [ "`ps -ef | grep -v grep | grep 'xine -V'`" != "" ];then
echo "VDR application is running => starting XBMC ..."
PID=`pidof -s /usr/bin/xine`
kill $PID
killall -9 xine
killall -9 xbmc.bin
sleep 2
$XBMC
sleep 1
PID=`pidof -s /usr/share/xbmc/xbmc.bin`
echo $PID > $PIDFILE
elif [ "`ps -ef | grep -v grep | grep '/usr/bin/xbmc'`" != "" ];then
echo "XBMC application is running => starting VDR ..."
PID=`pidof -s /usr/share/xbmc/xbmc.bin`
kill $PID
killall -9 xine
killall -9 xbmc.bin
sleep 2
$VDR
PID=`pidof -s /usr/bin/xine`
echo $PID > $PIDFILE
else
echo "no application is running => starting VDR ..."
killall -9 xine
killall -9 xbmc.bin
$VDR
PID=`pidof -s /usr/bin/xine`
echo $PID > $PIDFILE
fi
Die .lircrc
begin
prog = irexec
remote = technisat
button = tv/sat
config = /home/user/scripte/./umschaltscript & \n
end
Damit funktioniert bei mir das Umschalten zwichen vdr-xine und xbmc problemlos.
Don’t have an account yet? Register yourself now and be a part of our community!