Posts by xnalpf

Quote

Original von C-3PO
Thx @ wastl,

ich werde mal die neue Version mit meinem l4m132c Testen.

Btw: ist eigenlich eine graphLCD Version in Farbe geplant, - gerade für das l4m132c ?

Das fände ich auch interessant. Dann würde ich das über mein TFT laufen lassen. GraphLCD lief bei mir immer etwas stabiler als GraphTFT. Und mit der neuen SDL Unterstützung sollte es ja recht flüssig laufen.

Ups - mein Fehler. Hatte ich vom Compilerlauf ohne libusb kopiert. Habs korrigiert. So wie jetzt in meinem Post geschrieben ist die Ausgabe richtig.

Höhö - so schnell kann man den Programmierer verunsichern. Nee, mach dir keinen Kopf. Ist alles richtig bei mir.

Und bei keine Probleme? Habs grad mal auf meinem Laptop gebacken. Keine Probs.

uname -a
Linux deltaflyer 2.6.27.42-0.1-default #1 SMP 2010-01-06 16:07:25 +0100 x86_64 x86_64 x86_64 GNU/Linux

gcc --version
gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]

Heulsuse ist 11.1 und ich habs mit usb und SDL compiliert.

serdisplib version: 1.97.9

supported extra libraries
=========================
* libusb support ... yes
* libSDL support ... yes
* libgd >= 2 support ... yes

enabled(+) / disabled(-) drivers
================================
+ sed153x, pcd8544, sed156x, i2c, t6963, sed133x, nokcol, ks0108, lh155, ssdoled, l4m, goldelox, stv8105, acoolsdcm, directgfx, lc7981
-

tools
=====
* multidisplay ... yes
- with GIF support ... yes

Quote

Original von fnu
War mir da was entgangen oder war der Threadtitel: "Alle ahnungsfreien bitte melden!"

Gruß
Frank

Ist das nicht latent Untertitel von jedem Thread?

Quote

Original von Morone

Womit bewiesen ist "AMD unter Linux = Bullshit"

Hehe - ich liebe es, wenn eine meiner provokanten Äußerungen als Beweis genügt. Danke Morone!!!

Quote

Original von Stalker
VDPAU, XvBA, VA API, ... Mehr oder weniger macht da jeder seinen eigenen Kram, erklärt ihn zum Standard und ignoriert die anderen.
Relevant ist, was funktioniert, und da hat Nvidia einen beachtlichen Vorsprung. Natürlich steht es ATI und Intel zu, aufzuschließen, doch zu Zeit ist das nicht der Fall.

So ungefähr wollte ich mich auch ausdrücken. Hatte dann aber mehr Spaß daran zu provozieren
Ich hab übrigens beides im Einsatz: Nvidia auf meinen privaten Rechnern, ATI auf den Dienstrechnern. Und eins kann ich zumindest im direkten Vergleich sicher sagen - Nvidia hats drauf, ATI nicht.

Weil ATI unter Linux Bullshit ist.

Nur mal so als provokative Antwort

Das ist eine coole Neuigkeit. Dann bau ich mir ja vielleicht doch noch irgendwann einen HD-fähigen VDR...

Prima finde ich, dass der WLAN-Adapter ein USB-Stick ist. Ich hätte nämlich nicht gerne so einen "Strahlemann" auf dem Nachtisch. Bei mir würde WLAN direkt rausfliegen und gegen Lan getauscht.
Süßes Spielzeug...

Also ich kann zu der Diskussion hier zumindest schon mal soviel beitragen: Ich hab mir den Source vom 2.6.24er Kernel geholt und den Kernel mit verschiedenen Optionen für den realtek trieber kompiliert. Hat nix gebracht. Es muß aber definitiv am Kernel liegen denn ich hab mal Testweise einen SuSE-Kernel für die S100 gebacken und diesen gebootet. (nicht mit zendeb sondern mit einem abgespeckten Mini-SuSE) und dieser Kernel bootet jedes mal. Desweiteren habe ich sämtliche initrd's gelöscht - es wird bei mir also definitiv kein initrd benutzt. rotzdem hängt der Kernel jedes 2. Mal. Ich hab also leider auch noch keine Lösung aber zumindest ein paar zusätzliche Hinweise. Und ich bleibe am Ball...

Quote

Original von HTPC-Schrauber
Ich denke nicht, das sich die Frequenz großartig ändern wird.

Seh ich anders. Selbst bei den billigsten RC-Fernsteuersendern kommt eine Kapazitätsdiode zum Einsatz, die über eine variable (Spannungsgesteuerte) Kapazität den Quarz und damit den HF-Schwingkreis verstimmt. Nennt sich dann FM. Siehe auch hier: http://www.radiobastler.de/Modellbau/learn/quarzoszi.shtml

Quote

Allgemein ist es sehr schwierig bis unmöglich eine halbwegs genaue Uhr mit einem µC hinzubekommen. Die Gangungenauigkeit könntest Du auch per Software ausgleichen. Aber selbst dann ist die Genauigkeit für eine Uhr immer noch unbefriedigend.

Was soll denn bitteschön deiner Meinung nach noch genauer sein, als eine Quarzuhr. Und nichts anderes will devzero da mit sinem µC aufbauen. Klar - eine Atomuhr wird wohl "etwas" genauer sein. Aber die Quarzuhren, die ich so bei mir daheim habe weisen eine deutlich geringere Abweichung als 4s auf 24h auf.

Quote

Deutlich einfacher kommt man mit einem RTC-Baustein ans Ziel. Idealerweise einen mit integriertem Quarz.

Da gibt es auch unterschiedliche Meinungen zu. Die Zweifel an der Genauigkeit der RTC-Bausteine hat dazu geführt, dass heutzutage eigentlich jedes Betriebssystem einen NTP-Client nutz...

Quote

Original von xnalpf
Ich grab diesen uralten Thread nochmal aus

...

Aber mal ab von all den Missverständnissen - male die ketzerische Frage an Morone: Wird Music irgendwann mehr als mp3 und ogg können? Wäre es viel Aufwand Music auf xine zur Soundausgabe umzustellen? Kann xine überhaupt auf dvb ausgeben? Fragen über Fragen...

Wenn dein Music-Plugin jetzt noch so viele Codecs könnte wie xine... Aber das ist wohl ein anderes Thema!

Ja. Gut. Wenn man nur lange genug damit rumfummelt kriegt man's auch selbst raus. Hab noch ein --tcp in den Aufruf von vdr-sxfe eingebaut und jetzt funktioniert es. UDP als Transportprotokoll war der Übeltäter...

Ich hab jetzt nochmal aktualisiert:

VDR: 1.6.0.2 mit extension Patch
xineliboutput: 1.0.4
music: 0.4.0-b3

Auf dem Client hab ich auch xineliboutput Version 1.0.4 - trotzdem spielt Music jeden Song nur mal kurz an und dann kommt nix mehr. Der Fortschrittsbalken rennt wie blöd durch den Song und die Ausgabe vom vdr-sxfe auf dem Client sieht so aus:

[32044] [input_vdr] Connecting (data) to rtp://@224.0.1.9:37890 ...
[32044] [input_vdr] Data stream connected (RTP)
[32044] [input_vdr] using custom "no signal" image /etc/vdr/plugins/xine/noSignal.mpg
[32059] [input_vdr] exec_osd_command: Attempt to close non-existing OSD (0) !
[32059] [input_vdr] invalid parameter in control message OSDCMD
[32059] [input_vdr] exec_osd_command: Attempt to close non-existing OSD (1) !
[32059] [input_vdr] invalid parameter in control message OSDCMD
[32059] [input_vdr] exec_osd_command: Attempt to close non-existing OSD (2) !
[32059] [input_vdr] invalid parameter in control message OSDCMD
[32059] [input_vdr] exec_osd_command: Attempt to close non-existing OSD (3) !
[32059] [input_vdr] invalid parameter in control message OSDCMD
[32059] [input_vdr] exec_osd_command: Attempt to close non-existing OSD (4) !
[32059] [input_vdr] invalid parameter in control message OSDCMD
[32060] [input_vdr] UDP:119-119 missing, requested re-send for -1 frames
[32060] [input_vdr] SCR jump: +40 ms (live=0, tunning=0) time 0s
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32059] [input_vdr] vdr_flush_engine: stream_start, flush skipped
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32061] [input_vdr] No data in 8 seconds, queuing no signal image
[32061] [input_vdr] using custom "no signal" image /etc/vdr/plugins/xine/noSignal.mpg
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !
[32060] [input_vdr] Fifo buffer still full after poll !

Hmm. Hat sich denn in dem Abspielcode seit music-0.4.0-b3 was geändert? Das ist nämlich die Version, die ich mit meinem VDR benutze. Mein Server ist auch mit FF ausgerüstet und ich hab in Music als Ausgabedevice DVB eingestellt. Trotzdem kommt auf dem remote vdr-sxfe kein Ton raus und der Fortschrittsbalken rast durch die Lieder. Aber vielleicht liegt es ja an der xineliboutput Version? Welche Version nutzt du?

Genau das ist der Grund, warum meine Rechner alle per NFS booten und möglichst das gleiche OS haben. Da kann ich auf dem Server schnell sachen von einem Client auf den anderen kopieren. So aufwändig ist das aber alles nicht...

Ja. Auf dem Client einen eigenen VDR starten! Der holt sich dann per streamdev das Signal vom Server hat aber sein lokales xineliboutput und bedient dann lokal das vdr-sxfe. Damit sind alle Einstellungen unabhängig von anderen Maschinen. Genau so läuft es bei mir problemlos. Ich hab zwei T-Online Vision S100 - eine im Schlafzimmer mit analogem Sound und eine im Wohnzimmer mit digitalsound per SPDIF. Im Keller steht der VDR Server, der beide versorgt. Die S100 im Wohnzimmer startet nur ein vdr-sxfe, bedient sich also vom Server "direkt". Da ist dann alles auf digital eingestellt. Sie S100 im Schlafzimmer hat einen vdr laufen, der per streamdev-client plugin nur den mpeg-stream und die EPG-Daten vom Server kriegt alles weitere macht sie dann mit einem lokal verbundenen vdr-sxfe und zugehörigem xineliboutput völlig unabhängig. Die Aufnahmen sind vom server per NFS auf diese Box nach /video gemountet.
Der riesenvorteil an dieser Lösung ist, dass die zwei Clients nicht nur unabhängig in punkto Konfiguration sind sondern auch unterschiedliche Programme gucken können. Desweiteren reicht auf dem Server ein vdr mit nur zwei Plugins (xineliboutput, streamdev) und der Client mit eigenem VDR kann mit wesentlich mehr Plugins vollgeladen werden (DVD etc.). Wenn der Client abstürzt läuft der Server sauber weiter und macht keine Aufnahmen kaputt...

Quote

Original von det
steffen_b
um deine frage zu beantworten ja MusikHD mit vdr-sxfe oder xine leuft in freevdr
mfg det

Aber nur mit einem lokalen frontend? Oder auch remote übers Netz? Dabei meine ich jetzt nicht per vdr2vdr über streamdev und dann doch wieder lokalem vdr-sxfe sondern mit xineliboutput auf maschine "server" und auf dem client mit "vdr-sxfe xvdr://server" !

Quote

Original von Morone
Keine Ahnung..ich weiss noch net mal was vdr-sxfe wirklich ist

vdr-sxfe ist ein X-Frontend für den VDR, welches selbst auf xine basiert und auf dem Server mit xineliboutput kommuniziert. Es ist Bestandteil der xineliboutput plugins.
"Normalerweise" (was ist beim vdr schon normal?) wird es genutzt um auf einem Budget-Only System als Frontend zu arbeiten. Es gibt auch noch vdr-fbfe, das ist dann das gleiche Frontend nur eben für den Framebuffer. Das schöne an vdr-sxfe (und vdr-fbfe) ist, dass sie auch übers Netzwerk arbeiten. Daher eignen sie sich sehr gut für kleine Streamingclients. Glücklicherweise bietet das xineliboutput plugin die Möglichkeit Musik direkt über xine abzuspielen (was einem dann auch direkt einen Haufen mehr Codecs ermöglicht als bei Music) aber dafür hat man halt recht wenig Komfort. Der Player kann noch nicht mal shuffle...