Posts by e-PUNK

    unter windows kann ich inzwischen wieder alles super mit gknot zu divx encodieren. unter linux hab ich mich lange nicht mit der sache beschäftigt. steht aber immer noch auf meiner todo-liste endlich die perfekte vollautomatische lösung für meine ansprüche aus dem vorhandenen zu generieren. mal sehn wann ich wieder zeit für mein altes hobby hab. aber wenns dir nix ausmacht probier doch mal unter windows. tipps gibs auch von mir. is nat. die frage, ob das dann auch noch zum themen kreis hier hingehört. mal schaun ab nen par andere unter linux lösungen haben.


    grüße
    e-PUNK


    ps: bei mir hat bis auf halbbilder (nur mit abstrichen) divx unter ma.hoffs vdr2divx (is übrigens eine andere vdr-erweiterung als vdr-convert, guckst du ma.hoffs hompage) damals eigentlich immer alles gut funktioniert. Ich schau gleich mal was ich aus dem ersten posting noch nachvollziehen kann, is ja ne weile her dat janze. oder hast du eigene andere fehlermeldungen?

    So nochmal zur OSS-Funktionalität vom mp3-plugin ver 0.9.3:
    Habe vom Stefan (der Macher) nen patch erhalten. Das Problem beschreibt Stefan so:


    Quote

    Die DVB Karte benutzt big-endian Samples. Normalerweise sollten das Soundkarten
    Treiber auch können oder zumindest ordentlichen Fehler melden falls nicht. Um
    das ganze zu umgehen, benutze ich bei OSS jetzt die üblichen litle-endian
    Samples


    Ich poste den patch hier mal in seinem Auftrag. In der nächsten version ist das dann mit drinn, sagt er.
    Bei mir läuft nun OSS wunderbar und dank gom (audiomixer) auch schön laut.


    Gruß e-PUNK

    Ich glaube auch das mit dem sleep 10 muss nicht immer funktionieren.
    Ich bilde mir ein, dass liegt an der Überschneidung mit einer anderen svdrp connection z.B. von vdradmin. Dadurch wird der HITK Power Befehl manchmal nicht ausgeführt.
    Ich zitiere mich mal aus der ML, am ende gibts auch eine Lösung in Form eines sleeptimer.sh skripts.


    [vdr] SVDRP - problems when 2 sends nearly at same time -> e.g. vdradmin disturbs sleeptimer


    [vdr] Re: SOLUTION: vdradmin disturbs sleeptimer


    Grüße
    e-PUNK

    Da der Entwickler diesen Thread aber gar nicht erstellt hat, musst du mit ihm anders Kontakt aufnehmen als über diesen Thread. Ich habe wegen meinem Problem (s.o.) mit ihm Kontakt per e-Mail. Ich hab erfahren, dass er die VDR-Mailingliste abboniert hat. Dies ist für ihn die Haupt-Plattform bei der Kommunikation rund um VDR. Also: Auf liinuxtv.org vdr-ml subscriben und dort mal nett fragen, oder vielleicht auch ne nette Mail direkt an den Stefan Huelswitt. Gruß e-PUNK

    Wie du ja sagst, ist das mit den Covers durch einen Patch möglich. Dieser Patch ist wohl von einem anderen Author als der des mp3-plugins. Du musst also diesen Author fragen, ob er seinen Patch auch für 0.9.3 macht. Vielleicht entschließt sich irgendwann auch einmal der mp3-plugin-entwickler dazu diesen patch mit in seinen code aufzunehmen. Die Frage ist, ob er überhaupt weiß, dass dieser Patch existiert?


    Gruß e-PUNK

    Das liegt sicher daran, dass m3u-Listen jetzt anders behandelt werden als vorher. Vorher wurden sie wie jede datei einfach als txt-files behandelt. Aber nun sind es playlisten. Wenn du mehrere Streams in einer m3u-Playlist haben möchtest, könnte ich mir vorstellen, dass du für jeden Stream eine txt-Datei anlegen musst und diese txt-dateien dann alle in einer m3u-Playliste aufführst. Probier das doch mal.


    Gruß e-PUNK

    Hi Hulk


    Ich hab da mit vdr 1.2.6. und Komplettpatch-1.2.6-F
    + deinem icy-2-patch für das mp3-plugin noch folgendes im syslog festgestellt:



    Wenn ich deinen patch mit patch -p1 -R entferne tritt diese meldung nicht auf. Könntest du das noch fixen? Danke.


    Liebe Grüße
    e-PUNK


    PS: Groove.mp3 ist ein txt-file mit ner url zu nem stream. Hab ich nur so benannt, damit trotz filter *.mp3 aus der sourceslist meine streams im mp3-browser auswählbar sind.

    Auch ist es wichtig, dass der kernel mit dem gleichen kompiler wie der dvb treiber kompiliert wird. Wenn du also beispielsweise von stable auf testing umsteigst, ändert sich möglicherweise das gcc-packet. Wenn du nun den dvb-treiber kompilerst, passen die erzeugten dvb-module nicht mehr in den kernel der noch mit dem stable-gcc erstellt wurde. Also mal am besten auf der debian-faq und in /usr/share/doc/kernel-package lesen, wie man nen neuen kernel kompiliert. Natürlich lohnt der Aufwand nur, falls du tatsächlich durch einen upgrade die gcc-version erhöht hast!
    Ist jedoch nichts für Anfänger, du solltest noch ein paar Ratschläge von debianern einholen!


    Gruß e-PUNK

    Mal ne Frage:


    Woran kann das liegen, dass GRAB das Bild nur abgeschnitten erstellt? Irgendwann vor ein paar Monaten ging das noch korrekt. Liegts am DVB-Treiber? Ich hoffe nicht, denn dann müsste ich kernel und Treiber-Module neu kompilieren, da apt-get mir ne neue gcc-version draufgeklatscht hat. Das heißt demnach, mein Kernel und mein DVB-Treiber sind mit nem anderen gcc kompiliert als der vdr. Hoffe das isses nich!? Wie kann ich den Fehler nun am besten einkreisen, ohne gleich mit dem dicken Hammer allet neu aufzusetzen?


    Danke
    e-PUNK


    Config:


    vdr:.........1.2.6-KPP-1.2.6F
    dvb:........1.0.1 oder kernel-driver (weiß nich genau! Was ich weiß, ich lade in der runvdr mit modprobe ... aus /lib/modules/2.4.20, weiß aber nich mehr ob die *.o files aus dem dvb-kernel-driver oder aus dem dvb-1.0.1 kommen)
    kernel:.....2.4.20
    distri:.......debian sid

    Quote

    Leider hatte dieses Streaming nie richtig funktioniert, deswegen hatte ich das erst mal wieder rausgenommen bis es dafuer eine akzeptable Loesung (Alternative zu ffserver) gibt.


    Aber das Streamen des Livesignals war doch bisher ohne ffsever realisiert, mit dem Streamdev-plugin und dem Abspielen des originalen mpeg2-Streams z.B. via VLC oder mplayer. Das ging doch eigentlich ganz gut.
    Na und zum Anschauen der Aufnahmen scheint doch die Samba-variante wie in der ct-version recht passabel, oder?


    Ach ja, xpix, nochmal zu dem Problem mit dem abgeschnitten GRAB-Bild was ich weiter oben gefragt hab? Kann das am DVB-Treiber liegen? Vielleicht mit dem falschen Kompiler erstellt, oder falscher Treiber. Dast Bild /tmp/vdr.jpg selbst ist schon abgeschnitten. Vdradmin macht also definitiv keinen Fehler. Aber was kann ich tun, um das Problem einzukreisen?


    Gruß e-PUNK

    Nächste Frage:
    Warum ist in der 0.9pre5 das Streamen des aktuellen Programms über streamdev nicht mehr konfigurierbar und somit auch nicht mehr möglich. Hat das was mit den Änderungen bezüglich ffserver-streaming wie in der README erwähnt zu tun. Wenn ja, was?


    Gruß e-PUNK

    Der EAIO-Patch ist nur ein Teil des sog. Komplettpatches.
    Die Frage nach dem Komplettpatch für 1.3.6 ist mit dem Link zum EAIO-Patch also nicht beantwortet.


    Mein Tip ist, in diesem Forum nach dem Author des Komplettpatches 1.2.6-F zu suchen und mal vorsichtig anzufragen, ob und wann ein neuer Release für die höheren VDR-versionen kommt. Ich vermute mal, dass viele der im Komplettpatch enthaltenen Patches noch nicht für höhere VDR-Versionen angepasst sind. Damit gibt es also auch noch keinen Komplettpatch, denn der wird einfach aus allen Einzelpatches zusammengebastelt. Das kann noch dauern. Ich könnte mir denken, dass zu der nächsten stable Version wieder Komplettpatches auftauchen werden.


    Gruß e-PUNK

    hab die lösung gefunden, falls das noch jemand interessiert.


    at und wine funzt,
    wenn in dem script in dem wine auf gerufen wird


    export TERM=?


    auf einen gültige Wert für ein Terminal gesetzt wird.


    das export der variable ist der entscheidende Faktor:


    Ein Beispiel:

    Code
    echo 'export TERM=cygwin; wine c:\\...\\cPVAS.exe <options> > /log' | at now


    Anzeigen ob sich bei wine denn auch was getan hat kann man nun mit

    Code
    cat /log


    Ich hab auch aufnahmen, die vdrsync.pl nicht kann, cpvas.exe aber schon.
    So nun funzt bei mir das divxen mit vdr2divx+pvastrumento.


    Ich hab das export TERM=cygwin einfach ganz oben in die 2divx.sh hinzugefügt. Is sicher n bissl dirty. Ne abfrage ob $TERM ungleich "dumb" ist, wäre vielleicht noch angbracht.


    Grüße vom e-PUNK

    Hallo Leute,


    ich hab noch ne kleine Änderung (Verbesserung/Bugbehebung) im Skript


    improovements\2divxinfo.sh


    in dem Anhang des vorherigen Posts von mir getätigt.


    Was sagt ihr zu meiner Lösung?
    Ein Problem hatte ich mit ner Aufnahme von NDR letztens noch:
    Die ersten 10 sec des Spielfilmes hat der NDR noch in Mono gesendet.
    Dann schaltete man endlich auf Stereo um.
    Schneidet man diese 10 sec nicht weg so gibt vdrsync.pl lauter Warnings aus und es entsteht nur ein mono *.mpa File. Dies wird in vdr2mp3 ja dann lame als Input übergeben.
    Auf diese Weise hab ich gleich noch ein BUG in lame festgestellt, denn lame bleibt mit dem File in einer Endlosschleife bei voller CPU-Last hängen.
    Das Wegscneiden des Monoanteils hat geholfen.


    Besser währe vdrsync.pl noch eine --if-mischmasch-force-stereo option hinzuzufügen. Das Verhalten von vdrsync sollte dann so sein, dass es bei mono stereo-gemischten Audio-Spuren den Monoanteil in Stereo umwandelt. Das sieht mir noch etwas Arbeit aus.


    Gruß e-PUNK


    PS: Das vdrsync.pl in meinem 2divx.zip ist gegenüber dem Original übrigens leicht von mir modifierziert: Ich habe es so verändert, dass die Video-Spur nicht demuxed wird, sondern nur die Audio-Tracks. Das Video nimmt der Mencoder wieder direkt aus den *.vdr Files.

    Matzetronic


    ja, das originalfile geht ohne aussetzter. Da mein windowsplayer (Zoomplayer) und auch der win32-mplayer die encodierten files mit exact den selben rucklern abspielen, geh ich einfach mal davon aus, dass "skipped frame" wirklich bedeutet, die frames sind weg. Leider sieht man das sehr auffällig bei der Wiedergabe. Google-search und auch Martins Tipps haben ergeben, dass es wohl an der Audiospur liegt. Ein Indiz ist, dass mit


    mencoder -nosound


    alles flüssig läuft. Es werden auch keine Frames mehr gedropped.


    martin


    Naja ich hab nun eine Lösung mit der pre7 gefunden, wie es scheint. Ich war bisher auch immer noch etwas der neuen pre8 gegenüber etwas abgeneigt, da dein changelog größere Änderungen erwähnt. Da ich selber auch in den Skripten rumgemalt habe, sieht ein upgrade nach Arbeit aus, die sich vielleicht nicht lohnt. Noch kurz zur deutschen Mlayerversion ein Wort: Grundlegende Änderungen an meinem VDR mache ich immer mit dem aktuellen install-script, und da hab ich halt immer wenn ich Mplayer installiere ein Häckchen bei de gemacht. :)
    Es sind übrigens mehrere Aufnahmen, die Frames skippen: Einige lavc-Filmchen von VDR-Kumpels zucken, und bei mir sind es Aufnahmen auf ZDF. Ne Vorabendserie mit schwarzen Balken --> nehme mal an 16:9. Bei miener folgenden Lösung habe ich auch festgestellt, das offenbar 2 Audiospuren vorhanden sind: ac3 und mp2. Die mp2-Spur ist 48 kHz (is das üblich? oder doch häufiger 44.1?)
    Naja meine Lösung basiert auf einem anderen Problem, was mich hier schon einmal beschäftigt hat:


    http://www.vdr-portal.de/board/thread.php?threadid=5215&sid=&hilightuser=1922


    Da geht es um eine Lösung bei Filmen mit 2 Tonspuren.
    Ich hab die Vorgehnswiese über


    mencoder -nosound
    demux via vdrsync.pl
    und
    mux via avimerge


    jetzt in mein 2divx-Skript eingenbaut.
    Ich kann nun vollautomatisch 2-Tonspur-avis erzeugen. Und die Probleme mit den Framedrops sind dank -nosound behoben!


    Ich hänge mal meine veränderten Files an.
    Die Änderungen hab ich nur für lavc und mp3 128 gemacht, da ich bisher nur sowas brauche. Aber inspirieren lassen kann mann sich ja davon.


    Gruß e-PUNK