Beiträge von Hitman47

    Hi cinfo,


    könntest du das Log vor allem nach "buffering" hochladen, vorzugsweise auf ein pastebin?
    Falls du einen lokalen Webserver hast, kannst du zum Testen auch einmal in audio_player.c

    Code
    // Get new songurl:
    std::string url(GetNextsongurl());

    nach

    Code
    // Get new songurl:
    std::string url(URL_ZUM_WEBSERVER_ODER_INTERNETRADIO);


    ändern.


    So long.

    Hi,


    Zitat

    Original von snowyrain
    Ich habe bei mir das Problem, das die Lieder nicht ausgespielt werden. Laufen die Lieder bei Dir durch?


    Besteht das Problem auch mit der letzten svn-Revision noch? Ich habe dir dazu auch mal eine PN gesendet.

    Hi,


    bei mir tauchen beim Beenden auch die kernel panics auf unabhängig davon, ob FrameRateControl an oder aus ist. Ich verwende archlinux mit Kernel 2.6.29-ARCH. Das radeon-Modul habe ich zusätzlich gepatched, weil es sonst aufgrund fehlerhafter "AGP-Adressierung" ohne Hardwarebeschleunigung lief und darum auch FRC nicht aktiv wurde. <http://bugzilla.kernel.org/show_bug.cgi?id=12441#c9>
    Bei sparkies VGA2SCART-Patch hatte ich auch schon Probleme beim Entladen der Module. Ich weiß nicht in wie weit das zusammenhängen kann.


    Ansonsten läuft der FRC-Patch wie geschmiert, danke dafür.


    So long.

    Hi,


    Gleich vorweg. Ist die SVN-Version, die du gezogen hast aus trunk, also 0.2.5-svn?


    Zitat

    Original von steffen_b
    2.) keine Texteingabe mehr möglich (nur noch Sonderzeichen)


    Es funktioniert, wenn man tr() weglässt. Also etwa so:

    Code
    Add(new cMenuEditStrItem(tr("Username"),
    				 newUsername, sizeof( newUsername ), cUtils::GetFileNameChars_lastfm() ) );


    Zitat


    Beim Starten kommt Handshake unsuccessfull bei der SVN Version, vorher aber auch. Angeblich unbekannter Benutzer. Gibts denn ne Möglichkeit Usernamen und md5 Hash händisch einzutragen ?


    Die Konfig-Datei liegt in <vdrplugins/lastfm/lastfm_config.xml>. Das ist erst seit dieser Version so. Vorher wurde in <vdrplugins/lastfm_config.xml> gespeichert.
    Händisch eintragen kannst du natürlich. Die MD5-Passphrase bekommst du auf der Konsole wie folgt:

    Code
    echo -n 'PASSPHRASE' | md5sum


    Wenn du die DEBUG-Schalter einstellst wie in der Datei DEBUG beschrieben, kannst man ganz gut verfolgen, wo es hängt.



    So long.

    Hi,


    du hast ja bereits geschrieben, dass ein ersetzen durch tr() funktioniert. Eine Übersetzung geschieht dadurch nicht, aber es lässt sich übersetzen ; (kompilieren).
    Das resultiert daraus, dass ab vdr-1.6.0 gettext zur Int'lization verwandt wird.


    So long.

    Hi,


    In der svn-Version gehen die webservices wieder. Die kannst du mit folgendem Befehl ziehen:

    Code
    svn co https://vdr-lastfm.svn.sourceforge.net/svnroot/vdr-lastfm/trunk lastfm-svn


    Meinst du mit "Text-Eingaben übers OSD" zum Beispiel Umlaute? Ich teste das bei Gelegenheit mal. Selbst verwende ich vdr-1.6.0


    So long.

    Hi Paulaner,


    Zitat

    Original von Paulaner
    Es scheint als wird laufend ein Skip-Signal gesendet, denn es wird kein Song mehr vollständig abgespielt, sondern ständig weitergeschaltet!


    Dann laeuft wahrscheinlich der Puffer leer. Kompiliere bitte auch einmal mit den oben genannten DEFINES. Die Logs koennten hilfreich sein.


    Ansonsten, falls du testwuetig bist, kannst du in der Datei config.h die Werte fuer SOCKETS_SELECT_MS und POLLTIMEOUT veraendern. Also zum Beispiel bei beiden 100 (Einheit ist ms) oder 50.
    Die Puffer sollten sich dabei anders fuellen. Halte mich auf dem Laufenden


    So long.

    Hi,


    kannst du die Version aus dem Subversion-Repo auschecken?


    Code
    svn co https://vdr-lastfm.svn.sourceforge.net/svnroot/vdr-lastfm/branches/VDR-LASTFM-0_2_3-whole lastfm


    Die Passphrase musst du dabei noch einmal eingeben. Gib mir bitte Nachricht wie sich diese Version verhält.


    Weitere Informationen zu Artist und Track bekommst du über die Taste 5 (Submenu)


    So long.

    Hi sparkie,


    Zitat

    gab es dafuer einen Grund? Im GIT ist naemlich einiger Treiber-Code, den der Xserver noch nutzt, nur noch als 'deprecated' enthalten. Der Crash haengt ebenfalls damit zusammen.
    - sparkie


    Danke für den Tipp. Ich hatte auch tatsächlich gleich einen Absturz beim Beenden des Xservers, der wohl daher kommt.
    Ich verwendete libdrm-git eigentlich nur aus Bequemlichkeit, weil ich dafür ein PKGBUILD angepasst hatte und wusste, dass es schon einmal durchkompilierte.
    Ich mache mich gleich daran, die Sourcen aus dem aktuellen Kernel anzupassen und zu kompilieren.


    Bei der Sache mit &dev->vbl_received komme ich aber glaube ich nicht weiter. Ich werde mir das aber trotzdem mal anschauen. Vielleicht finde ich etwas dazu.


    EDIT:
    Das neue struct dev_drm sieht in KERNEL-2.6.28-ARCH so aus (drmP.h):


    Ich habe nun vbl_received durch _vblank_count ersetzt.
    Auch habe ich auf der neuen Wikiseite gelesen, dass im upstream-Paket xf86-video-ati etwas getan wird. Aber mehr konnte ich da nicht herauslesen. Weißt du da mehr? Möglicherweise ist dieser Passus mit vblank gar nicht nötig?



    So long.

    Hi sparkie,


    ich habe mich gleich an die Arbeit gemacht und versucht zu patchen. Unter archlinux ist Kernel 2.6.28
    aktuell. Dabei änderte sich die Dateistruktur etwas (Verschiebung in das Verzeichnis <gpu/[radeon]> und
    Includedateien sind nun auch in </linux/include>.
    Das lässt sich aber eigentlich noch problemlos lösen, bin aber trotzdem auf die libdrm aus dem git-repo
    ausgewichen.
    Ich komme aber beim Patchen der Datei radeon_drv.c nicht weiter, wo es um vblanks geht:



    Der Fehler geht dabei von

    Code
    &dev->vbl_received


    aus, was scheinbar in neueren Versionen abgeändert wurde.
    Auch weiß ich nicht, wo die folgende Zeile hingehört, weil da auch noch andere vblank-Signale ausgelöst werden:

    Code
    radeon_handle_vblank(dev, VSF_CRTC);


    Testweise habe ich diese Codestellen einmal weggelassen und durchkompiliert. Es lässt sich soweit alles laden,
    aber ob es trotzdem funktioniert, kann ich aber gar nicht sagen. Am Wochenende werde ich das noch einmal genauer untersuchen.



    So long.

    Hi sparkie,


    ich kann mittlerweile praktisch keine Unterschiede zwischen DSF und Das Erste erkennen. Woran es nun
    gelegen hat kann ich gar nicht sagen, da ich nun mehrere Sachen verändert habe.
    Ich habe auf vdr-xineliboutput-cvs aktualisiert (der scr-Patch ist dort bereits integriert, verwendet wohl
    aber eine Defaulteinstellung von 5000). Daraufhin habe ich eine separate config_xineliboutput angelegt und
    per Pluginparameter mitgeteilt, wo diese liegt. Den scr-Wert habe ich dann wieder auf 200 gesetzt.
    Daraufhin konnte ich dem xine-lib-Log diese recht guten Werte entnehmen, wie ich finde:


    DSF:


    Xorg.0.log zum gleichen Zeitpunkt:


    Die Logs sehen auf Das Erste sehr ähnlich aus, allerdings nicht mehr so perfekt, wie ich es in vorigen Logs gesehen habe.
    Es sind aber auch keine Langzeittests, sondern nur kurze Abläufe, die ich gemacht habe.



    Das nächste Problem ist das Beenden von VDR und Xserver. Die Reihenfolge des Beendens scheint dabei gleichgültig zu sein.
    Der Rechner schmiert dabei, wie schon erwähnt, komplett ab. Auch die Magickeys funktionieren nicht.
    Nun habe ich die Originalmodule (drm.ko, radeon.ko) zurückkopiert und xf86-video-ati installiert. Damit bringe
    ich den Rechner nicht zum Absturz; wenigstens bis jetzt
    Weißt du Rat, wie ich das weiter eingrenzen kann bzw. wie ich den Rechnerabsturz verhindern kann. Mein Dateisystem
    scheint das nicht so gut zu verkraften, da die vdrconfigs nach dem Neustart meistens leer sind (channels.conf timers.conf)



    So long.

    Hi sparkie,


    Die Patches habe ich soweit alle aus dem vga-sync-fields-Patch eingespielt. Bei xine-lib ist im Log auch eine Meldung "STRAY" mehrfach vorhanden; die sollte, soweit ich weiß, erst nach dem Patchen vorhanden sein.
    Bei vdr-xineliboutput muss man ja immer etwas aufpassen, dass man auch mit " make install " die Bibliotheken für xine-lib installiert und nicht die alten verwendet. Auch das habe ich beachtet.


    Ich habe, um den Test zwischen Das Erste und DSF darzustellen, nur den Kanal gewechselt. Solange die Kanalinfo eingeblendet wird, wird scheinbar auch noch nicht geregelt:

    Code
    |<- -20ms                               0                              +20ms ->|      R                    248896
    |<- -20ms                               0                              +20ms ->|      R                   1410106
    |<- -20ms                               0                              +20ms ->|


    Das Bedeutet wohl, dass das OSD nicht das Problem verursacht.


    Ich habe heute noch einmal den Test wiederholt:
    Das Erste:



    Hier sind die Sprünge nicht mehr so groß wie im vorigen Test, allerdings bleibt das Verhalten gleich. Wenn ich nun wieder auf Das Erste zurückschalte, sind die Sprünge wieder wie im vorherigen Log zu Das Erste; also wohl reproduzierbar.


    Noch eine Auffälligkeit:
    Ich nutze inittab um mit init den VDR inkl. X zu starten und zu beenden. Nun ist es so, dass der Rechner gelegentlich komplett abschmiert. Debugmeldungen kann ich dabei nicht auswerten. Ich weiß nicht, ob der DRM-Patch daran Schuld sein kann. Es ist aber subjektiv so, dass das bei durchfliegers Variante seltener passiert. Es ist dabei auch scheinbar unerheblich, in welcher Reihenfolge VDR und Xserver beendet werden.
    Ich kann im Moment auch nicht ausschließen, ob vdr-xineliboutput dass verursacht. In der ungepatchten Variante ist es vielleicht auch schon einmal vorkommen. Das sind dementsprechend vage Vermutungen und ich schreibe das nur in der Hoffnung, dass sich darauf jemand etwas zusammenreimen kann.



    So long.

    Hi,


    ich habe nun den letzten Patch von durchflieger (radeon-frc-v0.10) und sparkies
    vga-sync-fields-0.0.11 auf dem Pundit-R (IGP9100) getestet.
    Als erstes möchte ich anmerken, dass Beide problemlos funktionieren (archlinux; 2.6.28-ARCH).
    Allerdings kompiliert vga-sync-fields-patch nicht mit xv86-video-ati-6.11.0
    Der Patch geht mit ein paar hunks durch, aber:


    Code
    gcc -DHAVE_CONFIG_H -I. -I.. -I./AtomBios/includes -Wall -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/X11/dri -DDISABLE_EASF -DENABLE_ALL_SERVICE_FUNCTIONS -DATOM_BIOS -DATOM_BIOS_PARSER -DDRIVER_PARSER -march=i686 -mtune=generic -O2 -pipe -MT radeon_video.lo -MD -MP -MF .deps/radeon_video.Tpo -c radeon_video.c  -fPIC -DPIC -o .libs/radeon_video.o
    radeon_video.c: In function 'RADEONPutImage':
    radeon_video.c:2877: error: 'struct <anonymous>' has no member named 'drmFD'
    radeon_video.c: In function 'vga_sync_fields':
    radeon_video.c:4193: warning: suggest parentheses around arithmetic in operand of |


    Daher kann ich hier nicht direkt vergleichen; es kommt also wie vorgesehen
    xf86-video-ati-6.9.0 zum Einsatz.


    Durchfliegers Patch scheint mit den Standardeinstellungen nicht so aggressiv zu
    regeln. In den Logs sind die Nachregelungen träger, als bei sparkies Patch.
    Subjektiv gesehen, gefällt mir sparkies vga-sync-fields-Patch besser.


    Weiter Auffälligkeiten, die nicht Patch-spezifisch sind:
    Wenn ich auf Das Erste fernsehe, scheint es viel genauer zu regeln, als z.B. auf DSF. Scaling ist
    in vdr-xineliboutput-1.0.4 deaktiviert, soweit ich das beurteilen kann.
    Was kann das verursachen oder ist doch etwas in den Konfigurationsdateien (im Anhang) falsch?


    Auszug aus Xorg.0.log vga-sync-fields; Das Erste:


    Gegenbeispiel zu Obigem bei DSF (vermutlich niedrigere Auflösung)


    Zum Testen finde ich Trickfilme (ich sehe dazu Family Guy) ganz praktisch, da dort große Kontrastflächen
    vorhanden sind, die Streifen (Kammeffekt) und Umrisse offenbaren, wenn nicht nachgeregelt wird.
    Diese sind subjektiv gesehen praktisch nicht vorhanden, wenn ich den vga-sync-fields-Patch einsetze,
    beim FRC-Patch meine ich aber gelegentlich einen feinen Kammeffekt gesehen zu haben.
    Das ist natürlich eine sehr subjektive Sicht der Dinge.



    So long.

    Zitat

    Original von avanix

    Code
    avanix@vdr:~/libdrm-2.4.3/linux-core$ grep -r DRM_IOCTL_RADEON_FRAME_RATE_CONTROL .
    ./radeon_drm.h:#define DRM_IOCTL_RADEON_FRAME_RATE_CONTROL      DRM_IOWR(DRM_COMMAND_BASE + DRM_RADEON_FRAME_RATE_CONTROL, drm_radeon_frame_rate_control_t)


    ich glaube der patch ist da, oder?


    Ja, der Patch ist wohl da.
    Ein anderer Versuch wäre es, nun folgende Befehle abzuarbeiten:

    Code
    rmmod radeon
    rmmod drm
    insmod [...]./linux-core/drm.ko
    insmod [...]./linux-core/radeon.ko


    So sollten dann auf jeden Fall die gepatchten Module verwandt werden. Das ganze musst du mit beendetem X-Server machen.
    Du kannst das auch etwas nachvollziehen, indem du dmesg nach dem Entfernen und Neuladen der Module aufrufst.




    So long.

    Hi


    Zitat

    Original von avanix
    Die FRC lässt sich in Mode 4 nicht starten:
    Wenn die Wiedergabe beginnen sollte kommt:

    Code
    (EE) RADEON(0): [drm] setting frame rate trim value failed! Frame rate control disabled


    Hast du folgendes aus der README des FRC-Patches genau befolgt?; zur Not kannst du das System mal neu starten.




    So long.