Beiträge von gda

  • [Closed] VDR 1.4.6 mit Ext.-Patch v.23 für LinVDR 0.7

    Ich benutze Deinen vdr jetzt auf meinem Client, ich habe aber auch mit dieser
    Version das Umschaltproblem mit dem Streamdev-Plugin. Wenn ich ganz lieb bitte, bitte sage,
    kann ich dann vielleicht eine Version des plugins mit Schmirls Patch bekommen?
    Wenn das nicht geht, wie bekomme ich am schnellsten eine Entwicklungsumgebung um den
    Plugin selbst zu compilieren? Ich habe Ubuntu Edgy Eft und eine VMWare-Instanz mit Mahlzeit
    und Compiler ... zur Verfügung. Ich müsste mir wohl nur die Quellen irgendwo zusammenklauben
    und hoffen das alles passt.


    Danke
    Gerald

  • K6-333 zu langsam für VDR?

    Kernel 2.6.18 bringts auch nicht :(

    Code
    ~# uname -a
Linux linvdr 2.6.18.8 #1 PREEMPT Fri Mar 9 11:08:28 CET 2007 i586 unknown


    Interessant ist, dass der transfer thread [1212] und der receiver [1213] die höchste Last
    erzeugen. Die DXR3-Threads kommen zusammen nicht mal auf 20%.


    Ich war so naiv zu glauben, dass hier nur die Daten übers LAN gepumpt werden. Hat
    jemand eine Idee warum diese Threads soviel CPU brauchen?



    Code
    Mar  9 16:39:30 linvdr user.debug vdr: [1206] DXR3 audio output thread started (pid=1206, tid=1206)
Mar  9 16:39:30 linvdr user.debug vdr: [1207] DXR3 video output thread started (pid=1207, tid=1207)
Mar  9 16:39:30 linvdr user.debug vdr: [1208] streamdev-client: sections assembler thread started (pid=1208, tid=1208)
Mar  9 16:39:30 linvdr user.debug vdr: [1209] section handler thread started (pid=1209, tid=1209)
Mar  9 16:39:30 linvdr user.debug vdr: [1210] LIRC remote control thread started (pid=1210, tid=1210)
Mar  9 16:39:30 linvdr user.debug vdr: [1211] KBD remote control thread started (pid=1211, tid=1211)
Mar  9 16:39:30 linvdr user.debug vdr: [1212] transfer thread started (pid=1212, tid=1212)
Mar  9 16:39:30 linvdr user.debug vdr: [1213] receiver on device 6 thread started (pid=1213, tid=1213)
Mar  9 16:39:30 linvdr user.debug vdr: [1214] TS buffer on device 6 thread started (pid=1214, tid=1214)


    Gruß
    Gerald

  • K6-333 zu langsam für VDR?

    Zitat

    PS: Der Client sollte dank der DXR3 in der Tat nicht überlastet sein; auch wenn ich selber noch nie einen AMD K6-333 eingesetzt habe...


    Sondern? Was war der langsamste Prozessor?


    Ich frage mich ob ein Kernel mit CONFIG_MK6 übersetzt, noch ein bisschen
    was zusätzlich bringt. Welche DXR3-Treiber-Version setzt du ein? Der Thread,
    der mit der DXR3 arbeitet, erzeugt ja die höchste Last.


    Ich kann ja den 2.6.18 Kernel von Dr. Seltsam nicht direkt benutzen,
    weil der nicht von NFS bootet. Außerdem ist der so groß, der Prozessor
    braucht unheimlich lange um ihn zu entkomprimieren. Ich habe viel
    rausgeschmissen. Ich baue ihn deshalb frisch, ohne
    irgendwelche patches, aus vanillla sources. Lediglich Lirc- und Dxr3-Treiber
    kommen dazu.

  • K6-333 zu langsam für VDR?

    Zitat

    Zurück zu 2.6.18 und die Welt war wieder in Ordnung...


    Das ist doch mal eine eindeutige Aussage, es gibt also noch Hoffnung.
    Allerdings hatte ich darüber im Dr. Seltsam-Kernel-Thread schon gelesen und
    es hatte ein bisschen was von Voodoo.
    Trotzdem baue ich mir als nächstes erstmal einen Kernel 2.6.18.


    Blöd nur, dass ich den streamdev-plugin auch noch patchen muss damit er
    mich zappen lässt.


    Danke
    Gerald

  • K6-333 zu langsam für VDR?

    Zitat

    Such mal im Log nach Meldungen "thread startet (pid=... tid=...) in denen die PID aus "top" vorkommt.


    Mal sehen wann ich dazu komme, meine Frau kommt heute zurück, werde nicht mehr so viel Zeit dafür haben.


    Zitat

    Wie sieht es aus wenn Du einen Sender mit sehr niedriger Bandbreite einstellst (bei DVB-S am besten einen Standbild-Sender raussuchen)?


    Ich hab nur die PVR350 und die DVB-T Karte, getestet habe ich mit dem
    Signal von der PVR. Da ist die Bandbreite ja eh nicht so hoch.


    Zitat

    Ist die Last dann ähnlich hoch?


    Was würde Dir diese Informationen sagen?


    Zitat

    Könnte schlechte Empfangsqualität sein


    Das Bild auf dem Server ist aber Klasse und ruckelt nicht. Die PVR ist ja auch direkt am Kabel angeschlossen. Ein anderer Client mit einem AMD 2800+
    XP streamt das Bild auch völlig ohne Ruckeln.


    Zitat


    Um auszuschließen das es ein Kernel-Problem ist, würde ich mal das Mahlzeit-ISO testen.


    Gut, dann muss ich erstmal wieder eine Platte einbauen. Ist etwas
    tricky, weil ich kein CD-Rom anschließen kann, aber das kriege ich hin.


    Ich frage mich ob es wohl weniger Last wäre, wenn ich statt vdr mit streamdev-client, aaxine auf dem client und libxineoutput auf dem server
    benutzen würde?

  • K6-333 zu langsam für VDR?

    @smirl: danke das Du mir Mut machst es nochmal zu versuchen.


    top sagt:


    ein paar Auszüge aus logread:


    Ich nehme an das hat wohl nichts zu bedeuten:

    Code
    Mar  7 17:01:08 linvdr user.err vdr: [1090] Streamdev: Filter 18, 78, 254 not available from 192.168.99.5:2670                                               
Mar  7 17:01:08 linvdr user.err vdr: [1090] Streamdev: Filter 18, 80, 240 not available from 192.168.99.5:2670                                               
Mar  7 17:01:08 linvdr user.err vdr: [1090] Streamdev: Filter 18, 96, 240 not available from 192.168.99.5:2670                                               
Mar  7 17:01:08 linvdr user.err vdr: [1090] Streamdev: Filter 20, 112, 255 not available from 192.168.99.5:2670                                              
Mar  7 17:01:08 linvdr user.err vdr: [1090] Streamdev: Filter 0, 0, 255 not available from 192.168.99.5:2670                                                 
Mar  7 17:01:08 linvdr user.err vdr: [1090] Streamdev: Filter 17, 66, 255 not available from 192.168.99.5:2670                                               
Mar  7 17:01:08 linvdr user.err vdr: [1090] Streamdev: Filter 16, 64, 255 not available from 192.168.99.5:2670


    das wiederholt sich immer wieder:

    Code
    Mar  7 17:01:15 linvdr user.debug vdr: [1127] dxr3: audiodecoder: sample rate=48000                                                                          
Mar  7 17:01:15 linvdr user.debug vdr: [1127] dxr3: audiodecoder: channels=2                                                                                 
Mar  7 17:01:16 linvdr user.debug vdr: [1127] dxr3: audiodecoder: sample rate=48000                                                                          
Mar  7 17:01:16 linvdr user.debug vdr: [1127] dxr3: audiodecoder: channels=2                                                                                 
Mar  7 17:01:17 linvdr user.debug vdr: [1127] dxr3: audiodecoder: sample rate=48000                                                                          
Mar  7 17:01:17 linvdr user.debug vdr: [1127] dxr3: audiodecoder: channels=2


    bis es dann durch das hier abgelöst wird:

    Code
    Mar  7 17:01:26 linvdr user.err vdr: [1128] ERROR: skipped 46 bytes to sync on TS packet on device 6                                                         
Mar  7 17:01:26 linvdr user.err vdr: [1128] ERROR: skipped 21 bytes to sync on TS packet on device 6                                                         
Mar  7 17:01:26 linvdr user.err vdr: [1128] ERROR: skipped 123 bytes to sync on TS packet on device 6                                                        
Mar  7 17:01:27 linvdr user.err vdr: [1128] ERROR: skipped 171 bytes to sync on TS packet on device 6                                                        
Mar  7 17:01:27 linvdr user.err vdr: [1128] ERROR: skipped 89 bytes to sync on TS packet on device 6                                                         
Mar  7 17:01:28 linvdr user.err vdr: [1128] ERROR: skipped 28 bytes to sync on TS packet on device 6                                                         
Mar  7 17:01:28 linvdr user.debug vdr: [1127] PES packet shortened to 552 bytes (expected: 2034 bytes)


    Mit unterschiedlichen Zahlenangaben wiederholt sich das immer wieder


    Dmesg zeigt nicht auffälliges:


    Übrigens benutze ich im Moment Kernel 2.6.19.3, weil ich mit 2.6.20 den lirc nicht übersetzt
    bekam. Den dxr3-Treiber habe ich aus dem CVS, weil der stabile mit dem Kernel nicht wollte.
    Lohnt es sich hier vielleicht andere Treiber- Kernel-Versionen auszuprobieren? Allerdings
    sieht es ja so aus, als würde nicht der dxr3-treiber das Problem ist.


    Gruß
    Gerald

  • K6-333 zu langsam für VDR?

    Mein Igel-J, der ein Mahlzeit-3.2 iso per NFS bootet, ruckelt leider.
    Logread zeigt, dass er immer wieder Bytes wegwirft um synchron zu bleiben.
    Die 333MHz AMD-K6 CPU reicht wohl nicht. Bevor ich mich jetzt auf
    Hardware-Suche begebe und den Zorn des Finanzministers auf mich ziehe,
    frage ich hier noch mal nach, ob hier jemand eine Idee für eine Tuning-Maßnahme hat.


    Ich schrecke auch vorm Kernel umkonfigurieren nicht zurück. Musste ich ja
    sowieso machen um von NFS booten zu können.


    Ich benutze nur den Streamdev-Client-Plugin und den DXR3-Plugin.
    Arbeitet in dieser Konfiguration eigentlich der Livebuffer? Wäre wohl
    kontraproduktiv, da der Streamdev-Client-Plugin wohl eh schon buffert,
    oder?


    Logging abschalten wird wohl nicht viel bringen.


    Es wäre nett wenn Ihr ein paar Ideen hättet.


    Gruß
    Gerald

  • graphlcd findet libserdisp.so nicht, falscher link

    Das GraphLCD findet die libserdisp.so nicht, weil ein link falsch ist:

    Code
    /usr/lib/libserdisp.so -> usr/lib/libserdisp.so.1.97


    Das sollte eigentlich so aussehen:

    Code
    /usr/lib/libserdisp.so -> /usr/lib/libserdisp.so.1.97


    Die ownership von /usr/lib/libserdisp.so.1.97 sieht auch ein bisschen komisch aus, ist aber
    keine Problem, weil alle lesen dürfen.


    Leider funktioniert mein Display trotzdem nicht. Ich habe die Buchse für das Folienkabel
    von einem Profi löten lassen und hatte dann plötzlich während des Betriebs die Buchse
    in der Hand. Das mochte das Display wohl nicht.
    Nachdem die Buchse nun wieder angelötet ist, geht zwar noch das Backlight und ich kann
    mit testserdisp punkte setzen und testserdisp meint auch sie wären gesetzt, aber auf dem
    Display ist nichts zu sehen. :(


    Gruß
    Gerald

  • Mahlzeit-ISO 3.2

    xxv hat wohl doch noch ein paar Perl-Probleme:


    Code
    Can not load Module: SOAP::Lite
Please install this module on your System:
perl -MCPAN -e 'install SOAP::Lite'


    Code
    main: Can't locate Encode.pm


    Code
    Can not load Module: Net::XMPP
Please install this module on your System:
perl -MCPAN -e 'install Net::XMPP'


    Code
    Can not load Module: SOAP::Transport::HTTP                                                                                                                   
Please install this module on your System:                                                                                                                   
perl -MCPAN -e 'install SOAP::Transport::HTTP'


    Hab aber keine Zeit nach der Ursache zu suchen. Ist hier eventuell
    auch der Download irgendwo in den Installations-Skripten schiefgegangen?


    Gerald

  • Kernel 2.6.20.1 für LinVDR

    Zitat

    ivtv-Treiber 0.10 inkl. neuer Encoder-Firmware Achtung: dafür sind angepasste Versionen von pvrinput + pvr350 notwendig, die noch nicht für LinVDR kompiliert bereitstehen. Ich hoffe aber, dass das in wenigen Tagen der Fall sein wird. Ich habe mich trotzdem entschieden, den Kernel schon jetzt bereitzustellen, da die Mehrheit der Nutzer keine PVR-Karten einsetzt.


    Wie wirkt sich das denn aus? Nach einem linvdrupdate hatte ich plötzlich diese Konstellation:


    Code
    filename:       /lib/modules/2.6.18/kernel/drivers/media/video/ivtv/ivtv.ko
version:        0.10.0 (v4l-dvb + ivtv virtual merge) Revision: 3791


    Ivtv wollte nicht mehr laden, weil das Firmware-File nicht mehr passte. Ich hab mir eine
    neue Firmware besorgt und es ging wieder. Ich benutze pvrinput, kann es aber nicht richtig
    Testen, weil ich zu weit von der Antenne weg bin. Deshalb sehe ich nur Schneegestöber
    wie vor dem update. Heist das, das es doch mit dem neuen ivtv und dem alten pvrinput geht?


    Gerald

  • Mahlzeit-ISO 3.2

    Der Patch tuts jetzt bei mir erstmal:


  • Mahlzeit-ISO 3.2

    Hallo,


    nachdem ich die vergangene Woche so ziemlich jede VDR-Distri durchprobiert habe, bin
    ich jetzt doch beim Mahlzeit iso hängengeblieben. Hier sind die Probleme am geringsten ;).


    Bitte steinigt mich nicht, wenn das was ich hier beschreibe schon bekannt ist. Der Thread
    ist ja schon etwas länger. Die Fehlermeldungen sind schon mal in einem Log in diesem
    Thread aufgetaucht, aber es ist keiner drauf eingegangen.


    Der Skript marks2pts_mahlzeit-iso-3.2-install.sh funktioniert nicht, weil 2 URLs falsch sind.
    1. http://ftp.de.debian.org/debia…ibwww-perl_5.64-1_all.deb
    in dem Verzeichnis gibt es nur noch libwww-perl für ein etwas frischeres Perl.
    2. attachment.php?attachmentid=13200
    Ich denke das sollte attachment.php?attachmentid=13261 sein, da gab es unlängst ein Update
    für die Sharemarks. In einem anderen Thread habe ich darüber gelesen.


    Mich stört etwas, dass der linvdrupdater so weitermacht als sei nichts geschehen, und auch
    bei einem erneuten Aufruf nicht nochmal versucht Sharemarks zu installieren, weil in
    /etc/linvdrupdater die entsprechenden Files trotzdem erzeugt werden.


    Für die Lösung des ersten Problems gibt es nur die Möglichkeit
    einen Server mit diesem alten Perl-Paket finden, oder auf ein etwas moderneres Perl wechseln.
    Die zweite Möglichkeit ist sicherlich etwas aufwändiger, aber bei einer so
    kleinen Distribution sicherlich in den Griff zu kriegen und irgendwann muss es einfach
    gemacht werden.


    Gruß
    Gerald