Beiträge von 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?

Hier ist übrigens meine Variante des Tonspurwechsels beschrieben. Ich mache das nur bei avis. Lässt sich aber leicht auch für mpegs erweitern.

http://www.vdr-portal.de/board/thread.php?threadid=7344

Gruß e-PUNK

PS: Überspringt einfach die Zankereien in dem Thread

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:

Zitat

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

Zitat

Hi,

I'm using stable vdr 1.2.6.

The following commandline demonstrates a problem, that lets e.g. the sleeptimer-plugin not work correctly in conjunction with vdradmin. (Well, thats what I think the problem is, cause there are no errormessages from sleeptimer)

i=0; while true; do svdrpsend.pl MESG $i & sleep 2 ; i=$((i+1)) ; done

/var/log/syslog:

Jul 17 11:14:16 mediaportal vdr[708]: SVDRP message: '0'
Jul 17 11:14:16 mediaportal vdr[708]: info: 0
Jul 17 11:14:18 mediaportal vdr[708]: connect from 127.0.0.1, port 1305 - accept
ed
Jul 17 11:14:18 mediaportal vdr[708]: SVDRP message: '1'
Jul 17 11:14:19 mediaportal vdr[708]: info: 1
Jul 17 11:14:20 mediaportal vdr[708]: connect from 127.0.0.1, port 1306 - accept
ed
Jul 17 11:14:20 mediaportal vdr[708]: SVDRP message: '2'
Jul 17 11:14:23 mediaportal vdr[708]: connect from 127.0.0.1, port 1307 - accept
ed
Jul 17 11:14:23 mediaportal vdr[708]: SVDRP message: '3'
Jul 17 11:14:23 mediaportal vdr[708]: info: 3
Jul 17 11:14:24 mediaportal vdr[708]: connect from 127.0.0.1, port 1308 - accept
ed
Jul 17 11:14:24 mediaportal vdr[708]: SVDRP message: '4'
Jul 17 11:14:26 mediaportal vdr[708]: connect from 127.0.0.1, port 1309 - accept
ed
Jul 17 11:14:26 mediaportal vdr[708]: SVDRP message: '5'
Jul 17 11:14:27 mediaportal vdr[708]: info: 5
Jul 17 11:14:28 mediaportal vdr[708]: connect from 127.0.0.1, port 1310 - accept
ed
Jul 17 11:14:28 mediaportal vdr[708]: SVDRP message: '6'
Jul 17 11:14:31 mediaportal vdr[708]: connect from 127.0.0.1, port 1311 - accept
ed
Jul 17 11:14:31 mediaportal vdr[708]: SVDRP message: '7'
Jul 17 11:14:31 mediaportal vdr[708]: info: 7
Jul 17 11:14:32 mediaportal vdr[708]: connect from 127.0.0.1, port 1312 - accept
ed
Jul 17 11:14:32 mediaportal vdr[708]: SVDRP message: '8'
Jul 17 11:14:34 mediaportal vdr[708]: connect from 127.0.0.1, port 1313 - accept
ed
Jul 17 11:14:34 mediaportal vdr[708]: SVDRP message: '9'
Jul 17 11:14:34 mediaportal vdr[708]: info: 9
Jul 17 11:14:35 mediaportal vdr[708]: connect from 127.0.0.1, port 1314 - accept
ed

Ok that looks good, but an the TV not every message is shown!

Why is this a problem?
I have vdradmin running. That does a svdrp connect every minute or something to read the epg or what ever. Now, when I set a sleeptimer with sleeptimer-plugin, it could happen, that the vdr does not shutdown. The sleeptimer-plugin simply is running a script like the following when the time I configured as sleep-time is over:

sleeptimer.sh:

#!/bin/sh
echo "svdrpsend.pl HITK Power" | at now

Like with the example above this svdrpsend command could have been ignored by vdr and the system does not shutdown. The workaround could be to call a sleeptimer2.sh via atd :

sleeptimer2.sh:

#!/bin/sh
i=10
while test $i -gt 0 ; do
svdrpsend.pl HITK Power
sleep 5
i=$((i-1))
done

But I think, that's a bit dirty.
I know, making svdrpsend queueing all commands ever send, could have other bad effects. E. g. when doing the first example without the "sleep 2" . So what are your opinions about that problem?

Regards

Alles anzeigen

[vdr] Re: SOLUTION: vdradmin disturbs sleeptimer

Zitat

Now, I have a better solution for the sleeptimer.sh:

#!/bin/sh
#
# not so simple poweroff command, sleeptimer plugin

logger sleeptimer.sh: Trying to run svdrpsend.pl HITK Power
svdrpsend.pl HITK Power &

(sleep 3 && tail -n100 /var/log/syslog |\
grep -e "sleeptimer.sh: Trying to run svdrpsend.pl HITK Power\|Power button pressed" |\
tail -n1 | grep "Power button pressed" ||\
/usr/local/src/My_VDR-scripts/sleeptimer.sh ) &

The improovement to the sleeptimer2.sh is as follows.
The sleeptimer2.sh sends 10 times this HITK Power. But if the user cancels the shutdown by hitting a key, the sleeptimer2.sh is going on sending HITK Power at least 10 times.
My new solution checks with this tail-and-grep-pipe from the syslog, if the power command has been send correctly. If not, sleeptimer.sh is called recursively again. If the user cancels shutdown the sleeptimer.sh is already finished, and no further shutdown attempts will accure.
I thought this syslog-check is the only way to check if the HITK Power really is accepted by vdr.
I think this example demonstrates very well, what the user has to think about, when using svdrp. Or is there a more simple way to solve my problem?

Alles anzeigen

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

Anderes Problem. Das alte mp3-oss-plugin funzt bei mir. Jedoch die OSS-Funktionalität im neuen mp3-plugin erzeugt nur sehr zerkratzten Ton. Ich habe im Makefile die option OSS natürlich aktiviert, sonst könnte ich es im Einstellungsmenü gar nicht auswählen.

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

Ok der icy-patch ist in der aktuellen version 0.9.3 des mp3-plugins enthalten. Da besteht das Problem nicht. Somit sei dies als erledigt zu betrachten.

Ciao
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:

[...]
Jul  4 12:58:13 mediaportal vdr[12112]: mp3: playback started with instant playl
ist Groove.mp3
Jul  4 12:58:13 mediaportal vdr[12158]: mp3: player thread started (pid=12158)
Jul  4 12:58:13 mediaportal vdr[12159]: ShoutcastStream:[URL]http://64.236.34.196:80/[/URL]
stream/1018
Jul  4 12:58:13 mediaportal vdr[12158]: ShoutcastStream:[URL]http://64.236.34.196:80/[/URL]
stream/1018
Jul  4 12:58:14 mediaportal vdr[12158]: ERROR: invalid Count in cRingBufferLinea
r::Del: 0
Jul  4 12:58:45 mediaportal last message repeated 60 times
[...]

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

Zitat

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

Mal ne Frage:

Woran kann das liegen, dass der "vdradmin-Fernseher" das Bild nicht komplett anzeigt? Hatte das bei der 0.7 auch schon, drum glaube ich, es liegt nicht direkt an vdradmin. Irgendwann vor ein paar Monaten ging das noch korrekt.

Danke
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:

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

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.

Habe nun den 2-Tonspurrip am laufen.
Meine veränderten Sripte gibts hier:

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

Gruß e-PUNK

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