Aufruf Entwicklung Windows OpenATV Tool

Nachricht

pybcu · #21

Konkrete dinge, die das Programm oder die Weboberfläche denn leisten können soll wären hilfreich, um das ganze besser einordnen zu können. Wenn es um Dateien hin-und-herschieben geht oder darum, ein Kommando auszuführen gibt es ja auch die Möglichkeit per ssh(fs) auf die Box zuzugreifen, da gibt es auch etliche Clients.

Und eine grundsätzliche Bedienung ist über openwebif ja bereits ebenso möglich (auch wenn das durchaus etwas Liebe vertragen könnte).

Was also wäre eine Wunschliste der Features?

coMMas · #22

Also wenn ein neues Web-Interface, dann bitte Runderneuert und unabhängig von allen bisherigen, einfach mal neu von Null (das bewährte kann man ja hinter den richtigen Icons verstecken - leicht aktualisierte Ansicht).

Damit rückt dann auch die Fernbedienung etwas weiter entfernt, jeder hat sowieso sein SmartPhone in greifbarer Nähe, warum damit nicht auch den Receiver ohne App steuern (mit passender Mobil-Ansicht)?

Anbei mal ein einfacher Entwurf eines modernen Webinterfaces... das dann vielleicht auch ohne Tools (am Windows-/Linux-PC oder Mac) auskommt.

Der Dateianhang atv_web-if.jpg existiert nicht mehr.

Harro · #23

coMMas hat geschrieben:Also wenn ein neues Web-Interface, dann bitte Runderneuert und unabhängig von allen bisherigen, einfach mal neu von Null

Moin coMMas, nette Sache das! :-)
Ich würde aber trotzdem nicht auf eine App oder Tool unter welchem System auch immer setzen, sondern den neutralen Web-Browser benutzen wollen
VG, Harro

Old · #24

Genau, man muss unabhängig vom verwendeten Betriebssystem einen aktuellen Web-Browser verwenden können. Betriebssysteme reichen ja mittlerweile von Microsoft Windows, Apple iOS, Google Android und Linux auf Computern, SmartPhones und Tablets, Da ist ein Web-Broser immer vorhanden und es braucht keinerlei zusätzlicher Installationen von Apps/Tools oder sonst was.

Killefit · #25

Ähm, die Idee eines Webinterfaces, das in allen Browsen Hardware- und OS-unabhängig funktioniert, ist ja wirklich toll und wäre in der Tat ideal.
Meine Erfahrung als IT Admin (nicht Programmierer!) in einem mittelständigen Unternehmen zeigt aber leider, dass das in der Praxis oft nicht so toll funktioniert.
Da funktioniert ein Webinterface nur sauber mit Firefox, eines mit Chrome, das nächste mit IE. Wieder eines hätte gerne im IE den Kompatibilitätsmodus, während ein anderes damit nicht läuft, und ein drittes läuft nur mit TLS 1.2, ein viertes aber wieder nicht.
Fehlermeldungen bei Nichtfunktion gibt's dann nicht, und man wundert sich einfach, dass sich nichts tut, und ist stundenlang mit Fehlersuche beschäftigt, bis man auf den Browser oder dessen Einstellungen kommt.
Wenn ein Webinterface dann doch einmal funktioniert, ist es oft einfach nervtötend lahm.
Meine Kollegen und ich wünschen uns inzwischen mehrheitlich proprietäre Managementkonsolen zurück, die zuverlässig und performant funktionieren.
Just my 2 cents...

#26

Die grundsatzfrage, die sich dabei stellt ist:
- Soll man mit diesem Tool einen USB Stick zum Flaschen bauen können?
- Soll man mit RS232 flaschen können?

Wenn das die Anforderung ist, wird das mit der Anbindung eines Webinterfaces eher schwer, denn bei Windows gibts viele Schnittstellen bzw. Laufwerke und das über ein Webinterface zu entkoppeln ist vielleicht nicht der richtige Weg.

Ich glaube ja, es geht mehr um eine einfache Bedienung für Windows User, die keinen Schimmer haben von allem. Also ein Tool, dass alles für einen erledigt (also den Boxtyp auslesen, Stick vorbereiten, backup erstellen, backup einspielen, usw...)

Sonst wäre der Aufruf an Windows Entwickler ja nicht nachvollziehbar.

sirtobie · #27

So was gibt es schon für HDMU. Leider hat der Entwickler "morly" keine Lust / Zeit mehr. Das Tool funktioniert prinzipiell mit jedem Image.

#28

Killefit hat geschrieben:Ähm, die Idee eines Webinterfaces, das in allen Browsen Hardware- und OS-unabhängig funktioniert, ist ja wirklich toll und wäre in der Tat ideal.
Meine Erfahrung als IT Admin (nicht Programmierer!) in einem mittelständigen Unternehmen zeigt aber leider, dass das in der Praxis oft nicht so toll funktioniert.
Da funktioniert ein Webinterface nur sauber mit Firefox, eines mit Chrome, das nächste mit IE. Wieder eines hätte gerne im IE den Kompatibilitätsmodus, während ein anderes damit nicht läuft, und ein drittes läuft nur mit TLS 1.2, ein viertes aber wieder nicht.
Fehlermeldungen bei Nichtfunktion gibt's dann nicht, und man wundert sich einfach, dass sich nichts tut, und ist stundenlang mit Fehlersuche beschäftigt, bis man auf den Browser oder dessen Einstellungen kommt.
Wenn ein Webinterface dann doch einmal funktioniert, ist es oft einfach nervtötend lahm.
Meine Kollegen und ich wünschen uns inzwischen mehrheitlich proprietäre Managementkonsolen zurück, die zuverlässig und performant funktionieren.
Just my 2 cents...

Das war ein Hammerstatement (sozusagen aus der Praxis). Dem kann ich nur voll zustimmen:
Leider ist der bisher kompatibelste Browser für mich FireFox. Daher setze ich dort den "ESR" ein. Man muß nicht jeden neuen Krampf drinhaben.
Und die Management-/ Konsolentools sind auch in E2 der letzte Weg, klare Meldungen des Systems zu erhalten, und nicht das, was zufällig in der GUI irgendwie ankommt.

#29

Um dieses Thema mal aufzuwärmen:

An sich finde ich die Idee gut, allerdings hat Old leider Recht, was die Basis des Systems angeht:
Sie ist alt, scheiße gepflegt und was noch viel schlimmer ist: Schon auf einem kranken Fundament aufgebaut.

Die zwei elementarsten Fehler an E2 sind:

Es ist keine richtige Linux-Anwendung

Mit diesem Problem kollidiere ich leider immer wieder.
E2 will z.B. bestimmte Dinge ganz anders und selber machen, die eigentlich schon das System - also Linux - machen kann.

Beispiele sind
- der CAM-Start aus Python heraus, obwohl das die Aufgabe von SysVinit oder im Idealfall systemd wäre (Immerhin das hat OpenPLi richtig/besser gemacht).
- blindes Herumschreiben an Konfigurationsdateien mit Informationen aus Nicht-Systemkonfigurationsdateien, z.B. das Murksen in /etc/auto.network und /etc/fstab mit Informationen aus einer Murks-automounts.xml, statt die Informationen auch aus den Dateien zu nehmen, die geschrieben werden.

E2 "spricht" auch nicht mit Linux, es quält es nur wie oben beschrieben.
E2 reagiert nicht auf Signale, um z.B. seine Konfiguration neu einzulesen oder die aktuelle zu schreiben (Allein das ist schon ein gewaltiges Hindernis für eine anständige Zweit-GUI im Browser).

Alles was E2 mit dem Benutzer kommunizieren will, muß es durch diese grausame Scriptsprache Python tun und entsprechend bläht auch immer mehr Python-Code E2 auf.
Es ist eine einziger monolitischer Klumpen in mehreren Sprachen

Was mich an E2 am Anfang (negativ) fasziniert hat, war die Tatsache, daß meine Aufnahmen abgebrochen wurden, wenn ich bloß die GUI neugestartet habe.
So etwa das erste Jahr habe ich echt gedacht, den Fehler muß doch endlich mal jemand beheben ...

E2-Oldies finden das vielleicht völlig normal und verstehen gerade nicht, was ich meine ...

Wer aber unvoreingenommen nachdenkt, wird zu dem Schluß kommen, daß Google seine Apache-Web-Server schließlich auch nicht runterfährt, nur weil ich meinen Chrome schließe ...

Was ich damit sagen will:
E2 fehlt es an der Trennung in mindestens einen schlanken Daemon ("enigma3d") und eine GUI (Auch wenn der ganze Klump so bezeichnet wird).

Das bringt mich zu folgendem Fazit:
An so einer miesen Basis wollen wirklich immer weniger Leute mitentwickeln (Alle Teams schrumpfen).
Ich wage zu behaupten, daß von den noch aktiven Entwicklern in der Szene auch nur noch 1-3 Leute bei OpenPLi die Kompetenz hätten, E2 so zu ändern, daß es auch wieder neue Leute fasziniert.
Ja, ich behaupte, daß OpenPLi die fähigsten Köpfe hat. Leider verschwenden sie ihr Talent in ständige Neuentwicklungen des Rades.

So in etwa würde ein anständiges System aussehen:

Ein Daemon tut nichts anderes als Streams in Dateien aufzunehmen. Den Programmierern ist dabei klar, daß "alles eine Datei ist", also auch eine named Pipe.
D.h. auch LiveTV ist programmiertechnisch eine Aufnahme, sie wird halt nur nicht auf Festplatte sondern in eine Pipe geschrieben.

Da dieser Daemon unglaublich primitiv ist (Man könnte ihn vermutlich sogar als Shell-Script mit vorhandenen Tools realisieren), gäbe es wohl kaum irgendetwas, das in zum Abstürzen bringen kann und da er nichts anderes macht auch keinen Grund, ihn jemals neu zu starten.
D.h. Aufnahmen liefen - wenn ich es dem Daemon nicht explizit anders mitteile - durch, selbst wenn ich die GUI neustarte oder sie abkackt weil mal wieder mieser Python-Code rumspinnt.
Nennen wir ihn einfach mal "dvbd".

Parallel (nicht huckepack) läuft dann eine GUI und zwar wirklich eine nur eine GUI.
Was ich dem Schweinchen alles an Zusatzaufgaben aufhalse ist erstmal egal, seine Kernaufgabe wäre es aber, dem "dvbd" einfach nur zu sagen, was er gerade aufnehmen soll und sich für LiveTV an die entsprechende Pipe zu klemmen, um diese zum TV/Monitor zu bringen.

Andere Quellen (Also z.B. Youtube und weitere Mediaportale) wären dann wiederum nur weitere Daemons, deren einzige Aufgabe es wäre, die Fremdquellen der GUI bereitzustellen, wenn dieser danach gelüstet.
Das könnten dann vollkommen modular youtubed, dvdd, blurayd, mediaportald, hdmiinputd usw. sein.

Und jetzt kommen die ganzen Leckerchen, die ein solcher sauberer Aufbau mit sich brächte:
Ob die GUI dann überhaupt noch auf demselben Gerät läuft ist wumpe, sobald ich die Pipe auch über's Netz bereitstellen kann.

Ich kann auch eine Schicht dazwischen schieben, nämlich einen apached und aus der GUI einen Webbrowser machen, der einfach nur für die Benutzung per Fernbedienung optimiert ist (Kombiniert mit Webseiten, die für genau diese Bedienung optimiert sind).
Derselbe Apache könnte dieselben Daten herkömmlichen Browsern dann ganz anders aufbereitet präsentieren, vergleichbar der GUI auf Synology NAS.

#30

Du hast größtenteils Recht. Das mit dem Aufsplitten von E2 in mindestens 2 Teile steht schon seit Jahren auf meiner Todo Liste. ABER das ist so komplex das man das alleine nicht hinbekommt. Es stellen sich dabei ja auch 1000 Fragen. Wie kommunizieren GUI und Backend miteinander? Was soll das Backend überhaupt können? ... Da wird es jeweils nicht nur eine Antwort geben. D.h. es würde einige längere Diskussionen geben. Außerdem wäre es nicht super schlecht, wenn das neue GUI zumindestens teilweise abwärtskompatibel wäre...
Leider kann man auch nicht mit kleinen Schritten anfangen sondern muss eigentlich als aller erstes die wichtigen und komplizierten Fragen klären. Und bei so wenigen Entwicklern, die potentiell sich daran beteiligen könnten, wird das ganze wohl leider nie stattfinden. Die Hersteller krümmen ja auch keinen Finger.

#31

betacentauri hat geschrieben:Wie kommunizieren GUI und Backend miteinander?

Dafür kenne ich mich mit diesem Betriebssystem aus den 60er Jahren leider zu wenig aus.
In den 90er Jahren gab es in OS/2 jedenfalls named pipes.
Leider ist die Betriebssystem-Entwicklung seitdem eher rückwärts gegangen.

betacentauri hat geschrieben:Was soll das Backend überhaupt können? ... Da wird es jeweils nicht nur eine Antwort geben. D.h. es würde einige längere Diskussionen geben.

Nun, da gibt es eine ganz einfache Lösung

"Jeder hat ein Recht auf meine Meinung!"

Nein, jetzt mal
Bild

Der Daemon sollte so wenig wie möglich können, damit er schnell und stabil bleibt.
Praktisch der innerste Kern des C++-Codes von E2, eine Frequenz tunen, den Stream reinholen und weiterreichen.

Damit hast Du direkt einen weiteren Effekt:
Weil in diesem ersten Schritt nur ein Minimum aus E2 herausgeschnitten wurde, sollte der Rest eigentlich wie gehabt laufen, also abwärtskompatibel bleiben ... nur das man dann schon die GUI neustarten könnte, ohne daß Aufnahmen leiden.

#32

Also Aufnahmen (=Timer) gehören dazu. Was ist mit Autotimern? Ich will doch kein GUI starten damit Autotimer Timer erstellt ...

Aus dem vorhandenen E2 alles GUI artige rauszuwerfen so dass nur noch ein Backend ohne GUI übrig bleibt, stelle ich mir noch einigermassen "einfach" vor. Obwohl das wahrscheinlich an so vielen Stellen zusammenhängt, dass das auch nicht einfach wird. Schwieriger stelle ich mir vor eine ordentliche API zu basteln um das GUI anzusprechen bzw. über die das GUI Zugriff aufs Backend bekommt.
Für die Kommunikation sind Named Pipes eine Lösung oder shared Memory oder RPC. Besonders wenn man das GUI nicht auf der Box laufen lassen will, sondern auf einem anderen Gerät, sollte das ganze auch per Netzwerk funktionieren. Dann fallen named Pipes und Shared Memory eigentlich raus außer man bastelt was drum herum.

#33

betacentauri hat geschrieben:Also Aufnahmen (=Timer) gehören dazu. Was ist mit Autotimern? Ich will doch kein GUI starten damit Autotimer Timer erstellt ...

Ich würde die Überlegung vernachlässigen.

Denn wie Du schon schreibst:

betacentauri hat geschrieben:Aus dem vorhandenen E2 alles GUI artige rauszuwerfen so dass nur noch ein Backend ohne GUI übrig bleibt, stelle ich mir noch einigermassen "einfach" vor.

Nur wenn man das Problem in kleine Häppchen zerlegt, kann mit der jetzt noch vorhandenen Entwicklungskapazität was draus werden.

Die AutoTimer gleich am Anfang da mit rein zu nehmen macht eine Sisyphus-Arbeit daraus, denn da hast Du definitiv Zugriff auf Teile der GUI, die es im Daemon ja nicht gäbe.

Lassen wir den AutoTimer in der GUI, dann bleibt für ihn alles wie gehabt.
Und bisher muß die GUI ja auch laufen, damit AutoTimer gesetzt/aktualisiert werden, man verliert also nix.

Meine Hauptdirektive wäre übrigens: Faulheit.
Faulheit, Faulheit, und nochmals Faulheit.
Faulheit ist der Antrieb allen Fortschritts.
Nur weil Konrad Zuse zu faul war, seine Baustatik-Berechnungen auf Papier zu machen, hat er den Computer erfunden!

Deshalb wäre für mich der zweite Schritt nach einer Trennung in Daemon und Client, so viel Code wie möglich loszuwerden, indem man ihn durch solchen ersetzt, den eh schon andere pflegen!

Der vorhandene EPG samt API gehört in die Tonne und durch eine Datenbank ersetzt. Die Interfaces zum Zugriff auf Datenbanken gibt es fertig, für C++, für Perl und vermutlich sogar für dieses sch... Python.

In Perl genügt
use DBI;
um sich in einer SQL-Datenbank bis zum Erbrechen auszutoben.

Code: Alles auswählen

my @cinfo=$dbh->selectrow_array("SELECT sender.firma,sender.vorname,sender.nachname,eingangsdatum,eingangsart,rcpt.firma,rcpt.vorname,rcpt.nachname,ausgangsdatum,ausgangsart FROM container c INNER JOIN kunde AS sender ON sender.kunden_id=c.absender INNER JOIN kunde AS rcpt ON rcpt.kunden_id=c.empfaenger WHERE c.container_id=".$container);

Das gilt für alle anderen Teile von E2 auch:
Erik Slagter reibt sich daran auf, völlig bescheuerte Code-Schnippsel minimalst besser neu zu schreiben, statt sie komplett in die Tonne zu werfen.
E2 müßte einfach nur viel weniger selber machen und viel mehr durch libs/tools erledigen lassen, die eh schon von Entwicklerteams in Armeestärke bis zur Perfektion getrieben wurden.

#34

Ach ja:
Der obige Code-Schnippsel ist der Dreh- und Angelpunkt meiner Projektarbeit als Techniker.

Scrollt man den Code mit Notepad++ durch, sieht man uuuuuuuuuuunglaublich viel grün, also Kommentare.
Hätte ich mich nicht zu Tode kommentiert, hätte unser Projekt auf eine Seite gepaßt, was etwas wenig aussieht

Zu Tode kommentieren und für C++-Programmierer (Den bewertenden Lehrer) exotische Konstruktionen wie

Code: Alles auswählen

			# Weiter mit der nächsten Ebene wenn kein Container gefunden wurde
			next unless $test;

... oder sich darauf einen runterzuholen, daß Perl nicht typenstrikt ist ...

Code: Alles auswählen

	# Positionen der Matrix
	
	$cfg->newval( 'Grid', 'XAxis', (join(",",@xpos)));	# X-Achse aus Array @xpos in den Wert "XAxis" der Sektion "Grid" der INI speichern
	$cfg->newval( 'Grid', 'YAxis', (join(",",@ypos)));	# Y-Achse aus Array @ypos in den Wert "YAxis" der Sektion "Grid" der INI speichern
	$cfg->newval( 'Grid', 'ZAxis', (join(",",@zpos)));	# Z-Achse aus Array @zpos in den Wert "ZAxis" der Sektion "Grid" der INI speichern

kaschieren, daß man wirklich alles in Perl über einen Sack "use <Modul>" erledigt kriegt.

Leider hat Dream uns ja dieses ätzende Python hinterlassen, was uns mindestens ein Jahrzehnt zurückwirft.
Perls Net::Ping z.B. funktioniert vollständig, bei Python gibt es kein Gegenstück dazu (PyPing kann rein gar nix).
Weil Python rein gar nix kann, haben wir ja auch so viele os.popen ...

#35

Als ich vor ca. 15 Jahren mal mit dem DCC angefangen hatte, gab es gerade mal die Dreambox 7000. Auch die Entwicklungsumgebungen waren damals etwas simpler - in meinem Fall Borland C++. Irgendwann habe ich dann damit aufgehört, da die Anzahl unterschiedlicher Boxen-Varianten und Images drastisch zugenommen hat und mir somit die Anforderungen sowie Ansprüche der User geradezu über den Kopf gewachsen sind - von dem Zeitproblem einmal abgesehen.

Jetzt stehe ich kurz vor der Rente und habe (theoretisch) etwas mehr Zeit und könnte durchaus das vorhandene DCC etwas OpenATV-freundlicher zu machen, aber mit neuer Entwicklungsumgebung komplett neu aufsetzen werde ich die ganze Sache nicht.. Zumindest könnte das parallel zum hier vorgeschlagen Projekt laufen. Doch allen Ansprüchen wird es erfahrungsgemäß niemals genügen und es wird sich weiterhin nur auf die Windows-Plattform beschränken - Linux ist nicht so mein Ding und Mac besitze ich nicht, somit fehlt hier jede Erfahrung.

Aber unabhängig davon: Ein aufgebohrtes Webinteface seitens der Box mit weiterreichenden Möglichkeiten halte ich auch für die bessere Lösung.

#36

Hallo BernyR. Erstmal Willkommen, und Danke für dein Engagement!
Wäre eine Portierung in z.B. Java andenkbar? Dann wäre den WIN-, MAC-Usern und Linuxdosen gleichermaßen geholfen.

#37

Vielleicht hilft das ja: Free Pascal – Wikipedia

#38

Es ist in Borland C++ Builder 5 geschrieben (hat also nix mit "Pascal" zu tun) und lässt sich schon auf Grund der verwendeten (z.T. zahlungspflichtigen) Libraries nicht so ohne weiteres portieren. Ich bekomme es noch nicht mal in das angeblich multiplattformfähige RAD Studio XE2 von Borland portiert. Ist auch mittlerweile viel zu komplex...

Der C++ Builder stammt übrigens aus dem Jahre 2000! - LOL.

Pifall · #39

Ich plädiere für schieres ANSI C bei hardwarenahen Implementierungen und C++ bei nicht ganz so nahen Implementierungen. Das hat den Vorteil der Geschwindigkeit. DIe Hardwareentwickler können dann wieder ein paar Jahre Urlaub machen :-)

Es muss ja nicht unbedingt via Mnemonics duch die Assembler gejagt werden die Quelle.

Auch Compiler Bauer verdienen Respekt. GNU, gcc und g++ bitte Hin Richtung Enigma 3. Neu aufbauen.:-)

Bei einem WIndows Frontend nehmen wir dotNET mit C-Sharp, stecken ja ein paar tausend Mann Jahre Arbeit dahinter.

Welches OS ist heute nicht mehr gefrickelt ? Ich habe damals in Aalborg Dänemark auf The Party den Code für Pinball Fantasies optimiert, MC68000 Assembler, Blitter und Copper, Denise und Paula vs. scrollfreies Ruckeln. Taktzyklenoptimiert. was können die Caches und lohnt es sich Schleifenbildung zu schreiben oder straight down Code, weil dat kostet, Rücksprungadressen auf den Stapel zu packen. Man programmiert dann zwei Balken, horizontale und vertikale Austastlücke in den Horizontal und Vertical Blank IRQ, Restrechenzeiten in den Lücken. So macht man Games geschmeidig.

Mein Bruder sich selbständig gemacht nmit einer alten Dreh- und Fräsmaschine. Er selbst Glasmalstäbe angebracht, Geld geschürft und dann hat er eine hochdynamische gekauft für 360.000 Euro mit Johannes Haidenhain TNC 426 Steuerung. Seine Software GibbsCAM in 2,5 Dimensional der Demo Dongle. Er mich angerufen, kannst Du bitte GibbsCAM knacken , ich habe Aufträge ohne Ende. Ich so, wenn DU mit der Software Geld verdienst, holst Du das Original, das ist ist ein Ehrencodex der Szene. Ich Softice Kernal Mode Debugger an, STRG+D, bpx OpenWindowA() und bpx OpenWindowW(). Ich so, Brüderchen, das sind Assemblerseiten mit WIndasm32, scroll Du schonmal durch son bischen und koch mir Kaffee ja. Ich tausend Adressen aufgeschrieben in Little Endian auf so Notizblockzettel. Bruder so, wie lange dauert das. Ich so, das ist eine Sentinel Super Pro Protection, ich springe jetzt mal aus der Funktion hier zurück und dann trace ich weiter. Ich so, sach mal kann das sein, das es 12 verschiedene Dongle gibt ? Er so, ja gibt es die ? Sieht ganz so aus. Ich GibbsCAM voll aufgeschaltet mit Adressen egal, nur Befehlen für den Prozessor, mach nichts (NOP), return (RTE).

Bruder mir 1200 gegeben, er dann von BMW Aufträge gekricht. Ich zu ihm kaufe die SOftware die du liebst, das ist so bei Hackern. Das war immer so, wir haben COmputerspiele geknackt, wer ein SPiel spielt, der kauft das Original.
Er den Vertreter angerufen von GibbsCAM und für 36.000 die Linzenz gekauft. Er so, jetzt krich ich auch die Updates :-)

DaGuckste · #40

Liest sich irgendwie, als ob du nicht schnell genug schreiben konntest und die Gedanken viel weiter waren.
Was wolltest du sagen?