johns: Wegen der Alsa Version als Fehlerquelle:
cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version 1.0.24.
Im Test ist gerade deine aktuelle Git softhddevice Version, der Log schaut bis jetzt prima aus. Optisch und akustisch auch.
Makefile unverändert also ohne Audiodriftkorrektur.
johns: Danke für die neue Version ( de79e9211f5efcab225f750d9bdd85da3c9d83ac)
Damit laufen alte PES-Aufnahmen von einer bestimmten Sendergruppe bei mir deutlich besser als bisher. Dort gab es vorher bei alle paar Sekunden deutliche, merkwürdige Ruckler.
Was jetzt bei mir nicht mehr richtig funktioniert ist schnelles Vor- und Zurückspulen in PES-Aufnahmen. Dort bleibt dass Bild dann zunächst 1 bis 2 Sekunden stehen und bewegt sich dann ruckartig in Zeitlupe. Ist aber nicht tragisch, springen mit den Farbtasten funktioniert einwandfrei.
Mar 02 21:30:38 [vdr] video: 14:48:18.024 +182 1345 0/\ms 191 v-buf_
Mar 02 21:30:38 [vdr] video: 14:48:18.044 +168 1312 0/\ms 191 v-buf_
Mar 02 21:30:38 [vdr] video: 14:48:18.064 +155 1279 0/\ms 191 v-buf_
Mar 02 21:30:38 [vdr] [8335] [softhddev]Clear:_
Mar 02 21:30:38 [vdr] [8335] [softhddev]Mute:_
Mar 02 21:30:38 [vdr] [8335] [softhddev]TrickSpeed: 6_
Mar 02 21:30:38 [vdr] video: display buffer empty, duping frame (1490/230809) 191_
Mar 02 21:30:38 [vdr] video: missed frame (53/230809)_
Mar 02 21:30:38 [vdr] video: missed frame (54/230809)_
Mar 02 21:30:38 [vdr] video: missed frame (55/230809)_
Mar 02 21:30:38 [vdr] video: missed frame (56/230809)_
Mar 02 21:30:39 [vdr] video: missed frame (57/230809)_
Mar 02 21:30:39 [vdr] video: missed frame (58/230809)_
Mar 02 21:30:39 [vdr] video: missed frame (59/230809)_
Mar 02 21:30:39 [vdr] video: missed frame (60/230809)_
Mar 02 21:30:39 [vdr] video: missed frame (61/230809)_
Mar 02 21:30:39 [vdr] video: missed frame (62/230809)_
Mar 02 21:30:39 [vdr] video: missed frame (63/230809)_
Mar 02 21:30:39 [vdr] video: missed frame (64/230809)_
Mar 02 21:30:39 [vdr] video: missed frame (65/230809)_
Mar 02 21:30:39 [vdr] video: missed frame (66/230809)_
Mar 02 21:30:39 [vdr] video: missed frame (67/230809)_
Mar 02 21:30:40 [vdr] video: missed frame (68/230809)_
Mar 02 21:30:40 [vdr] video: missed frame (69/230809)_
Mar 02 21:30:40 [vdr] video: missed frame (70/230809)_
Mar 02 21:30:40 [vdr] video: missed frame (71/230809)_
Mar 02 21:30:40 [vdr] video: missed frame (72/230809)_
Mar 02 21:30:40 [vdr] video: missed frame (73/230809)_
Mar 02 21:30:40 [vdr] video: missed frame (74/230809)_
Mar 02 21:30:40 [vdr] video: missed frame (75/230809)_
Mar 02 21:30:40 [vdr] [8335] [softhddev]Clear:_
Mar 02 21:30:40 [vdr] [8335] [softhddev]Play:_
Mar 02 21:30:40 [vdr] video: missed frame (76/230809)_
Mar 02 21:30:40 [vdr] video: 14:48:18.264+1245 1593 0/\ms 191 v-buf_
Mar 02 21:30:40 [vdr] video: 14:48:18.264+1230 1578 0/\ms 191 v-buf_Grüße, Peter
ZitatMenu / Back / Stop
... bewirken hier gar nichts - statt dem (ursprünglichen) "kanalwechsel" mit der RC sollten diese keys aus dem (initialen) "suspend" (plug-parameter "-s") schalten?
svdrp "RESU" hab ich nicht getestet.
ciax
Hmm... die Version 4d1a516c808202141af4268199ae09e9c4bec3fc lief bei mir deutlich besser, als die letzte von gestern Abend (de79e9211f5efcab225f750d9bdd85da3c9d83ac). Bei der fliegt mir beim Zappen desöfteren der Ton weg und es kommt nur noch ein Rauschen. Teilweise hilfts auf einen Stereokanal zu schalten, ansonsten hilft nur ein Neustart vom VDR.
Das Umschaltverhalten an sich ist jetzt viel besser, gerade durch das spätere Einsetzen des Tons. Was mir nicht gefällt sind die Lautstärkeunterschiede z.B. auf Sky zwischen Originalton und der deutschen Vertonung. Gerade wenn über HDMI lediglich Stereo benutzt wird ist man ständig am regeln. Läßt sich da über ALSA eventuell der Center noch etwas anheben?
Gruß
iNOB
Bei der fliegt mir beim Zappen desöfteren der Ton weg und es kommt nur noch ein Rauschen.
Hatte ich auch 2 mal gehabt.
Ansonsten läuft die Version bei mir besser als die Vorgänger. (nur die Grundfunktionen gestestet)
sehr gut dachte schon gestern was ist da kaputt 
Mit der gestrigen GIT Version kommt es bei mir öfters vor das beim schalten von einem ac3 sender auf einen stereo sender der ton auf ac3 stehen bleibt und erst nach ca. 6sekunden umschaltet. Nachdem ich den Buffer auf 116 gesenkt habe ich keine Probleme mehr. Läuft wirklich gut.
Getestet mit und ohne Drift Korrektur.
Ich sehe schon wo das Problem ist. Vorher habe ich den Audiopuffer nicht gescheit zurückgesetzt und nun erkennt er LPCM, was es aber nicht ist.
diff --git a/softhddev.c b/softhddev.c
index d875417..e9f6057 100644
--- a/softhddev.c
+++ b/softhddev.c
@@ -501,7 +501,8 @@ void PesParse(PesDemux * pesdx, const uint8_t * data, int size, int is_start)
pesdx->State = PES_LPCM_HEADER;
pesdx->HeaderIndex = 0;
pesdx->HeaderSize = 7;
- break;
+ // FIXME: need harder LPCM check
+ //break;
}
}Sollte es beheben, bis ich besseren Check habe.
... bewirken hier gar nichts - statt dem (ursprünglichen) "kanalwechsel" mit der RC sollten diese keys aus dem (initialen) "suspend" (plug-parameter "-s") schalten?
svdrp "RESU" hab ich nicht getestet.
Stimmt aus dem start suspend, weckt nur ein SVDR resume.
Johns
Ich weiß es gibt noch ganz andere Baustellen, aber ich wollte mal fragen ob es evtl. irgendwann mal möglich wäre ein Softosd für Dein Plugin zu entwickeln (einzubauen)? Ich meine sowas wie hier für xineliboutput?
[ANNOUNCE] xineliboutput-SOFTOSD-Patch (nicht NUR für Softies)
Grüße
So nun ist es passiert ffmpeg hat einen Bug und libav funktioniert besser.
Soll das bedeuten es soll ffmpeg deinstalliert werden, und stattdessen libav installiert werden ? 
Beides gleichzeitig wird wohl nicht gehen, ist ja quasi fast das gleiche.
wenn ja ab welcher Version, ist 0.8.1 hinreichend?
kann man nicht besser den Bug bei ffmpeg melden?
Christian
Also wer eine Distribution mit ffmpeg hat soll ffmpeg >= 0.7 benutzen.
Ich habe via packman repo, die Version 0.10-1.4 ist ja fast die aktuellste wenn ich mich nicht irre.
Deine Aktuelle Version mit Audiodrift aktiv läuft im Log sauber, bis jetzt keine underrun errors oder so.
Aber selbst diese Version läuft, nur wird erst bei einen Drift von >10ms die Drift korrigiert.
Wenn korrigiert wird, zeigst du dies extra im syslog an ?
Nachtrag: Der Audiofehler scheint nun behoben zu sein, ich hatte noch nie so schöne Logs vor allem auf Sky HD mit DD.
Aber ich hatte einen kurzen Ruckler im Livebild, danach ging alles in einen kurzen Schnellvorlauf.
Dies war auch sehr selten beim xineliboutput Plugin zu sehen.
Ich hänge den Log mal dran, denke dein Videoparser wird dies fixen.
Und nochmals der selbe Fehler, im 2. Anhang
Warum kümmert sich softhddevice um UserInactivity?
Wenn z.B. das mp3-Plugin mit einer langen Playliste läuft, wird mit Plugin->Active() dem vdr signalisiert, dass auch nach Ablauf der Inactivity-Zeit nicht runtergefahren werden soll. Jetzt aber geht softhddevice zu dem Zeitpunkt in Suspend und schaltet den Ton ab. Nur durch ein externes RESU bekommt man überhaupt jemals wieder Ton und Bild.
Meiner Meinung nach sollte softhddevice es dem vdr überlassen, zu entscheiden, wie auf Inaktivität reagiert wird.
Wenn z.B. das mp3-Plugin mit einer langen Playliste läuft, wird mit Plugin->Active() dem vdr signalisiert, dass auch nach Ablauf der Inactivity-Zeit nicht runtergefahren werden soll
Eigentlich wäre ja ein ShutdownHandler.SetUserInactiveTimeout() korrekter um die UserInactivity Prüfung zu umgehen. Plugin->Active() lässt das Log unnötig vollschreiben und produziert unnötig viele Aktionen (z.B. wird alle 5 Minuten die setup.conf weggeschrieben). Ist also eher ein Problem vom mp3 Plugin.
Nur so für die Akten angemerkt. Nicht das das hier auch ausartet wie im anderen Thread 
cu
Na dann nenne mal ein paar mehr Beispiele.
Ich wuesste jetzt nicht was daran so schlimm ist , wenn alle 5 Min. die setup.conf geschrieben wird ;).
Abgesehen davon habe ich auch noch nirgends den Code gesehen , wo das MP3-Plugin VDR veranlasst
die setup.conf neu schreiben zu lassen.
Wenn korrigiert wird, zeigst du dies extra im syslog an ?
Nachtrag: Der Audiofehler scheint nun behoben zu sein, ich hatte noch nie so schöne Logs vor allem auf Sky HD mit DD.
Aber ich hatte einen kurzen Ruckler im Livebild, danach ging alles in einen kurzen Schnellvorlauf.
Dies war auch sehr selten beim xineliboutput Plugin zu sehen.
Ich hänge den Log mal dran, denke dein Videoparser wird dies fixen.
Und nochmals der selbe Fehler, im 2. Anhang
Es wird nur was ausgegeben mit -DDEBUG. Im Normalbetrieb ist Ruhe.
Ich sehe im Log keinen Fehler, der den "decoder render too slow" produziert.
Deshalb glaube ich nicht das der neue Video Parser eine Verbesserung bringen könnte.
Sieht doch nach einen VDPAU Problem aus.
Johns
Ich wuesste jetzt nicht was daran so schlimm ist , wenn alle 5 Min. die setup.conf geschrieben wird ;).
Abgesehen davon habe ich auch noch nirgends den Code gesehen , wo das MP3-Plugin VDR veranlasst
die setup.conf neu schreiben zu lassen.
Ups, du hast Recht, die Plugins werden vor dem setup.conf speichern abgefragt, das setup.conf speichern kommt erst vor der Abfrage der Shutdown hooks.
Aber... egal, ich gebe jetzt auf, macht doch was er wollt dann patche ich halt selber lokal
cu
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
