Beiträge von betonme

    Mal ein aktueller Stand bei mir.


    Konfig:
    DM920 mit aktuellem Experimental Image
    PC mit DVBViewer Media Server
    GBit Netzwerk


    Das SAT-IP Streaming läuft prinzipiell stabil, der Fehler "SID in PAT nicht gefunden" tritt nicht mehr auf. Danke


    Auf manchen Sendern habe ich in der Prime Time aber immer wieder Störungen / Klötzchen vorrangig bei Pro7 und RTL.
    (Ich vermute zu der Zeit verwenden die Sender eine höhere Datenrate.)


    Nachein wenig forschen, bin ich auf folgendes gestoßen.


    journalctl -f zeigt keine Auffälligkeiten
    top -d 0.2 zeigt keine Auffälligkeiten


    ethtool -S eth0
    rx_errors: 0
    tx_errors: 0
    rx_dropped: 0
    tx_dropped: 0
    rx_mtu_err: 0
    rbuf_ovflow_cnt: 0
    rbuf_err_cnt: 0
    mdf_err_cnt: 317
    alloc_rx_buff_failed: 0
    rx_dma_failed: 0
    tx_dma_failed: 0
    ...


    Der mdf_err_cnt steigt langsam aber kontinuierlich an.
    Eine Dokumentation zu dem mdf_err_cnt habe ich nicht gefunden.
    Hat jemand eine Idee?


    Oder an welcher Stelle kann ich weitere Untersuchungen anstellen?
    Danke

    Jetztist es wider passiert:

    Ich gehe mal zurück zur Version: Linux dm7080 3.4-3.0-dm7080 #10 SMP Mon Oct 27 11:10:27 UTC 2014 mips GNU/Linux
    Die lief bei mir über 2 Monate stabil

    Hallo,


    neuerdings, hängt meine DM7080 beim Booten.


    Im Log sieht man nach dem Abschnitt "checkTimerlist" noch folgendes

    Zitat

    [ 1753.503000] fp cmd 30 retry
    creating surface with pixel format 0x07e48888 (BPXL_eA8_R8_G8_B8)
    disable manual blit


    Ich habe mir mal einen früheren Log zum Vergleich rausgesucht:


    Nach der "checkTimerlist" folgt hier


    Per Telnet, FTP ist d ie Box ansprechbar, nur die GUI startet nicht.
    Nach vielen Neustart Versuchen, ist vielleicht mal einer dabei der erfolgreich bootet.


    Aber es hilft nur ein Neu Flashen, das funktioniert dann ein, zwei Wochen, dann hab ich wieder das gleiche Problem.


    Das Image ist auf dem neuesten Stand.


    Ich würde gerne mal mit DreamUp, die Bad Sectors markieren lassen.
    Aber DreamUp schein noch nicht dafür vorbereitet zu sein. Andere Ideen?


    Danke

    Ja, die entsprechende Thread ID hab ich auch lange gesucht.


    Hab hier auch schon alles versucht:
    currentThread(), _get_ident(), self.ident, os.getpid()


    Aus den OpenEmbedded Sourcen hab ich mir dann das hier abgeleitet:
    from ctypes import CDLL
    SYS_gettid = 4222
    libc = CDLL("libc.so.6")
    tid = libc.syscall(SYS_gettid)
    print "Thread id: " + tid


    Fehler nochmal nachgestellt:
    FATAL!: addTimer must be called from thread 5532 but is called from thread 7135


    MainThread ist 5532
    WorkerThread ist 7135


    Wir haben also definitif ein Problem in den Threads


    Aktuell liegt meine Vermutung bei ePythonMessagePump

    Hallo,


    mit einem der letzten Updates der DM7080HD hat sich ein Threading Fehler eingeschlichen bzw. es wird restriktiver geprüft.



    Im Code des SeriesPlugin wird hier keine Funktion addTimer verwendet.
    Meine Vermutung, es wird die C-Funktion des eTimers im falschen Thread aufgerufen.
    Aber ein Timer wird vom Plugin auch nicht verwendet.


    Für das Threading wird das Toolkit SimpleThread verwendet.



    Beim Netatmo Plugin scheint es, das gleiche Problem zu geben.



    Danke

    Hatte Ritzmo mal angeschrieben ob man den Autotimer nicht alternativ starten kann - ideal wäre natürlich wenn man im Autotimer ne Zeiteinstellung
    vornehmen könnte ...so vollkommen autark vom epg refresh

    Hi, der AutoTimer hat doch ein Aktualisierungsintervall, stell das doch einfach auf 12 Stunden, dann wird er 2 Mal am Tag gestartet.

    Hallo zusammen,
    ich hab mir das Thema mal angeschaut, brauche aber Support.


    Hier die Log File Auswertung:
    Der EPGRefresh startet
    [EPGRefresh] About to start refreshing EPG


    läuft sauber durch
    [EPGRefresh] Done refreshing EPG
    [EPGRefresh] Debug: Cleanup


    Jetzt kommen die Unterschiede, Ohne AutoTimer
    [EPGRefresh] Debug: Calling nextTodo
    [EPGRefresh] Debug: Call <bound method EPGRefresh._ToDoCallAutotimer of <Plugins.Extensions.EPGRefresh.EPGRefresh.EPGRefresh instance at 0x22778f0>>
    [EPGRefresh] Debug: Calling nextTodo
    [EPGRefresh] Debug: Call <bound method EPGRefresh._ToDoAutotimerCalled of <Plugins.Extensions.EPGRefresh.EPGRefresh.EPGRefresh instance at 0x22778f0>>
    [EPGRefresh] Debug: Calling nextTodo
    [EPGRefresh] Debug: Call <bound method EPGRefresh._callFinishNotifiers of <Plugins.Extensions.EPGRefresh.EPGRefresh.EPGRefresh instance at 0x22778f0>>
    [EPGRefresh] Debug: Calling nextTodo
    [EPGRefresh] Debug: Call <bound method EPGRefresh.finish of <Plugins.Extensions.EPGRefresh.EPGRefresh.EPGRefresh instance at 0x22778f0>>
    [EPGRefresh] Debug: Refresh finished!
    RemovePopup, id = EpgRefreshEndNotificationId
    AddPopup, id = EpgRefreshEndNotificationId domain = EPGRefresh
    AddPopup, id = EpgRefreshEndNotificationId domain = EPGRefresh
    [EPGRefresh] Debug: Calling nextTodo
    [EPGRefreshTimer] next real activation is Tue Oct 28 07:00:01 2014
    [NotificationQueue::popNotification] domain EPGRefresh deferred_callable: True
    Alles in Ordnung


    Jetzt mit AutoTimer
    [EPGRefresh] Debug: Calling nextTodo
    [EPGRefresh] Debug: Call <bound method EPGRefresh._ToDoCallAutotimer of <Plugins.Extensions.EPGRefresh.EPGRefresh.EPGRefresh instance at 0x22778f0>>
    [EPGRefresh] Debug: Call AutoTimer: True
    [EPGRefreshTimer] next real activation is Tue Oct 28 07:00:01 2014


    hier wird der der AutoTimer gestartet
    autotimer.parseEPGAsync(simulateOnly=False).addCallback(self._nextTodo).add
    Errback(self._autotimerErrback)


    Aber _nextTodo bzw _autotimerErrback wird nie aufgerufen, stattdessen sieht man im Log nur:
    WARNING removeSocketNotifier should be called from thread 162 but is called from thread 382



    Entweder der AutoTimer crashed aus irgendeinem Grund oder es gibt einen TimeOut.
    In dem Fall würde ich aber diese Meldung erwarten.
    "Reactor no longer active, aborting."


    Jetzt die Frage, wie kommt es zu dem "removeSocketNotifier"

    Hallo,


    seid dem Update:


    Mon, 25 Mar 2013 23:03:21
    - fixed a small MPEG4 ASP playback bug (xvid, divx, ...)


    laufen die OTR HQ Files geringfügig besser, leider ist das ruckeln noch immer sehr störend.


    Gruß betonme

    Hallo,


    ich wollte das Thema hier mal wieder antriggern.


    Jetzt da es ein OTR Plugin gibt, wäre es super die OTR HQ Files direkt als Stream abspielen zu können.


    Ein Sample gibt es hier zum freien Download: OTR HQ
    http://www.onlinetvrecorder.com/v2/?go=samples



    Das Sample wurde hier schon mal analysiert:
    https://www.dream-multimedia-t…ad&postID=89191#post89191


    "...very highly compressed...It turned out that this was because the I-frames was very far apart, up to almost 10 seconds simetimes..."


    Vielen Dank schonmal