permanentes Timeshift - Livebuffer-Patch (neue Testversion 28.03.07)

Zitat

Original von thomas83
infinite:
Den Reject von recording.c kannst du normal einfach ignorieren.

würd ich ja gerne, aber wenn ein reject auftritt, lässt sich das beim patchen von ctvdr nicht wirklich ignorieren

Zitat

Original von thomas83
Dass mit der automatischen Sprachauswahl werde ich mir in den nächsten Tagen mal ansehen und sollte in der nächsten Version dann richtig funktionieren.

geil, es wird also ne neue version geben ? juhu - livebuffer ist für mich einer der besten patches.. läuft bei mir wirklich astrein, auch mit neturmels plugin
musste zwar die frameswait zahl von auf 8 erhöhen, sonst bekam ich bild / ton aussetzer, aber nun klappt es perfekt !

wird der patch für 1.4.X funken dann ?

gruß,
infinite

Hi Thomas,

schön Dich mal wieder in unserer Mitte zu haben

Zitat

Original von thomas83
Was da bei dir falsch läuft, kann ich im Moment nicht sagen. Du hast wohl mehrere Patches drauf (aus dem Log ist z.B. der LNB-sharing patch ersichtlich). Irgendetwas könnte sich da in die Quere kommen.

Gut erkannt. Ich habe aber das Loggen dort lediglich aktiivert, weil es so einfacher zu sehen ist. Mein erster Gedanke war auch, dass es an dem Lnbsharing-Patch liegt (den ich gar nicht wirklich benutze, aber gerne bereit haben will für dne Falll des Falles - aber auch ohne Lnbsharing-Patch das Gleiche). Vor allem da die Hänger beim Polaritätswechsel passieren. Möglicherweise auch irgend eine Verzögerung bemn der Aussendung des DiSEqC-Signales.
Das "doppelte umschalten" (und die Hänger) sind abe rauch ohne die Decodier-Möglichkeit verschlüsselten Sendern weg.
Es gab aber auch wie weiter oben erwähnt ab vdr-1.3.46 eine Änderung mit den Karten-Prioritäten (nochmal Zitat Klaus: "avoiding the 'actual' device when starting a recording").
Also nicht ganz klar was es wirklich ist...

Meine Frage ist aber eigentlich erst mal grundsätzlich, ob es normal ist, dass mit Livebuffer-Patch mehrere LNBs umgeschaltet werden. Das würde mir schon mal weiter helfen das Problem "einzukreisen". Hab ja selbst einiges rumbasteln müssen, um den Patch bei der auf meiner c't Distri. basierenden Installation zum Laufen zu bringen.

Vielleicht bringst Du ja eine aktualisierte Version - jetzt wo wir wieder "stabil" sind würde es sich ja doppelt lohnen?!

Werner

Zitat

Original von infinite

würd ich ja gerne, aber wenn ein reject auftritt, lässt sich das beim patchen von ctvdr nicht wirklich ignorieren

Ich glaub ich geb's auf...

Zitat

geil, es wird also ne neue version geben ? juhu - livebuffer ist für mich einer der besten patches.. läuft bei mir wirklich astrein, auch mit neturmels plugin

Na endlich?! Hat's mit der original recording.c geklappt - oder wie?

Zitat

wird der patch für 1.4.X funken dann ?

Bei Dir wohl eher nicht...

@ scovery,

sorry aber ich steig bei den sachen mit den rejects wirklich nicht durch.. wie das für dich so einfach ist verstehe ich nicht, und eben mal auflösen ist ja anscheinend auch nid - deine angepasste version behebt ja nicht die rejects mit dem opt-20_liemikuutio-1.3 auch nid.

livebuffer läuft bei mir tadellos - nur eben ohne opt-20_liemikuutio-1.3 und den hätte ich doch ganz gerne wieder dabei.

bzgl der orginal recording.c hab ich noch nid probiert, mach ich am we.

bzgl dass es für 1.4.X bei mir nicht laufen wird - sorry, aber wenn der patch ohne rejects für ctvdr funkt sehe ich kein grund wieso das ausgerechnet bei mir nicht laufen sollte..

nicht jeder ist so ein linux gott wie du, tut mir leid.

infinite

Zitat

Original von infinite
nicht jeder ist so ein linux gott wie du, tut mir leid.

Mir auch.
Ich beschäftige mich gerade erst seit November richtig mit Linux - und eigentlich haben Deine Probleme gar nichts damit zu tun sondern nur damit, das Prinzip von Patches zu verstehen, nämlich einfach die zu ändernden Zeilen zu finden und zu ändern. Mit der Dabian c't Distri ist das ja eh noch einfacher und einem wird eh genau gesagt, wo was hakt. Und nochmals: es ist oft wirklich völlig simpel, hat auch oft nichts mit Programmierkenntnissen zu tun sondern einfach mit Zeilen lesen können (wie kürzlich gehabt eine Änderung die bereits durchgeführt wurde - oder einfach mal zusätzliche Zeilen im Quellcode, so dass es eben nicht mehr 1:1 aussieht und natürlich ein automatisierter Patch die korrekte Stelle nicht selbst findet).
Und ich denke (und habe auch mit VDR gelernt) ein wenig muss man sich schon auch selbst mit der Materie beschäftigt - schließlich wird einem kein fertiges Produkt vorgesetzt (es sei denn man nimmt etwa die c't Distri. "out of the box" - dann musst Du eben warten und hoffen, dass es eine neue Version gibt, in der auch mal wieder der Livebuffer-Patch aktulaisiert und aangepasst ist). Aber selbst dann ist es sinnvoll ein wenig zu verstehen, was wie läuft. Und nochmals: wenn jemand unterschiedlich viele Patches anwendet dann passt eben ein nachfolgender Patch nicht mehr unverändern und dann kann nur jeder selbst das ändern und keiner kann diese Arbeit abnehmen.

ich hab ne debian base mit den ctvdr paketen, also nicht out of the box.. und ja ich schau mir das nochmal genauer an, vlt steige ich dann da ja mal durch.. wie gesagt im moment drückt es nicht, da mein 1.3.45 eigtl sehr zufriedenstellend läuft.

thomas83

ist leider nicht so einfach mit dem ignorieren, weil wenn der den patch nid mag dann bricht er einfach ab, ist dann essig mit compilen.

gruß,
infinite

Zitat

Original von thomas83
Ich kenne zwar ctvdr nicht, aber wieso kannst du den reject nicht einfach ignorieren. Patchen bei ctvdr wird wohl ganz normal ablaufen:
Zuerst patchen, dann kompilieren.

Läuft wenn man ein Debian Paket "schnürt" normalerweise alles mittels eines einzigen Befehls. Und klappt etwas nicht wird abgebrochen. Ist wie ich infinite vergeblich beizubringen versuche eine Kleinigkeit das so abzuänder, dass es "durchläuft"...

Zitat

Wirklich tunen sollten nicht beide Karten. Aber ich glaube, der vdr meldet, wenn von der 2.Karte empfangen wird einen Kanalwechsel von Karte 2 (ist ja klar) und zusätlich von Karte 1 (da diese nun diesen Kanal ausgibt)

Da komme ich jetzt nicht mit. Eine Karte schaltet um - die mit der ich gerade schaue. Also wieso ist "Kanalwechsel bei Karte 2 klar" - wenn "Karte 1 ausgibt"?

Werner

Jetzt macht's eher Sinn.
Budget-Karte schaltet um - FF-Karte gibt aus.
Nur: weshalb bekomme ich die Meldung für beide Karten nur wenn Livebuffer zugeschaltet ist? Weil Mit Livebuffer nicht einfach nur umgeschaltet wird sondern umgeschaltet und dann die Lifebuffer-Aufzeichnung (auf der anderen Karte) wiedergegeben wird?
Lange Rede kurzer Sinn: ist also so normal?

Mein Problem ist nicht genau sagen zu können, wo es hakt. Das Auffällige ist ja auch, dass es die Hänger nur bei Polaritätswechsel gibt. D.h. für mich dass es offenbar ein Problem mit der DiSEqC-Umschaltung gibt. D.h. ebenso, dass bei Dir ggf. mit gleichem Quellcode auch kein Problem auftauchen könnte. Muss mal sehen ob ich mir mal einen normalen mind. Twin-LNB zum ausprobieren besorge (jetzt hängt der VDR am Multiswitch) - Schüssel würde leicht erreichbar sein und ein Tausch nicht problematisch.

Zitat

Original von thomas83
Du könntest mal bei ausgeschaltetem LiveBuffer folgendes testen:
Bei zwei Kanälen mit unterschiedlicher Polarisation (die beim Umschalten mit Livebuffer Probleme machen) mal im CA-Feld eine 2 reinschreiben (damit sie nur von der 2.Karte empfangen werden können). Dann zwischen diesen beiden Kanälen umschalten und schauen, ob es hier auch ohne Livebuffer Probleme gibt.

Genialer Tipp, Thomas!
Dadurch habe ich auch ohne aktivierten Livebuffer gelegentlich die selben Aussetzer. Womit wohl zweifelsfrei bewiesen ist, dass es nicht am Livebuffer liegt sondern offenbar tatsächlich ein Problem mit DiSEqC vorliegt, das mir nur vorher nicht aufgefallen ist.
Hab zwar schon etwas an der diseqc.conf rumgebastelt, war aber wohl noch nicht auf dem richtigen Weg. Eigentlich hatte ich auch erwartet, dass nach der Timeout-Meldung im Log irgend was stehen müsste, was passiert ist, da es nach dem Timeout ja ein Signal/Bild gibt. Aber dort steht überhaupt nichts diesbezügliches (retune o.ä.).

für die neue version des patches hätte ich vlt noch folgende idee:

bei mir ists so, wenn ich mit der pre10 vom burn plugin 0.1.0 was brenne, dann hab ich beim live bild bild/ton aussetzer, bin aber der einzige bei dem das auftritt, da andere keinen livebuffer patch nutzen. ich werd das diese woche nochmal genauer testen obs am livebuffer liegt.. wenn ja wäre ne routine ala

if burn is running
stop livebuffer
else
start livebuffer

sodass lifebuffer eben temp. ausgeschaltet wird.. idealerweise einstellbar via OSD..

gruß,
infinite

Zitat

Original von infinite
bei mir ists so, wenn ich mit der pre10 vom burn plugin 0.1.0 was brenne, dann hab ich beim live bild bild/ton aussetzer, bin aber der einzige bei dem das auftritt, da andere keinen livebuffer patch nutzen. ich werd das diese woche nochmal genauer testen obs am livebuffer liegt.. wenn ja wäre ne routine ala

Unwahrscheinlich, überprüfe mal deine DMA-Modi!

Der Livebuffer macht ja nichts anderes als eine Aufnahme auch...

Zitat

Original von Franzose
[Der Livebuffer macht ja nichts anderes als eine Aufnahme auch...

Eben - trotzdem läuft Livebuffer bei mir auch alles andere als flüssig - und das, obwohl in eine Ramdisk geschrieben wird. Ich kann zwei Aufnahmen gleichzeitig auf Festplatte machen - das läuft flüssiger als der Livebuffer
Ist aber wahrscheinlich auch ein Unterschied wenn man wie ich erheblich weniger CPU-Leistung hat.
Aber ich habe eh noch ein weiteres Problem festgestellt. Mit Livebuffer kann ich praktisch den Streamdev-Server vergessen, da vorher immer erst am VDR selbst das gleiche Programm eingestellt werden muss.
Das und das anscheinend unlösbare DiSEqC-Problem mit meiner WinTV Nova-S machen es mir eh unmöglich, den Livebuffer zu aktivieren. Für die Nova-S Plus gab's wenigstens mal einen Patch wegen DiSEqC.

Zitat

Original von thomas83
Ich habe auch 2 DVB-Karten und kann ganz normal streamen, egal ob LiveBuffer aktiv ist oder nicht.

Wenn der Stream läuft kann ich auch am VDR ein anderes Programm wählen.

Zitat

Original von scovery
Wie schaut den deine diseqc.conf aus? Hilft es denn nichts, wenn du die diseqc-Befehle ein paar mal wiederholst?

Ich hab's jetzt nur mit einer Pause und danach einmaligen Wiederholen versucht. Ich weiß einfach nicht, was eigentlich mit der Budget-Karte los ist. Geloggt wird nichts. Ich weiß nicht, weshalb es nach knapp 10 Sekunden dann doch geht. Müsste da wohl ehe rmal bei der linuxtv.org ML nachfragen. Oder ich probier's doch einfach mal interessehalber mit ner anderen Budget-Karte - ist ja nicht ganz so kostspielig.

tag !

Ich habe jetzt endlich auch mal den Live-Puffer getestet und muss sagen , wirklich coole sache!!!!

Hat mich wirklich umgehaun wie gut das funktioniert habe nur 2 Fragen die mich etwas nachdenklich stimmen.

1) Die umschaltzeiten stören mich nicht, aber das das Bild sich erst wieder einruckeln muss schon, ist das normal und gibt es abhilfe oder kann man daran nix machen?

2) Er zuckt in 10min schritten so das das Bild kurze zeit stehn bleibt und dann wieder normal weiter läuft. Muss ich den Puffer grösser stellen oder sonst was machen? Oder ist auch das völlig normal?

Hi Thomas !

Also dein Tip war was das einruckeln angeht wirklich GOLDWERT !

Leider bleibt das Bild aber immer noch recht gleichmässig stehn und zwar kann ich das beeinflussen wenn ich den puffer grösser stelle.

Also bin ich mir auch auf jeden fall sicher das es irgendwas mit dem schreiben der datei zu tun hat. Habe jetzt mal auf 1500MB gestellt , da wird er denke ich nun fast ne Stunde durchhalten dürfen.

Ich berichte dann !