Beiträge von adenin

    Nö, das geht hier wie erwartet


    Timeout:

    Code
    (0)fe event: status 1, inversion off, m_tuning 6
    Timeout!
    answer: True
    Traceback (most recent call last):
      File "/usr/lib/enigma2/python/mytest.py", line 193, in processDelay
    	callback(*retval)
      File "/usr/lib/enigma2/python/Plugins/DemoPlugins/TestPlugin/plugin.py", line 54, in mycallback
    	raise Exception("test-crash")
    Exception: test-crash


    yes:

    Code
    (0)fe event: status 0, inversion off, m_tuning 5
    action ->  MsgBoxActions ok
    answer: True
    Traceback (most recent call last):
      File "/usr/lib/enigma2/python/mytest.py", line 193, in processDelay
    	callback(*retval)
      File "/usr/lib/enigma2/python/Plugins/DemoPlugins/TestPlugin/plugin.py", line 54, in mycallback
    	raise Exception("test-crash")
    Exception: test-crash


    no:

    Code
    (0)fe event: status 0, inversion off, m_tuning 5
    action ->  MsgBoxActions ok
    answer: False
    (0)fe event: status 1, inversion off, m_tuning 6

    Hallo leute


    wie im betreff schon zu lesen ist geht es um das alte leidige thema UC0 die meisten gehen hier von einem defekten tuner als hardware aus aber was ist wenn es mal nicht der fall ist das es an der hardware liegt wie verhällt es sich wenn der fehler in der software liegt kann man dann per JTAG was dagegen tun Frage deshalb weill hab mir mal angesehen was so eine reparatur kostet ab 70 € aufwärts und nun ist die frage was wäre wenn es nicht die hardware ist die defekt ist sondern die software dann ärgert mann sich schwarz und dream multimedia verlangt sogar noch mehr für die behebung des fehlers wäre es denn nicht besser vorher genau zu wissen welche der beiden dinge zu trifft ???

    Ja, solche aussagekräftigen Überschriften in Verbindung mit solchem Textinhalt findet man auch in mancher Tageszeitung.



    Da es auf offiziellen Seiten keine Infos dazu gibt, nehme ich an, das da jemand in betrügericher Absicht handelt.

    das mit dem crashlog wird aber eine never ending story, da immer nur der erste Fehler protokolliert wird,
    und da das ein gp Skin ist, wird es sehr viele "Fehler" geben, weil im Skin sehr viele gp specifische Elemente drin sind,
    die in jedem anderen Image zum Buntscreen führen

    Warum soll ich mich durch den Skincode wühlen, wenn der Crashlog genau sagt was faul ist.
    Ein zugeordneter Fehler reicht völlig.
    Und ich muss ja auch nicht alle 1234 Image-spezifischen Sachen finden um auszusagen, dass das nicht geht, weil der Skin für ein anderes Image ist.

    Noch einer, der mich nicht mag?
    Mist. Da muss ich jetzt schon die Strümpfe ausziehen, damit ich die Leute zählen kann. :winking_face:
    (Das war überheblich :grinning_squinting_face: )


    Ich hab jedenfalls keine Probleme Images zu bauen.
    Der Holzweg liegt im Auge des Betrachters.


    beste Grüße
    adenin

    this is a bug in sed 4.2.1 :smiling_face_with_sunglasses:
    downgrade to a lower version.
    clean and rebuild glib, because all directories are empty.


    sed sperrt sich selbst die Zugriffsrechte auf seine eigenen temporären Dateien :kissing_face:
    beste Grüße
    adenin

    Über http kommt dieser Fehler:

    Code
    git clone -n http://git.openembedded.net/openembedded /home/adenin/test6/openembedded/1.5/openembedded
    Initialized empty Git repository in /home/adenin/test6/openembedded/1.5/openembedded/.git/
    fatal: http://git.openembedded.net/openembedded/info/refs not found: did you run git update-server-info on the server?
    make: *** [/home/adenin/test6/openembedded/1.5/openembedded/.git] Fehler 128