Zapping-Event?

[Pedant]

Hallo,

z3r0 hat das wunderbare JackTV geschrieben. Damit ist es möglich einige der ebenso wunderbaren Features von VLC zu nutzen.
http://wiki.tuxbox-cvs.sourceforge.net/JackTV
Eines dieser Features ist es einen Stream von der DBox zu holen und im Netzwerk an weitere Clients zur Wiedergabe zu verteilen.

Jetzt besteht mein Wunsch darin, dass auf einem Server JackTV läuft und die Verteilung übernimmt, aber von jedem Client per DBox-Webinterface oder direkt an der DBox per Fernbedienung umgeschaltet werden kann und JackTV die Umschaltung mitbekommt und VLC für den neu gewählten Sender erneut startet.

Das Problem ist aber, dass die Umschaltung zumindest innerhalb eines Transpondern unbemerkt bleibt. VLC empfängt immer noch den "alten" Sender.
Es müsste beim Umschalten des Senders eine von außen erkennbare Veränderung geben. Vorstellbar wäre, dass die DBox das Zappingevent über einen Port dem Netzwerk mitteilt.
Vielleicht gibt es ja schon etwas Auswertbares, ohne dass man die DBox dauernd von außen abfragt und mit diesen Abfragen stresst.

Wer eine Idee hat, wie vorhande DBox-Features genutzt werden könnten, dessen Antwort würde ich sehr schätzen, ansonsten fällt mir nur die Bitte um ein neues Feature ein, das Zappingevent auf Port xy.

Gruß Frank

[z3r0]

Ich würde die Umsetzung des Requests auch begrüßen. Ich sehe momentan keine andere "saubere" Möglichkeit einen Zap-Event am Streaming-Rechner zu registrieren. Alle 2 Sekunden die channelId zu holen, um zu sehen ob gezappt wurde, ist nicht das wonach ich strebe

[jmittelst]

Hört sich, wie immer, wenn Pedant was will, sehr interessant an. Könnte riesige Vorteile für Watch-Programme bringen und die sind seid Tuxvision ja ehr stiefmütterlich behandelt (o.k. WingrabTV sah ganz hoffnungsvoll aus, aber scheint mittlererweile auch tod).
cu
Jens

[MysticEmpires]

Nur um das etwas zu puschen

Ich hätte auch Interesse ander Sache da ich grade eine einem Kleinen Progrämchen Arbeite *g*

[jmittelst]

@MysticEmpires: Wenn Du was hast, poste es. Neue Progrämmchen sind immer gut
cu
Jens
PS: soll heißen, wenn Du BetaTester oder so brauchst, ...

[MysticEmpires]

Jo klar ich werde das erstmal so Progammieren. Also ohne dieses Event. Aber wenn das mal kommt währe das ein super Ding. Mal gucken wann ich mal die erste Beta presentieren kann.

[Pedant]

Hallo,

Geduld ist eine Tugend, ich weiss. Deswegen frage ich jetzt nach 225 Tagen mal nach, ob dieser Wunsch nur übersehen oder als unrealisierbar oder viertrangig eingestuft wurde.
Über eine Antwort würde ich mich freuen, sogar über ein knappes "Nein".

Gruß Frank

[Pedant]

Hallo,

es sind wieder 272 Tage vergangen, deswegen frage ich nochmal nach.
Welchen Status hat dieser Feature-Request?
Für mich ist das immernoch das Wunsch-Feature Nummer 1. Ich weiss, dass es nur ein Wunsch unter hundert Anderen ist und dass es sich hier um ein Freizeitprojekt handelt, trotzdem würde ich mich wirklich freuen, wenn mal jemand vom Dev-Team darauf Antworten würde. Bleibt diese Innovationsvoraussetzung für Lan-TV ein Traum oder hat das eine Chance auf Umsetzung?

Gruß Frank
(Keine Antwort ist keine Antwort.)

[arno-neutrinoTV]

Da es kein event-mechanismus für das "umschalten" gibt wird dieses feature so erst mal nicht kommen.

Was in neutrinoTV allerdings kommen wird, ist eine Art LAN-TV mit theoretisch (praktisch abhängig von dem verwedeten Netztwerk) beliebig vielen neutrinoTV Instanzen, welche alle die Möglichkeiten von dem ersten neutrinoTV haben werden - sofern die erste Instanz das erlaubt (per option ein/aus schaltbar). Mehr dazu, wenns fertig ist.

Zeitplan ungewiss, nach meiner roadmap wird das zum ersten mal in der 1.3 verfügbar sein (das kann sich aber noch ändern).


Nachtrag (EDIT): Wenn es andererseits so ein "zapping-event" geben sollte, dann würde ich das natürlich gerne mitverwenden (alle livebilder würden dann umschalten) D.h. ich würde so ein event auch begrüßen - aber es sollte in diesem Fall wirklich ein event sein und kein polling.

Grüßle
A.

[Pedant]

Hallo,

Da es kein event-mechanismus für das "umschalten" gibt wird dieses feature so erst mal nicht kommen.

Mein Feature (Wunsch) ist doch genau dieser event-mechanismus für das "umschalten". Da hast Du irgendwie Wirkung und Ursache vertauscht.

Das nur, damit keine denkt, mein Request hätte sich dadurch erledigt.

Auf die Umsetzung Deiner Idee für neutrinoTV freue ich mich allerdings schon. Das klingt sehr interessant. Meiner Meinung nach würde auch neutrinoTV von einer Unterstützung durch die Dbox (Zapping-Event) profitieren können.

Gruß Frank

[arno-neutrinoTV]

@Frank:

Ja, du hast recht ich hab vorhin etwas schnnell geantwortet, hab danach noch ein edit eingefügt. Also hier nochmal deutlich, ich würde ein zapping-event auch begrüßen, allerdings weiss ich nicht so richtig wie man das sauber bewerkstelligen würde. Spezieller TCP Port wäre ok, ist halt so ein bischen das overkill, in die web-api kann man es nicht reinpacken, weil es sonst zu polling führen wird....

hmm ... *überleg*

evtl registriert man bei der box eine url welche von der box bei Bedarf aufgerufen wird. Also konkret es gibt einen nhttp-api call

Code: Alles auswählen

/control/callbackonzap?url=http://192.168.x.x/<cid>&timeout=60

Die Box würde dann "wget <url>" bei dem Event aufrufen. Der Timeout ist für den softstate, da man ja nie wissen kann, ob der client nicht einfach gestorben ist. D.h. ist die in timeout (in s) verstrichene zeit abgelaufen wird Aufruf nicht mehr durchgeführt. D.h. jeder client müsste sich regelmässig (<timeout) neu registrieren.

Bei dem Aufruf müsste es sich dabei nicht um einen http-Aufruf handeln, es könnte z.B. auch einfach nur ein wohldefiniertes UDP Packet sein..

Was meinen andere dazu?

Grüßle
A.

[Pedant]

Hallo,

mein Feature-Request wird heute 3.
Das nehme ich mal als Anlass mittzuteilen, dass er für mich immernoch aktuell ist.

Ich weiß, dass es hier im Bereich "Feature-Requests" 1511 Themen gibt, trotzdem gebe ich die Hoffnung nicht auf, dass sich jemand dieser Sache annimmt.
Arno hat hier ja schon eine Überlegung angestellt, wie man es umsetzen könnte, vielleicht hat ja jemand noch eine andere Idee oder es gibt mittlerweile eine Weiterentwicklung der Dbox-Software an der man leicht anknüpfen könnte. Ich habe leider keine Ahnung von Linux, um selbst aktiv zu werden, so bleibt mir nur der Weg hier beharrlich meine Bitte zu äussern.

Ich versuch mal einen anderen Ansatz zu bieten:

Es wird doch die Zapping-History geplegt. Es muss also irgend einen Prozess geben, der beim Zappen diese Datei modifiziert.
Jetzt könnte man vermutlich leicht den Ort der Datei verlegen. Ich denke da an einen neuen und ansonsten leeren Ordner z.B. /var/tuxbox/config/zapit/history/
Die reguläre Funktion der Dbox wäre damit erstmal unverändert.

Wer das Zapping-Event nach aussen mitteilen möchte, der kann einfach ein PC-Verzeichnis unter /var/tuxbox/config/zapit/history/ mit Schreibrecht mounten, sodass die Datei nichtmehr auf der Dbox, sondern auf dem Server gepflegt wird.

Für PC-Software, die das Zapping-Event auswerten möchte, wäre es ein Leichtes die Datei permanent zu prüfen, ohne dass die PC-CPU davon in die Knie geht oder die Dbox belästigt wird.

Die einzige erwähnenswerte Änderung an der Dbox-Software wäre, dass der Prozess, der die Zapping-History pflegt fehlertolerant gestaltet werden müsste, da das Zielverzeichnis nicht immer erreichbar ist und das Umschalten nicht auf ein langes Timeout beim Schreibversuch auf ein nichterreichbares Mount warten soll.

Falls die Zapping-History nicht geeignet sein sollte, so könnte ein beliebiger Prozess, der beim Umschalten aktiv wird um eine Zeile wie
echo $channelID > /mnt/filme/zapping.txt
ergänzt werden und so gestrickt sein, dass er nicht auf den Erfolg der Schreibaktion wartet und sich über Misserfolg auch nicht ärgert.
Es wird das EPG ausgelesen, der Display-Inhalt geändert und sicher noch einige andere Dinge beim Zappen gemacht, irgendwo muss es einen "leichten" Ansatz für eine weitere kleine Aktion geben.

Das ganze ist nicht für einen Herzschrittmacher gedacht, insofern wäre eine Lösung, bei der gelegentlich mal eine Umschalten unentdeckt bleibt auch kein Drama.

Weiterhin voller Zuversicht, verbleibe ich mit liebem Gruß
Frank

[Tommy]

Die History wird nicht in eine Datei geschrieben - die hängt im Speicher

[Pedant]

Hallo Tommy,

danke für den Hinweis, dann muss ich mich nicht wundern, dass ich keine entsprechende Datei gefunden habe.

Dann halt eine Lösung über den zweiten Ansatz und irgendeine Datei erzeugen lassen.
Einen Weg muss es geben.

Gruß Frank

[dbt]

Also wenn es reichen würde das Event nach aussen zu bringen, könnte man das sicher so machen wie das ja z.B. bei der Formatumschaltung gemacht wurde.
Hier mal quick'n'dirty im Infoviewer eingebaut. Da greife ich das ZAP_COMPLETE ab und starte, falls vorhanden, ein Script ZAPCOMPLETE_FILE. Was man damit macht, ist dann ein anderes Ding, also auch für sonst was verwendbar. Die Histories kann man sicher auch über ein Script abrufen...

Code: Alles auswählen

 		eventname	= info_CurrentNext.current_name;
 		return messages_return::handled;
 	}
+	else if (msg == NeutrinoMessages::EVT_ZAP_COMPLETE)
+	{
+		showSignalBars(true);
+		if (access( ZAPCOMPLETE_FILE, 0 ) != -1)
+			CNeutrinoApp::getInstance()->execute_start_file(ZAPCOMPLETE_FILE);
+		return messages_return::handled;		
+	}
 	else if (msg == NeutrinoMessages::EVT_ZAP_FAILED)
 	{
 		if ((*(t_channel_id *)data) == channel_id)

[arno-neutrinoTV]

Hi folks,

ZAP_COMPLETE könnte schon zu spät sein. Das Problem ist, dass man eigentlich den stream beenden müsste BEVOR das zapping eingeleitet wird. D.h man bräuchte eine Art ZAP_STARTED (vielleicht gibts das auch schon). Und dann ist immer noch die Frage ob das reicht, weil das Beenden des streams auch etwas zeit kostet. Wenn also die dbox schneller ist und den zap durchführt bevor der stream abgeschaltet wurde ist's leider wieder kaputt

Eigentlich müsste man das ZAP-Event "aufhalten" können. Das heisst es wird erstmal nach aussen ein ZAP_REQUESt gegeben. Erst wenn dieser positiv bestätigt wird (wie auch immer das gehen soll) darf das zapping weitermachen.

Nichtsdestotrotz, wenn es ein ZAP_COMPLETE gäbe würde ich versuchen es in neutrinoTV zu verwenden. D.h. bei Empfang des events würde ich sofort den stream stoppen, ne Weile warten und dann versuchen den Stream neu anzufordern. Evtl würde es gehen. - wobei ich eher nicht daran glaube, weil vmtl das zappen (während gestreamt wird) einfach schon fehlschlagen wird - oder?


Viele Grüße
Arno

[seife]

Ich verstehe nicht, warum man für sowas die dbox nicht einfach das aktuelle Programm per UDP-Multicast (oder Broadcast, ist in normalen Heimnetzen dasselbe) rausblasen läßt. Mit dvbstream aus den dvbtools habe ich z.B. sowas schon gemacht (allerdings nicht auf der dbox).
Das sollte auch auf der dbox gehen, da IIRC nichts anderes gemacht wird als den stream in RTP-Pakete zu packen und dann mehr oder weniger direkt auf den UDP-Socket zu blasen.
HTTP-Streaming und ähnliches ist für Echtzeit einfach untauglich, vermutlich ein Grund warum sich keiner dieses Feature Requests angenommen hat (mich eingeschlossen), auch wenn es trivial zu implementieren wäre.

[Pedant]

@arno,
das Problem, wenn die Dbox erst umschaltet und dann die Umschaltung bekannt gibt, verstehe ich nicht. Wobei Du natürlich tiefer in der Materie steckst als ich.

Ich habe einfach mal die Situation mit VLC getestet. (per Kommandozeile)
1. Am Server einen Stream von der Dbox geholt und per http am Client abgerufen.
2. An der Dbox umgeschaltet. Das Bild am Client bleibt stehen.
3. Am Server VLC geschlossen. Das Bild am Client verschwindet.
4. Am Server VLC mit den neuen PIDs gestartet.
5. Am Client [Play] gedrückt. Der aktuelle Sender wird wiedergegeben.

Falls die Dbox das Umschalten mitteilen würde, so könnte man die Schritte 3. und 4. automatisieren. Bei http im Gegensatz zu udp bleibt einem das Playdrücken am Client so der so nicht erspart oder sehe ich das falsch?

Falls es wirklich notwendig ist das Umschalten erst mitzuteilen, dann auf ein externes Okay zu warten und dann die Umschaltung zu machen, so sehe ich da im Dbox-Betrieb Nachteile und Schwierigkeiten:
- Die Implementierung in der Dbox wäre deutlich aufwendiger.
- Was passiert, wenn man einfach die Kanäle durchzappen will, auf der Suche nach einer interessanten Sendung. Man müsste jedesmal warten bis neutrinoTV sich auf den neuen Sender eingestellt hat, was durchaus einen Moment dauern kann und könnte dann erster weiterzappen?
- Was passiert, wenn neutrinoTV nicht gestartet ist, die Dbox würde beim Zappen immer erst auf ein Timeout warten müssen?

Mein Vorschlag wäre das Zapping Event fehlertolerant und ohne Timeout nach aussen zu bringen, um den regulären Fernsehbetrieb nicht zu beinträchtigen und alle weiteren Dinge extern zu erschlagen.
neutrino TV sollte nacheilend auf ein Zapping reagieren und zwar zunächst den Abruf stoppen und dann warten ob nicht sofort ein weiteres Zapping durch den User erfolgt und erst dann den neuen Abruf starten. Ich vermute einfach, dass wenn beim Senderdurchblättern sofort jeder Stream abgerufen wird die Dbox unnötig gestresst wird.
Aber das ist nur eine Vermutung, die man durchaus mal überprüfen könnte.

Eigentlich ginge das Alles ja irgendwie auch jetzt schon, indem man an der Dbox umschaltet, und der Server deswegen mit den verwendeten PIDs keinen Stream mehr erhält. Das könnte der Server bemerken, die aktuellen PIDs abfragen und das Streamabrufen erneut starten.
Das scheitert aber daran, dass beim Zappen innerhalb eines Transponders, der Stream mit den vorhergehenden PIDs immernoch funktioniert, der Server also von der Umschaltung nichts mitbekommt.
Daher überhaupt die Idee des Zapping Events.

Damit ich nicht falsch verstanden werde:
Ich möchte Dir natürlich nicht vorschreiben, wie Du Dein Programm zu gestalten hast und ich möchte hier auch kein Plädoyer gegen eine tiefgreifende und umfassende Implementierung neuer Features halten, ich denke nur, dass es wichtig ist eine Lösung zu finden, die den regulären Fernsehbetrieb nicht nachteilig beeinflusst und es andernfalls notwendig wäre die Dbox für Fernseh- oder neutrinoTV-Betrieb zu konfigurieren.

@dbt,
es wäre definitiv ein guter Anfang und vielleicht auch völlig ausreichend das Event nach aussen zu bringen und eigentlich auch egal wie.
Könnte Dein Script-Entwurf schon beim jetzigen Stand der Dbox-Software verwendet werden oder müsste da noch was Anderes vorbereitend verändert werden?

@seife,
einfach das aktuelle Programm per UDP-Multicast oder Broadcast ins Netzwerk schicken wäre auch ein Weg, aber auch das müsste natürlich jemand der Dbox beibringen.

Danke für Eure Beteiligung an der Diskussion.
Gruß Frank

[arno-neutrinoTV]

Hi allerseits,

@Pedant: Cool. Da hatte ich noch nen falschen Eindruck. Ich dachte mich erinnern zu können, dass wenn man umschaltet während man streamt (egal ob http, also streamts oder udpstreamts) dann würde die dbox vollständig durcheinander kommen. Wobei, klar, das Bild beim VLC client muss stehen bleiben - ich dachte mich erinnern zu können, dass allerdings dann auf dem TV das berühmt "Kanal nicht verfügbar" kommt. Kann auch sein, dass das mittlerweile so nicht mehr ist.

Unter diesen Bedingungen reicht natürlich ein ZAP_COMPLETE event völlig aus.

@seife: ja. http streaming eingnet sich natürlich dazu nicht. Allerdings bezog sich die ursprüngliche anfrage auf beliebiges streamen, also z.B. auch auf udpstreamts. Aktuell ist es eben so, dass wenn man udpstreamts startet, dann den Sender per FP wechselt, der udpstreamts zwar aktiv bleibt, aber der stream abreisst - logisch, da die dbox jetzt andere pids hat. Mit einem Event, welches nach aussen gegeben wird, kann man nun theoretisch udpstreamts töten und einfach mit den neuen pids neu starten.

Natürlich währe es noch viel idealer eine version von udpstreamts zu haben, welche immer den aktuellen sender streamt - so dass man extern gar nix tun müsste. Dies ist m.E. zur Zeit aber nicht möglich, oder?

Nachtrag@Pedant: Alle die von dir angesprochen Punkte bzgl. den Nachteilen eines Wartens auf ein ok stimme ich voll und ganz zu. Das ist kompliziert und müsste sehr vorsichtig gemacht werden, wobi das wichtigste wäre, das der normale Betrieb nicht gestört wird. Daher, hoffe ich dass ich damit im Unrecht war und es viel einfacher geht...

Viele Grüße
Arno

[seife]

Momentan ist das nicht möglich, aber es wäre wohl relativ einfach, an der Stelle im zapit, wo die PIDs für den MPEG-Dekoder selektiert werden, dieselben PIDs auch an ein udpstreamts zu übergeben und dieses udpstreamts beim nächsten Zappen zu beenden, wenn auch der MPEG-Dekoder angehalten wird.

[arno-neutrinoTV]

Das wäre cool. Wie wärs mit einer allgemeinen Lösung aufbauend auf deinem Vorschlag von vorhin, nur mit der Änderung, das dem script alle aktuellen pids mitgegeben werden.

Code: Alles auswählen

+   else if (msg == NeutrinoMessages::EVT_ZAP_COMPLETE)
+   {
+      showSignalBars(true);
+      if (access( ZAPCOMPLETE_FILE, 0 ) != -1)
+         CNeutrinoApp::getInstance()->execute_start_file(ZAPCOMPLETE_FILE); // <-- hier müssten die PIDs mitgegeben werden
+      return messages_return::handled;      
+   }

ein passenden script wäre dann (nur oberflächlich)

Code: Alles auswählen

ip = 192.168.42.255 // nur ein beispiel
killall udpstreamts
udpstreamts ip $*

Natürlich müssten man noch einbauen dass diese skript nur exisitert wenn man dieses feature wirklich nutzen will - aber das kann man dann über die webapi irgenwie hinbekommen.. denke wenn man obiges realisieren könnte, müsste sich das feature machen lassen.

Grüße
Arno

[Pedant]

Hallo Arno,

... dass allerdings dann auf dem TV das berühmt "Kanal nicht verfügbar" kommt.

als ich das heute kurz getestet hatte, hatte ich den TV gar nicht eingeschaltet, ich weiß also nicht ob dort Beschwerden aufliefen. Ich hatte allerdings mehr als einmal den Kanal gewechselt. Morgen werde ich nochmal einen Test machen und etwas genauer hinsehen und hoffentlich funktioniert es.

Gruß Frank

[dbt]

Könnte Dein Script-Entwurf schon beim jetzigen Stand der Dbox-Software verwendet werden oder müsste da noch was Anderes vorbereitend verändert werden?

Das ZAP_COMPLETE Event habe ich einem Snap schonmal drin eingebaut gehabt, allerdings wollte ich damit was anderes erreichen was hiermit überhaupt nichts zu tun hat, aber wie gesagt was man dann mit dem Event anstellt, ist was anderes. Evtl. reichte es für diesen Zweck aus.

2xI
1xI

Das Script muss hier liegen:

Code: Alles auswählen

/var/tuxbox/config/zap_complete.start

[Pedant]

@Arno,
dummerweise ist es tatsächlich so, dass beim Zappen, während ein Stream abgerufen wird, der neue Kanal mit Kanal zur Zeit nicht verfügbar erscheint und ab dann gilt das für alle Kanäle auch wenn der Server nichts mehr abruft. Nur gelegentlich beruhigt sich die Dbox wieder durch mehrfaches Umschalten, meist ist aber ein Reboot nötig.
Dem Server hingegen ist das "Kanal zur Zeit nicht verfügbar" egal, er kann trotzdem den aktuellen Kanal abrufen.

Stoppt man den Server vor dem Zappen, so funktioniert es am Server und am TV.

Getestet habe ich mit "Das Erste" und "ZDF", um zwei unterschiedliche Transponder zu haben.
Wer es auchmal ausprobieren möchte:

Serveraufruf für "Das Erste"

Code: Alles auswählen

C:\Programme\VideoLAN\VLC\vlc.exe http://dbox_ip:31339/0,0x64,0x65,0x66 :sout=#duplicate{dst=std{access=http,mux=ts,dst=0.0.0.0:1234}}

Serveraufruf für "ZDF"

Code: Alles auswählen

C:\Programme\VideoLAN\VLC\vlc.exe http://dbox_ip:31339/0,0x64,0x6e,0x78 :sout=#duplicate{dst=std{access=http,mux=ts,dst=0.0.0.0:1234}}

Clientaufruf - Sender unabhängig

Code: Alles auswählen

C:\Programme\VideoLAN\VLC\vlc.exe http://server_ip:1234

Die Kommdozeile für die Windows-Eingabeaufforderung sind jeweils Einzeiler, auch wenn die Zeilen hier automatisch umgebrochen dargestellt werden. dbox_ip und server_ip müssen noch individuell angepasst werden. VLC-Version 0.8.6d. Wer nur einen Rechner hat, der kann auch den Server- und den Clientaufruf am selben PC starten. Weitere Details siehe hier.

Es bleibt also die Frage, was die Dbox dabei so verwirrt, dass sie keine Kanäle mehr findet.
Entweder findet sich der Grund und eine Lösung dafür oder das Zapping-Event ist doch anspruchsvoller, als zunächst von mir gedacht, zumindest in Bezug auf VLC-Streaming.

@dbt,
Danke für die Images, ich habe sie mir mal runtergeladen, auch wenn es so scheint, dass Arno mit seinem Einwand, dass es nicht so einfach wäre, recht hat.

Gruß Frank

[yjogol]

Hi zusammen,

ich fasse mal zusammen:
- http-Streaming kann man hierfür so ohne weiteres nicht verwenden
- upd-Multicast ist sicher die sinnvollste Lösung
- wir brauchen einen Event vor dem Zap (EVT_ZAPTO). Da muß dann festgestellt werden, ob der udp-Server läuft und beendet werden. Der Zap-Event muß solange warten.
(Und wenn wir dieses Skript schon haben, könnte es ausserdem zwei weitere Dinge tun:
1. falls ein Stream gerade läuft, das Umschalten verhindern oder
2. den Stream-Server streamts/streampes killen)
- wir brauchen einen Event nach dem Zap (EVT_ZAP_COMPLETE, EVT_ZAP_SUB_COMPLETE). Falls der udp-Server zuvor lief, muß er mit den neuen Pid wieder gestartet werden.

Wäre es das?

Gruß
yjogol