Beiträge von Tode

    sorry, aber Dein post hilft mir nicht wirklich weiter. Ich habe einen 37" (aber halt noch nicht FUll HD).


    SD sieht anständig aus (aber das ist definitiv eine subjektive Sache, da will ich auch nicht drüber streiten).


    Dass HD tausendmal besser aussieht sollte auch dem letzten Dodo klar sein.


    Was ich aber wissen will:


    Wie sieht SD über DVI im Vergleich zu SD über Scart aus.


    Und zu Dieser Frage liefert mir Deine Antwort leider überhaupt keinen Anhaltspunkt.


    Tode

    Das ist KEIN neuer "wann kommen die 8er Boxen und was werden sie können"- thread sondern eine reine Information für mich (möglicherweise basierend auf bereits bestehenden HD- Boxen der Mitkonkurrenten):


    Momentan habe ich eine 7025+ an meinem Toshiba HD- Ready (noch nicht Full HD) Gerät über ein hochwertiges Scart- Kabel hängen, und ich bin wirklich zufrieden mit der Qualität (dafür, dass die Sender so an Bandbreite sparen sieht das ganz anständig aus...).


    Ich glaube auch nicht, dass ich z.B. über YUV bessere Ergebnisse bekommen kann, da das ja nicht wirklich supported ist und ich mir die Bastelei sparen wollte nur um rauszufinden, dass es nix bringt...


    Dafür passiert aber ja intern folgendes:


    1. Der Digitale SAT- Stream wird auf der Dream in ein analoges Signal umgewandelt.


    2. Dieses analoge Signal wird über Scart an den Fernseher übertragen.
    3.Dieser wandelt es wieder zurück in Digitale Daten (LCDs brauchen das ja so)
    4. Danach rechnet der Scaler im Fernseher die Bilder auf die passenden 720p hoch.



    Das heisst: erst d/a- Wandlung, dann a/d- Wandlung, dann Scalen, dann ausgeben.


    Ich stelle mir das ganze jetzt in meiner naiven Art in einer HD- fähigen Box für SD- Material so vor:


    1. Das Signal kommt digital vom Satelliten.
    2. Die Box scaled das digitale Bild auf das eingestellte Fernsehformat
    3. Das Bild wird digital zum Fernseher übertragen
    4. Der Fernseher gibt es -hoffentlich ohne erneute Berechnung wegen Overscan- direkt aus.


    Die doppelte Wandlung müsste hier eigentlich wegfallen, ausserdem leidet ein digitales Signal bei der Übertragung zum Fernseher nicht durch äussere Einflüsse...


    Das heisst für mich: auch die SD- Kanäle müssten mit einem HD- fähigen Receiver auf einem entsprechenden Fernseher an Brillanz gewinnen.


    Wenn sich rausstellen sollte, dass der Scaler der Box nichts taugt, könnte man ja immer noch 480p per Box ausgeben und dann den TV scalen lassen, aber das hoffe ich doch mal nicht...


    Habe ich bei diesen Annahmen irgendwas übersehen ?
    Kann ein Besitzer einer HD- Box (leider ja noch nicht Dream) die Bildverbesserung bestätigen (oder eben nicht, wenn ich total daneben liege) ?


    Thanx
    Tode

    gut... dann gehen wir es mal anders an:


    Die Developer wollen / können dieses Feature im Moment nicht liefern (wahrscheinlich gibt es genug andere Dinge mit Prio).


    Wenn uns aber jemand sagen könnte, in welchen Python- Files welche Aufrufe beim Enigma2- Start für den Skin zuständig sind (oder zumindest mal sagen, in welchen python- Files was über die Skins drinsteht), dann könnte man ja mal anfangen zu basteln.


    Es sei denn, das ganze Skin- Handling findet auf einer tieferen Ebene statt...


    Dann findet sich sicher der ein oder andere, der aus dem "Enigma2- Reinit" ein "Enigma2-Skin-Reinit" bastelt...


    Auch ich würde mich da gerne mit meinen Programmierkenntnissen (auch wenn ich noch nicht wirklich viel mit Python gemacht habe, aber vielleicht kann ich mit "logik" helfen) einbringen...


    Gruß
    Tode

    auch ich wechsle meinen Skin nicht regelmässig.. (aktuell nutze ich Nemesis Glassline, den finde ich richtig genial, das beste was ich bisher gesehen habe).


    Aber wenn ich ein neues Image aufspiele, oder man wieder 5-10 Skins runterlade, dann würde ich diese Skins halt einfach gerne in einer "besseren" Preview ausprobieren... Die Bilder, die in den Skin- Selektoren drin sind, sagen ja nicht wirklich was darüber aus, wie sich ein Skin "anfühlt" (Lesbarkeit der Schriften, Aufbau der Listen, etc...).


    Wenn ich mich dann für einen Skin entschieden habe, bleibt der auch ne ganze Weile auf der Box... Aber das ausprobieren dauert mir persönlich viel zu lange...


    Ich könnte mir sowas vorstellen wie:


    2 Möglichkeiten:
    1. Skin auswählen -> Preview (mit möglicher Warnung: Stabilität erst nach reboot)


    2. Skin auswählen -> Übernehmen -> Enigma2 wird neugestartet.


    Dann könnnte man schnell die Skins antesten, und wenn einem der Skin gefällt, macht man EINEN restart von Enigma um die Änderungen zu übernehmen.


    Weitergesponnen könnte man dann im "Preview"- Mode rechts oben in der Ecke einen Text "Preview" einblenden, damit man nicht vergisst, die Änderungen per Knopfdruck dann "endgültig" zu übernehmen.


    Das wäre mal ein richtig cooles feature...


    Tode

    natürlich muss ich "Nur" enigma2 neu starten. Aber auch das dauert in meinen Augen viel zu lang, um "mal schnell" 5 Skins auszuprobieren. spätestens nach 2 habe ich da keine Lust mehr...


    Deshalb diese Frage. Wenn es einen "Workaround" gäbe ala...


    "Ruf die Funktion InitAllSkins in der InitEnigma.py auf"


    der nur nicht verwendet wird, weil das ganze instabil werden kann / wird, dann würde ich das gerne wissen und das gerne mal "riskieren".


    Gruß
    Tode

    Ein Skin besteht doch aus ein paar Bildern und den "Positions"- und "Transparenz"- Werten der Elemente (mal grob vereinfacht).


    Weshalb muss bei einem Skin- Wechsel dann immer die ganze Box neugestartet werden ?


    ist das


    a) Bequemlichkeit, weil man sonst das "neueinlesen" der Skins erst mal programmieren müsste
    b) Hoffnung auf mehr Stabilität, weil der Skin nicht "on the fly" ausgetauscht wird, es keine Files gibt, die gerade im Zugriff sind,etc...
    c) Eine technische Hürde, die nicht genommen werden kann ?


    Es würde mich einfach interessieren... Wenn man ein paar neue Skins ausprobieren will, dann ist man locker mal 10 minuten dran, nur weil man ständig neu Booten muss...


    Thanx
    Tode

    Du drehst Dir alles so hin, wie es Dir passt...


    Ich habe nie behauptet, dass alle Plugins / anderen Images illegal wären.


    Ich habe nur gesagt, warum hier über DIE Erweiterungen, die illegal sind, nicht gesprochen wird.


    Ein Fritzcall- Plugin, ein Wetter- Plugin, ein Auto- Timer, und wie sie alle heissen sind natürlich in keinster Weise illegal.


    Aber sie sind NICHT von Dream.


    Dream kann und wird keine Beschreibungen der Zusatzfunktionalitäten auf Ihrer Website aufnehmen, die nicht von Ihnen kommen.


    Das hat was mit "zu eigen machen" zu tun und könnte unter anderem rechtliche Konsequenzen haben (wer haftet, wenn eines der Plugins die bei Dream erwähnt werden aber nicht zu Dream gehören, Schaden beim Kunden anrichtet...).


    DMM macht keineswegs ein "Geheimnis" um die vielen und tollen Features die es für Ihre Boxen gibt. Aber sie promoten diese auch aus oben genannten Gründen nicht aktiv.


    Aber immerhin stellen Sie ein Board zur Verfügung, in dem die Autoren Ihre Plugins (zumindest die legalen) vorstellen und der Allgemeinheit zur Verfügung stellen können.


    Nochmal: Es gibt kein "GEHEIMNIS" um die Boxen von Seitens DMM.


    Das sind Receiver. Die zeigen Dir das Fernsehprogramm inklusive eines EPG und mit manchen der Boxen kann man auch Aufnehmen und teilweise Media- Files abspielen.
    Ausserdem kann man sie über den PC updaten und Filme / Dateien per Netzwerk zwischen PC und Dreambox austauschen.


    Thats it...


    Alles was darüber hinausgeht, und nicht den "Kernkompetenzen" eines Receivers entspricht, kommt halt von anderen Programmierern.
    Und da kocht jeder sein eigenes Süppchen (ich habe auch schon 2-3 Zeilen gecodet, bin aber eigentlich kompletter Newb was Dreamboxen angeht, habe sie erst seit 2 Monaten).


    Andersrum: Wenn DMM auf der Homepage schreiben würde, was man alles mit der Box machen KANN, dann kämen sofort User und würden von Täuschung / etc. sprechen, weil diese Funktionen ja nicht out-of-the-box installiert sind.


    So gabe es schon x Benutzer, die gesagt haben, dass Sie Ihre 500er zurückgeben, weil diese die "zugesicherte Eigenschaft" Streaming- Fähigkeit und Aufnahme auf ein NAS nicht besitze.... Alles nur, weil auf dem Karton steht "10/100 kompatibler Netzwerkanschluss".


    Aus solchen Gründen hält sich Dream mit solch generellen Statements aussen vor, und überlässt es jedem Benutzer selbst, herauszufinden, welche tollen Bonbons sich im weltweiten Web verbergen (zumal die sich nicht wirklich verstecken, einmal nach den Boxnamen und Forum gegoogelt kriegt man unendlich viele Informationen).


    So... jetzt habe ich hier genug Zeit verplempert... Ich gehe mich jetzt lieber wieder um meine Dreambox kümmern. Muss noch das ein oder andere Image einspielen und testen mit BarryAllen....




    Gruß
    Tode

    Dream Multimedia entwickelt einen (bzw. mehrere) Receiver auf Linux- Basis mit dem Hintergrund, eine offene Plattform für "Community"- Entwicklungen anzubieten.


    Die Receiver von Dream sind -out-of-the-box- nicht mehr und nicht weniger als genau das... Receiver (wenn auch Netzwerkfähig, aber das machen andere Hersteller inzwischen auch).


    Was die Community daraus macht (und dazu gehören halt zufälligerweise auch Entwickler von DMM, die in Ihrer Freizeit ebenfalls Software für die Dream entwicklen), kann DMM weder vorraussagen noch irgendwie beeinflussen.


    Die Frage "warum gibt es Fremdimages" ist damit ganz einfach beantwortet:


    Weil sie jemand macht, der gerne standardmässig Funktionen eingebaut, die es im Original- Image von DMM nicht gibt.


    DMM released ausserdem nur in bestimmten Abständen eigene Images, nämlich genau dann, wenn die Entwickler diesen Stand für absolut stabil halten.
    Trotzdem wird die Software kontinuierlich weiterentwickelt, und aus diesen Veränderungen kann man wiederum eigene Images machen (sogenannte CVS- Images), die dann zwar den aktuellsten Entwicklungsstand wiederspiegeln, nicht aber unbedingt in allen Funktionen stabil laufen.


    Du willst natürlich wissen, warum niemand die "tollen" illegalen Sachen hier auflistet, die man mit den Dream- Boxen machen kann.


    Auch wieder ganz einfach: Weil sie gegen geltendes Recht verstossen und eben gerade NICHT von DMM kommen...


    Du fragst nach den Möglichkeiten: Die sind unendlich, alles was sich für Linux entwickeln lässt und mit den Hardware- Ressourcen der Dream zurecht kommt ist möglich.


    Aber ob Du jetzt wirklich ein Excel / Word auf der Dream brauchst, wage ich zu bezweifeln...


    DMM liefert Bedienungsanleitungen auf Ihrer Homepage, die genau beschreiben, was die Receiver von Haus aus können.


    Zu allem anderen gilt das gerade geschriebene...


    Gruß
    Tode

    wenn Du wirklich aufmerksam die Berichte gelesen hättest, dann hättest Du gesehen, dass die Temperatur- Probleme mit dem neuen Netzteil aus der Welt waren.


    Da Du jetzt gerade eine Box gekauft hast, hast Du wahrscheinlich sogar die 7025+, die dann schon die dritte Generation des Netzteils verbaut hat. Mit dieser sind dann gar keine Wärmeprobleme mehr bekannt...


    Also: Kein Grund für einen Hals. Und deine "Erkenntnis" ist inzwischen schon mehrere Monate alt.


    Gruß
    Tode

    Das ist meiner Meinung nach falsch... wenn man sich die Videos von den Messen anschaut, dann sieht man, dass in der 8000er ein blaues OLED verbaut ist. Ich weiss nicht, wie du darauf kommst, dass das Bild KEIN OLED zeigt...


    Gruß
    Tode

    also den Typen vom Blödmarkt traue ich viel zu...


    nachdem die 7025+ bereits 3 Monate auf dem Markt war, und bei keinem einzigen Online- Shop noch eine 7025 zu kriegen war, bin ich dorthin gegangen, um sie von ihrer veralteten 7025 zu erlösen.


    Der Kerl hat mir gesagt: Neues Modell ? Quatsch... das ist immer noch das aktuelle. Es gibt nichts neueres. Das hätte ihm letzte Woche der Verkäufer von Dream persönlich bestätigt.


    Soviel zur Kompetenz der Blödmarkt- Leute... (ach ja: Im iNet gabs zu dem Zeitpunkt die Plus für 499, im Blödmarkt kostete die alte Box noch 599).


    Insofern könnte ich mir vorstellen, dass das vertauschen der Kartons bei denen selbst passiert ist... (2x 7025 ausgestellt, dabei eine aus versehen als Plus und dann beim einpacken die beiden falsch eingepackt.. Wahrscheinlich ohne zu wissen, dass es 2 verschiedene sind)


    Gruß
    Tode

    HeiRos:


    1. Sind Tabellen im "Modernen" Webdesign vollkommen "out", weil sich -wie Reichi schon ausgeführt hat- kein einziger Browser an die Standards hält, und ein konsistentes Layout auch nur über 2 Browser hinweg praktisch unmöglich ist.
    Ganz schlimm: IE6 und IE7 unterhalten sich KOMPLETT unterschiedlich, und um es noch zu verbessern, verhält sich der IE6 je nach User- Konfiguration unterschiedlich.


    2. Ist CSS das Design der Stunde (auch wenn hier ähnliches gilt für die verschiedenen Browser, aber hier gibt es wenigstens für die verschiedenen Browser funktionierende Workarounds)


    Nur mal zur Tabelle mit "Dynamischer Höhe": Wenn ich im IE eine Tabelle mit 100% Höhe definiere, dann habe ich IMMER Scrollbalken, weil der Browser als 100% den gesamten Bildschirm annimmt, und vergisst, dass er ja auch noch ne Menuleiste und Symbole hat....


    Also: Tabellen sind für eine aktuelle Website ein absolutes "NoGo" als Element zur Seitengestaltung.


    Gruß
    Tode

    Thanx for your answer.


    I already updated my code to prohibit the crash.
    I created a completely new py- File with 2 new functions called:


    GetDescriptionWithFallbackFromService(service)


    and


    GetDescriptionWithFallbackFromEvent(event,descr)


    These to functions take either a service or an event as parameters and try to give back a "sensible" description (whereas the second one takes a "default"- or "fallback"- description as parameter).


    I can not speak for a "general standard". But I looked at a lot- of german stations and found out some interesting things:


    A lot of them seem to send a long- description (EPG) only, but no short- description. The title -e.g. of series- very often is empty, but is shown in addition in the long- description.


    Whether the stations do not send this information, or if the Dreambox does not read it correctly, is something, that I could not find out yet.


    From my experience with german stations I implemented the following search- order:


    Search for double quotes: if found, take the text in between
    Search for single quotes: if found, take the text in between
    Search for colon: if found, take the text before the colon
    Search for dot: if found take the text before the first dot
    else: Take the first 20 characters.


    This information is mostly true for series (e.g. Heroes, Emergency Room, etc.), not for Movies, where the Short- Description most often is empty, or filled with something like a genre ("Comedy") or something.


    Best thing would be, to make the search- order configurable in a config- screen, and probably to let the user define his own special characters to search for. You could as well let him choose the number of characters to use, if the characters were not found.


    I'll attach my new "MovieUtils.py" that I copied to the Components- folder as well as two implementations: Your Movie- Retitle and a change in RecordTimer.py.


    Probably you can use it.
    Best regards


    Tode

    ich habe eine kleine Hilfsbibliothek geschrieben, die momentan nur eine Funktion enthält:


    GetDescriptionWithFallback( service )


    Die Funktion erwartet einen Service als Parameter und gibt die zu diesem service gehörige Description zurück.


    Dabei geht sie folgende 3 Schritte durch:


    1. Gibt es eine meta- Datei, wird die dort hinterlegte Description zurückgegeben.
    2. Gibt es die nicht, versucht er aus dem Event über getShortDescription die Description auszulesen.
    3. Gibt es die nicht, wird die Extended - Description des Events geparst:
    a) Gibt es einfache Hochkommata, wird der Wert zwischen ihnen zurückgeliefert.
    b) Gibt es doppelte Hochkommata, wird der Wert zwischen ihnen zurückgeliefert
    c) Fallback sind die ersten 20 Zeichen der extended- Description



    Ich habe die Funktion in eine eigene "Modifikation des "MovieRetitle"- Plugins integriert, um bei Serien, für die keine Description existieren die Description aus der extendedDescription auslesen zu können.


    Aber ich habe sie ausgelagert, weil ich mir das auch gleich im RecordTimer.py vorstellen könnte. Da werde ich mich als nächstes dranmachen.


    Vielleicht kanns ja mal jemand brauchen.


    Gruß
    tode


    Wer es testen will, kann einfach die plugin.py im MovieRetitle- Plugin durch die angehängte ersetzen (einfach entsprechend umbenennen, und das sichern der originalen vorher nicht vergessen) und die MovieUtils.py ins Components- Verzeichnis kopieren.

    Die Fehlermeldung im Crashlog lautet:


    AttributeError: 'NoneType' object has no attribute 'getExtendedDescription'


    Die Funktion klappt für die meisten Einträge in der Movie- Liste nur für einige liefert sie nix zurück.


    Alle Aufnahmen sind über einen Timer aufgenommen worden und unterscheiden sich scheinbar durch nichts... Nur bei einigen kommt der Fehler


    Wie komme ich dem Problem auf die Spur ?


    Thanx
    Tode

    I needed a function to automatically fill the description with text from the extended description because some senders do not send a correct description for the events.


    I added the functionality to your great plugin:


    if description is empty and extended Description contains <'> then the description is replaced by the part of the extended description between the two ' ' characters.


    Example:


    On start of the plugin:


    Description = ""
    Extended description: Folge 10: 'The best friend': Theo meets...


    After start:
    Description = The best friend


    Here is the code I changed:


    Probably you find it usefull for changes in future.
    But be careful: There is no error- handling in this code at the moment. Whenever there is no ' in the text it will crash enigma. I will fix that when I am back at home.
    regards
    Tode

    Ich wurstle mich grad so ein wenig durch Python- Quelltext und interpretiere da ein wenig was rein:
    Wenn ein Text so im Quelltext steht:


    _("This is a text")


    dann wird das von Python automatisch als zu "übersetzender" Text erkannt.
    Die Übersetzung holt er sich aus der de.po - Datei.


    Das würde aber bedeuten, dass man neue Texte aus seinen Plugins immer dort übersetzen lassen müsste. Wie geht sowas von statten ? Oder kann man auch "plugin-spezifische" übersetzungs- Dateien hinterlegen ?


    Gruß
    Tode