streamdev: mehr als ein Stream?

Damit kann man mehrere Streams empfangen

http://www.vdr-wiki.de/wiki/in…Verbindungen_oder_Servern

Und wegen der verwendung der lokalen Karte kann ich dir nicht weiterhelfen.

Zitat

Aber wenn man eben eine Aufnahme _auf dem Client_ laufen hat, die über Streaming kommt - dann scheint es nicht möglich zu sein, gleichzeitig auch noch den aufgenommenen Kanal oder die anderen Transponder-Kanäle per Live-TV zu schauen (sicherlich auch nicht aufzunehmen, auf dem Client!)

Muss ich mir mal anschauen. Ich habe da den Workaround für das Streamen verschlüsselter Kanäle im Verdacht. Wenn Du testen willst: in streamdevs client/device.c ist in Zeile 126 ein Block mit "#if 0" deaktiviert. Diesen z.B. mit "#if 1" reaktivieren.

Zitat

Ich habe auch lokal (auf dem Client) ein DVB-device. Aber wenn man damit einen Kanal von einem anderen Transponder schaut, so meint der VDR offenbar er tut einem was gutes, wenn er für eine Aufnahme nicht mehr umschaltet, sondern stattdessen das remote device verwendet. Kann man das Verhalten ändern? Ich würde lieber die Aufnahme mit dem lokalen device machen und ggf. per Streaming Live-TV schauen. Die Aufnahme ist im Zweifel schliesslich das wichtigere..

Ja, VDR schaltet den Live-Kanal nicht weg solange es noch eine Alternative gibt - damit landen Aufnahmen normalerweise bei streamdev. Im streamdev-client Setup kannst Du aber die Prioritäten einschränken, bei denen sich streamdev zuständig fühlt. Wenn Du z.B. einstellst, dass Streamdev nur bis Priorität 1 reagiert, zwingst Du Timer mit einer höheren Priorität auf die lokale Karte.

Hallo liebe Foren Leser,

ich meld mich jetzt auch nochmal! Also ich betreibe einen Acer Revo als reinen streaming client. Keine eigene DVB karte, kommt alles vom server. Klappt soweit prima, ABER: wie berichtet, sobald ich am client eine Aufnahme starte (ich will auf dem client aufnehmen, nicht aufm server, der hat kaum platten) kann ich den selben kanal nicht weiterschauen. Normalerweise erscheint ja auch im "Hauptmenü" des VDR's sowas wie "Aufzeichnung beenden"... kommt aber auch nicht.
Was ich rausgefunden habe ist dass es mit version 0.3.4 noch problemlos funktioniert, mit allen aktuellen nicht mehr.
das mit dem Workaround für das Streamen verschlüsselter Kanäle will ich bei nächster gelegenheit mal ausprobieren.

Kann sonst noch jemand dieses verhalten bestätigen?
(ach ja, ausgabe über xineliboutput, ob das wirklich was damit zu tun hat bezweifle ich, habs auch auf einem anderen rechner mit ner alten FF probiert, selbes verhalten, bis 0.3.4 ok, ab da kein schauen mehr wärend aufnahme.)

Zitat

Was ich rausgefunden habe ist dass es mit version 0.3.4 noch problemlos funktioniert, mit allen aktuellen nicht mehr.

Ja, in 0.3.4 und auch im CVS für 0.4.0 (VDR 1.4.x) ist der fragliche Code-Block nicht auskommentiert. Das ist nur in CVS 0.5.0 der Fall.

also ich bin jetzt smirls hinweis gefolgt und natürlich hatte er mit seiner vermutung recht. es liegt an besagter zeile 126 in clinet/device.c. jetzt kann ich aufnehmen und denselben kanal schauen. auch im osd wird die laufende aufnahme korrekt angezeigt. eigentlich super, nur bleibt die fage was der Workaround für das Streamen verschlüsselter Kanäle eigentlich tut, bzw was ich da jetzt aktiviert habe? oder habe ich was deaktiviert?

Anbei zwei Patch-Vorschläge, die einen Kompromiss darstellen. Wer nur frei empfangbare Kanäle schaut, sollte mit beiden Patches glücklich werden. Interessant wäre, welcher Patch funktioniert, wenn auch verschlüsselte Kanäle empfangen werden sollen. Der Patch ca_equal.diff wäre mein Wunschkandidat. Was mit beiden Patchen nicht mehr klappt: die verschlüsselten Kanäle auf frei empfangbar stellen und die automatischen Kanal-Updates deaktivieren. Zum Empfang verschlüsselter Kanäle muss der Kanal fest auf Streamdev gebunden werden (oder natürlich VDR gepatcht werden).

Zitat

Irgendeine Chance, dass man über eine streamdev-Kanal-Anforderung ebenfalls den Restart des Servers auslöst, wenn der Tuner nix liefert (video data stream broken)?

Du könntest über das remoteosd-Plugin auf das Server-OSD zugreifen und dort den Neustart im Menü "Einstellungen" auslösen. Mit entsprechendem keymakro geht das mit dem Druck einer Taste auf der Fernbedienung.

ich empfange leider auch keine verschlüsselten kanäle, also kann ich auch nicht richtig testen, sorry. will aber versuchen ob der rest mit den patches geht und werde dann berichten

Hi,

ich habe das mal mit den verschlüsselten Kanälen und mit dem Patch "ca_equal.diff " getestet.

Aktuelle Version Streamdev ausgescheckt - Patch drauf -> funzt!!

Einfach super, läuft ohne Fehler.

Danke für den Patch.

Grüße
cinfo

Zitat

ich habe das mal mit den verschlüsselten Kanälen und mit dem Patch "ca_equal.diff " getestet.

Prima - danke! Kannst Du noch kurz beschreiben, welche Varianten Du testen konntest? Relevant sind nur Umschaltvorgänge innerhalb des selben Transponders.

• FTA->verschlüsselt
• verschlüsselt->FTA
• verschlüsselt->verschlüsselt (selbes Verfahren)
• verschlüsselt->verschlüsselt (unterschiedliche Verfahren)

schmirl

Hallo, Nachdem ich lange nicht wusste nach was ich suchen muss bin ich auf diesen und zwei andere Threads gestossen die dieses Thema behandeln.

Streaming Umschaltproblem verschlüsselt/unverschlüsselte Kanäle (akt. e-tobi exp. VDR 1.6) [gelöst]
streamdev cvs verschlüsselte Kanäle

Folgende Situation:
yaVDR auf Server und client mit Streamdev, im Server stecken zwei DVB-C Karten, alle Kanäle verschlüsselt. Das aktuelle streamdev von yaVDR
vdr-plugin-streamdev_0.5.0~pre20090706+cvs20100202.1555-1tyavdr2
hat den ca_equal patch enthalten.

Damit ist es mir (meist) nicht möglich Kanäle auf dem selben Transponder umzuschalten. Die CAID ist "normal" 1801, ich habe die dann auch für alle Kanäle auf "0" gesetzt gehabt.

Nachdem ich den ca_fta patch eingespielt habe hat das Problem immer noch bestanden.

Nun habe ich alle drei Instanzen "&& TRANSPONDER(Channel, m_Channel)" mit dem ca_fta patch versehen, die CAID wieder auf "1801" gesetzt und das umschalten funktioniert jetzt tadellos.
Einzig ein kleiner Fehler taucht im syslog noch auf, der war aber auch schon vorher da.

Feb 16 09:38:09 zotac vdr: [1692] Text2Skin: channelInfo display update thread started (pid=1538, tid=1692)
Feb 16 09:38:09 zotac vdr: [1538] switching to channel 57
Feb 16 09:38:10 zotac vdr: [1690] ERROR (device.c,1881): Bad file descriptor
Feb 16 09:38:10 zotac vdr: [1690] TS buffer on device 10 thread ended (pid=1538, tid=1690)
Feb 16 09:38:10 zotac vdr: [1691] buffer stats: 167032 (7%) used
Feb 16 09:38:10 zotac vdr: [1691] receiver on device 10 thread ended (pid=1538, tid=1691)
Feb 16 09:38:10 zotac vdr: [1694] TS buffer on device 10 thread started (pid=1538, tid=1694)
Feb 16 09:38:10 zotac vdr: [1695] receiver on device 10 thread started (pid=1538, tid=1695)
Feb 16 09:38:11 zotac vdr: [1538] switching to channel 56
Feb 16 09:38:11 zotac vdr: [1694] ERROR (device.c,1881): Bad file descriptor
Feb 16 09:38:11 zotac vdr: [1694] TS buffer on device 10 thread ended (pid=1538, tid=1694)
Feb 16 09:38:11 zotac vdr: [1695] buffer stats: 42864 (2%) used
Feb 16 09:38:11 zotac vdr: [1695] receiver on device 10 thread ended (pid=1538, tid=1695)
Feb 16 09:38:11 zotac vdr: [1696] TS buffer on device 10 thread started (pid=1538, tid=1696)
Feb 16 09:38:11 zotac vdr: [1697] receiver on device 10 thread started (pid=1538, tid=1697)
Feb 16 09:38:12 zotac vdr: [1697] cVideoRepacker: switching to MPEG1/2 mode
Feb 16 09:38:12 zotac vdr: [1697] cVideoRepacker: operating in MPEG1/2 mode
Feb 16 09:38:15 zotac vdr: [1692] Text2Skin: channelInfo display update thread ended (pid=1538, tid=1692)

Da dass für mich alles nur copy & paste / trial & error ist, wäre da noch die Frage ob ich noch den equal_diff patch (an allen drei Instanzen) testen sollte. Wenn das für Dich etwas bringt dann mach ich das natürlich.

Gruss
Sk8ter

P.S.: Die modifizierte device.c liegt im Anhang

Zitat

Nun habe ich alle drei Instanzen "&& TRANSPONDER(Channel, m_Channel)" mit dem ca_fta patch versehen, die CAID wieder auf "1801" gesetzt und das umschalten funktioniert jetzt tadellos.

Danke für das Feedback! Den ca_equal.diff können wir denke ich begraben. Allerdings bin ich noch nicht ganz überzeugt, dass wirklich alle drei Stellen gepatcht werden müssen. Vielleicht langt es auch an zwei Stellen. Ich würde erwarten, dass der Patch in der Methode ProvidesChannel überflüssig ist und in bestimmten Fällen nur das Umschalten unnötig verlängert. Wäre prima, wenn Du das noch ausprobieren könntest.

Klar, mach ich gerne. Da ich was kompilieren angeht eine ziemliche Nuss bin gleich noch eine Frage.

Kann ich eigentlich nur die device.c anpassen und dann wieder

dpkg-buildpackage -rfakeroot -sa

laufen lassen, oder muss ich da erst noch vom letzten Durchlauf etwas aufräumen? Bis jetzt habe ich immer alles gelöscht und habe wieder von vorne angefangen, um sicher zu gehen.

BTW, kannst du noch etwas zu dem Fehler "ERROR (device.c,1881): Bad file descriptor" sagen, oder soll ich den einfach ignorieren?

Gruss
Sk8ter

: gelöscht und unten eingefügt damit der chronologischce Ablauf wieder stimmt.

-tc nach Abschluss Quell-Baum säubern.
also immer so bauen :
dpkg-buildpackage -tc
aufräumen im paket geht natürlich auch nachträglich:
debian/rules clean
-sa brauchst du eigentlich nicht ???

Zitat

BTW, kannst du noch etwas zu dem Fehler "ERROR (device.c,1881): Bad file descriptor" sagen, oder soll ich den einfach ignorieren?

Die Meldung ist "normal" und kannst Du ignorieren. Der Lese-Thread versucht noch von der Netzwerkverbindung zu lesen obwohl der Filedeskriptor schon anderweitig geschlossen wurde. Ist unschön und lässt sich sicherlich irgendwie beheben, allerdings fehlt mir dazu leider im Moment die Zeit.

hotzenplotz5
Das kommt davon wenn man nicht weiss was man tut. Hab mir das mal irgendwo abgeschrieben gehabt.
Das heisst dass dann das -rfakeroot auch überflüssig, weil default , ist und es dann nur noch

dpkg-buildpackage -tc

lautet?

schmirl
Yep es hat funktioniert. Musste noch schnell schauen wie man so einen diff macht. Änderungen siehe Anhang, funktioniert mit CAID 1801 in der channels.conf.

Zitat

Ist unschön und lässt sich sicherlich irgendwie beheben, allerdings fehlt mir dazu leider im Moment die Zeit.

Ist ja auch gar nicht nötig wenn man weiss dass es "normal" ist.

Auf jeden Fall danke vielmal für die Hilfe.

BTW.: Jetzt wo das umschalten so spitzenmässig funktioniert. Gibt es eine Möglichkeit dass beim schnellen zappen, nicht zu jedem Kanal geschaltet wird. Das heisst wenn ich 10 mal hintereinander schnell "Channel up" drücke dass das quasi zusammengezählt wird und nur ein Kanalwechsel stattfinden würde?

Sk8ter

Zitat

Yep es hat funktioniert. Musste noch schnell schauen wie man so einen diff macht. Änderungen siehe Anhang, funktioniert mit CAID 1801 in der channels.conf.

Prima. Ist schon im CVS. Vielen Dank!

Zitat

BTW.: Jetzt wo das umschalten so spitzenmässig funktioniert. Gibt es eine Möglichkeit dass beim schnellen zappen, nicht zu jedem Kanal geschaltet wird. Das heisst wenn ich 10 mal hintereinander schnell "Channel up" drücke dass das quasi zusammengezählt wird und nur ein Kanalwechsel stattfinden würde?

Da kann streamdev leider nichts machen. Das wird so vom VDR gesteuert.