Aussetzer bei Aufnahme über NFS (DM8000, Qnap-NAS)

  • Hallo,


    Hat jemand schon das Problem lösen können?
    Ich habe ähnliche/gleiche Probleme.
    Leider konnte auch ich die Ursache noch nicht ausfindig machen.
    Bei meinen Aufnahmen fehlen oft, wenn nicht immer, immer wieder mal ein paar Minuten.
    Leider finde ich keine Ursache.


    Hier mein Setup:


    Aufnahmen gehen auf eine Synology DS1813+ mit Synology Hybrid RAID, Dateisystem ext4 (4 Festplatten), NFS Freigabe.
    Die Verbindung zu meiner Dreambox 8000 läuft über eine Fritbox 7390 -> WLAN -> Fritz Repeater -> Kabel -> CISCO SLM2008 8-Port Gigabit Smart Switch -> Kabel -> DM8000.
    Bisher hatte ich immer eine super Performance.


    Zur DM8000:
    Gerätebezeichnung: dm8000
    Enigma2 Version: 2014-02-19-tarball
    Image Version: Newnigma2 v4.0.9 2014-02-23
    Frontprozessor Version: V7
    Tuner A: BCM4506 (internal) (DVB-S2)
    Tuner B: BCM4506 (internal) (DVB-S2)
    Tuner C: Philips CU1216Mk3 (DVB-C)
    Tuner D: Philips CU1216Mk3 (DVB-C)



    Leider bin ich kein Profi. Von einigen dieser Beiträge oben verstehe ich nur BAHNHOF (leider).
    Doch vielleicht kann mir jemand helfen.
    Diese blöden Aussetzer nerven.
    Die bei einem Post beschriebenen auftauchenden Zahnräder habe ich auch schon bemerkt. Ich habe bereits auch alle Autotimer gestoppt, so das nur wenige Aufnahmen laufen, keine Besserung.


    Derzeit verwende ich ein OE2.0 System, früher (bei OE1.6) hatte ich keine Probleme.


    DANKE für jede Hilfe.


    Gruss
    IHA

  • Hi,


    hmm ich hatte die tage gelesen, dass es wohl bei einigen NAS einen an/abschaltbaren Write-Cache gibt, der default aus ist.


    Da würde ich mal in den Menüs des NAS schauen, ob es da was gibt, und ob es angeschaltet ist... wenn nicht dann mal anschalten.


    Seit OE2 und damit dem Kernel 3.2 wird in enigma2 "Direct I/O" beim schreiben der Aufnahmen verwendet.


    Sprich der Pagecache des Linux Kernels wird umgangen, weil die neueren Kernel leider deutlich größere Probleme mit wenig RAM haben
    als der alte 2.6.18 Kernel gemacht hatte. Wobei es da auch mit dem alten Kernel bei wenig RAM schon Probleme gab.


    cya

  • Zitat

    Original von nokia2
    Seit OE2 und damit dem Kernel 3.2 wird in enigma2 "Direct I/O" beim schreiben der Aufnahmen verwendet.


    Sprich der Pagecache des Linux Kernels wird umgangen

    Ah, ok. Danke für die Infos, das wäre als Ursache wirklich sehr plausibel.
    Gibt es denn eine Möglichkeit unter OE2.0 auf das vorherige Verfahren mit Cache-Nutzung zurückzukehren, oder wäre dafür ein Downgrade auf OE1.6 die einzige Möglichkeit?
    (Notfalls würde ich das auch machen - so riesig sind die Vorteile von OE.2.0 auch wieder nicht...)


    Zitat

    Original von nokia2
    hmm ich hatte die tage gelesen, dass es wohl bei einigen NAS einen an/abschaltbaren Write-Cache gibt, der default aus ist.

    Ja, kann sein, dass es da was gibt. Werd ich demnächst mal anschauen.



    iha: Bei dir käme eventuell noch WLAN als zusätzliche Fehlerquelle in Frage. Ansonsten: Interessant, dass du das Problem mit einem Synology hast. Das ist zumindest schon mal ein Indiz, dass es vielleicht doch nicht nur daran liegt, dass Qnap Mist gebaut hat.^^

  • Sind deine HDD's in der Kompatibilitätsliste der QNAP gelistet? Wenn nicht - dann hast du dort das Problem!


    Wenn 4k HDD's, sind die richtig aligned?

  • In der Kompatibilitätsliste stehen sie. Wenn es denn tatsächlich an den HDDs liegen sollte, könnte es höchstens noch damit zusammenhängen, dass es nicht 5 gleiche, sondern unterschiedliche sind (neue, größere, die dann auch alles gleich sind, werde ich demnächst anschaffen. Das ist die nächste Investition. Am Anfang war das im Budget leider nicht mehr drin. Das NAS alleine ist ja schon sau teuer...)


    Ob sie richtig aligned sind? Ich habe von den Festplatten, bevor ich sie ins NAS eingebaut habe, sämtliche Partitionen gelöscht, sie also in Auslieferungszustand versetzt und anschließend das Partitionieren / Formatieren dem NAS überlassen. Ob die Qnap-Software dabei korrekt vorgegangen ist, kann ich so nicht nachprüfen (wüsste auch gar nicht wie), aber ich gehe mal stark davon aus, dass Qnap das korrekt implementiert haben wird.



    Wie dem auch sei, bin ich stark dafür, zu versuchen, von dem vom nokia2 angesprochenen Direct I/O wegzukommen. Komplett auf einen Cache zu verzichten scheint mir allgemein eine sehr riskante Lösung zu sein - egal, wie perfekt das NAS auch konfiguriert sein mag, kann es doch eigentlich immer vorkommen, dass es mal winzige Verzögerungen gibt. Spätestens dann, wenn zufällig gleichzeitig jemand vom PC aus große Datenmengen aufs NAS verschiebt und es damit auslastet.

  • Ich hatte die selben Probleme wie du beschreibst mit einer WD green in der qnap als die ~80% voll war.
    Die besten Werte beim schreiben und lesen aber andauernd Bildfehler bei der aufnahme.
    Wenn kein RAID hast, Versuchs eventuell mit einer anderen HDD ...

  • Hi,


    es hat niemand geschrieben, dass gar nicht mehr gecached wird. Nur der interne Cache des Linux Kernels wird nicht mehr verwendet. Weil das eben viele Probleme gemacht hatte. Da gabs mega Probleme in den Aufnahmen Anfangs im OE2... sogar auf internen Festplatten.


    Enigma2 selber cached aber je Aufnahme bis zu 12MB.. was schon einiges ist. Wenn das auf dauer nicht ausreicht, dann muss schon durchgehend das Netzwerk zu langsam sein.


    Wie gesagt.. ich würde mal schauen, ob es am NAS noch einen anschaltbaren Write-Cache gibt oder irgendwas, was das schreiben schneller machen könnte.


    Tritt das Problem denn durchgehend auf? Oder z.b. erst nach langer Laufzeit der Dreambox.


    Schonal ein Logfile angefertigt? Also wenn der enigma2 interne Buffer überlauft wird man das im Logfile auf jedenfall lesen können.


    cu

  • Hallo!
    Da kann ich mich ja gleich mit einklinken ....


    Bei mir ebenfalls starke ruckel Probleme


    Aber erst seit Umstieg von qnap ts-119p+ auf synology ds-214+ :face_with_rolling_eyes:


    Nach dem Umstieg haben alle mein Netzwerk als Problem in verdacht gehabt.
    Pustekuchen
    Habe sämtliche Komponenten ausgetauscht
    Alle festen Leitungen durch lose Überbrückt
    Sämtliche Parameter in der Auto.network Datei eingetragen und getestet


    Wobei der Fehler NUR bei meiner 800se V2 aufgetreten ist und nicht bei meiner 500 HD V1 :face_with_rolling_eyes:


    Oft ist der Fehler sogar schon beim Abspielen einer HD Aufnahme und gleichzeitige Aufnahme passiert


    Im dmm Forum wurde mir sogar geraten mir eine interne HDD wieder einzubauen damit ich diese Probleme nicht habe :face_with_rolling_eyes: :zensiert:


    Super Problemlösung


    Ein Glück hatte ich noch die qnap 119p+ neueste FW


    Damit läuft es nach wie vor perfekt!


    Da ich durch die synology aber von der Geschwindigkeit verwöhnt war und die synology nicht mit der 800se V2 ging hab ich die mit Verlust verkauft und nun eine qnap ts-269L bestellt !


    Hoffentlich gehts mit der auch!


    Echt shice die synology hatte das bessere Preis Leistungsfähig Verhältnis ..


    User nillebor hat auch festgestellt das


    Irgend was an den V2 boxen im LAN anders ist siehe Vergleich hier :


    Hallo!



    anbei die Werte aus dem nfs speedtest mit der qnap ts-119p+



    qnap ts-119p+


    Results for write throughput:
    89.478 Mbit/s with udp,async,wsize=8192
    89.478 Mbit/s with udp,async,wsize=4096
    89.478 Mbit/s with udp,async,wsize=32768
    89.478 Mbit/s with udp,async,wsize=16384
    89.478 Mbit/s with tcp,async,wsize=8192
    89.478 Mbit/s with tcp,async,wsize=32768
    89.478 Mbit/s with tcp,async,wsize=16384
    76.695 Mbit/s with tcp,async,wsize=4096


    Results for read throughput:
    89.478 Mbit/s with tcp,async,rsize=8192
    89.478 Mbit/s with tcp,async,rsize=4096
    89.478 Mbit/s with tcp,async,rsize=32768
    89.478 Mbit/s with tcp,async,rsize=16384
    21.474 Mbit/s with udp,async,rsize=32768
    21.474 Mbit/s with udp,async,rsize=16384
    20.648 Mbit/s with udp,async,rsize=8192
    19.884 Mbit/s with udp,async,rsize=4096


    mit synology ds-214+


    komische werte beim lesen...


    Results for write throughput:
    89.478 Mbit/s with udp,async,wsize=32768
    89.478 Mbit/s with udp,async,wsize=16384
    76.695 Mbit/s with udp,async,wsize=8192
    76.695 Mbit/s with tcp,async,wsize=8192
    76.695 Mbit/s with tcp,async,wsize=4096
    76.695 Mbit/s with tcp,async,wsize=32768
    76.695 Mbit/s with tcp,async,wsize=16384
    53.687 Mbit/s with udp,async,wsize=4096


    Results for read throughput:
    536.870 Mbit/s with udp,async,rsize=32768
    536.870 Mbit/s with tcp,async,rsize=4096
    107.374 Mbit/s with tcp,async,rsize=16384
    with udp,async,rsize=4096
    with udp,async,rsize=8192
    with udp,async,rsize=16384
    with tcp,async,rsize=8192
    with tcp,async,rsize=32768




    Melde mich mal ob es mit der qnap ts-269L geht


    JonnyDreambox

    ______
    DM800SE V2 S-(C-sundtek)
    DM500HD C-(C-sundtek)
    oe 2.0 MERLIN
    Synology ds-214Play
    FB7490
    MacBookPro16gb Ram
    ATV2
    iPhone6
    Panasonic TX-P55VT50e

  • Zitat

    Original von nokia2
    es hat niemand geschrieben, dass gar nicht mehr gecached wird. Nur der interne Cache des Linux Kernels wird nicht mehr verwendet.

    Ah, ok. Explizit geschrieben hat es niemand, nur dachte ich genau das sei die Definition von "Direct I/O". Wenn es dann doch einen Cache gibt, hab ich das wohl falsch verstanden.^^


    Zitat

    Tritt das Problem denn durchgehend auf? Oder z.b. erst nach langer Laufzeit der Dreambox.

    Das Problem ist unabhängig von der Laufzeit (sowohl bezogen auf die Dreambox, als auch aufs NAS).


    Zitat

    Schonal ein Logfile angefertigt?

    Noch nicht. Hast aber recht, sollte ich mal versuchen.

  • Hallo!



    Habe jetzt mein synology ds-214+ verkauft und mir ein qnap ts-269L gekauft!
    In der Hoffnung das das ruckeln weg ist , da es ja auf meiner qnap ts-119p+ auch läuft!


    Nun was soll ich sagen,
    Jetzt hab ich die qnap 269L und genau das gleiche Problem, aber wie vorher auch NUR mit der 800se V2 !
    Hat sich nichts geändert zur synology, ausser meine qnap 119p+ da mag die dm800se v2 alles,mit der läuft es!


    jetzt kann es nur noch an der 800se V2 liegen ,mag gar nicht vermuten das es evtl. an allen V2 (bzw. Boxen mit mehr Speicher) liegt!


    Könnte Kotzxx :zensiert:


    gruß


    JonnyDreambox

    ______
    DM800SE V2 S-(C-sundtek)
    DM500HD C-(C-sundtek)
    oe 2.0 MERLIN
    Synology ds-214Play
    FB7490
    MacBookPro16gb Ram
    ATV2
    iPhone6
    Panasonic TX-P55VT50e

  • Synology DS213j und dm800sev2, funktionieren hier einwandfrei.
    Hier ruckelt nix, bei 10-11 MB/s und Standardeinstellungen.

  • Hallo!


    habe mal was ausprobiert zu loggen während der Fehler ,
    könnt ihr da was sehen ?


    Ganzes log anbei


    auszug:
    Apr 5 13:37:22 dm800sev2 user.warn kernel: [147936.851000] audio_cdb_itb_error_isr: 14 callbacks suppressed
    Apr 5 13:37:22 dm800sev2 user.warn kernel: [147936.851000] audio_cdb_itb_error_isr! underflow
    Apr 5 13:37:22 dm800sev2 user.warn kernel: [147936.883000] audio_cdb_itb_error_isr! underflow
    Apr 5 13:37:22 dm800sev2 user.warn kernel: [147936.915000] audio_cdb_itb_error_isr! underflow
    Apr 5 13:37:22 dm800sev2 user.warn kernel: [147936.947000] audio_cdb_itb_error_isr! underflow
    Apr 5 13:37:22 dm800sev2 user.warn kernel: [147936.976000] RAP pts error 0 PTS 0x54fe7c6f, STC 0x54fef28c, type 1
    Apr 5 13:37:22 dm800sev2 user.warn kernel: [147936.976000] RAP pts error 0 PTS 0x54fe820f, STC 0x54fe70b6, type 0
    Apr 5 13:37:22 dm800sev2 user.warn kernel: [147936.979000] audio_cdb_itb_error_isr! underflow



    edit:
    Jetzt das aktuelle originale image drauf
    nur die auto.network eingesetzt
    nichts anderes, keine cams plugins nix!


    Fehler bleibt!




    Habe Dabei wirklich ALLES getauscht von Router zu Kabel und sogar 2 Unterschiedliche NAS gekauft!




    hab keine Langeweile aber langsam besseres zu tun,


    Das kann es nicht sein, nehme seit dbox zeiten auf , noch nie Probleme gehabt ......


    Andere haben die Probleme wohl auch schon und nillebor konnte es mit V2 Boxen auch schon rekonstruieren .....



    JonnyDreambox


    ps.



    sonst gebe ich auf verkaufe meine qnap 269L auch wieder , und hole mir ne ganz andere box


    Mir kommt es echt so vor als ob man den Fehler nicht ernst nimmt......


    danke :wacko:

  • So, jetzt hab ich mal Zeit zum Testen und das erste, was ich probiere geht natürlich gleich nicht. :frowning_face:
    Wollte tcpdump aus dem Beitrag von ABPSoft installieren.


    Code
    root@dm8000:~# opkg install /tmp/tcpdump_4.1.1-r1_mips32el.ipk                 
    Installing tcpdump (4.1.1-r1) to root...                                       
    Collected errors:                                                              
     * opkg_install_pkg: Package tcpdump md5sum mismatch. Either the opkg or the pakage index are corrupt. Try 'opkg update'.                                     
     * opkg_install_cmd: Cannot install package tcpdump.


    Vorher opkg update eingeben hab ich natürlich probiert, ändert aber nichts. Nochmal neu runtergeladen, um Fehler beim Download auszuschließen, hab ich es auch schon.
    Stell ich mich grad zu doof an, oder ist das Paket tatsächlich fehlerhaft? Hat jemand ein funktionierendes tcpdump oder einen Tipp, wie ich das installiert bekomme? Danke.

  • Mal sehen was bei tcp dump rauskommt!
    Ich meinerseits habe das Problem mit einer Vu+solo 2 gelöst,


    Seit dem noch eine menge Reserve was das Netzwerk betrifft :hurra:



    Schöne Ostern

    ______
    DM800SE V2 S-(C-sundtek)
    DM500HD C-(C-sundtek)
    oe 2.0 MERLIN
    Synology ds-214Play
    FB7490
    MacBookPro16gb Ram
    ATV2
    iPhone6
    Panasonic TX-P55VT50e

  • Zitat

    Originally posted by netman
    Das kann man doch einfach über den Feed laden:


    Nicht bei jedem Image (sonst hätte ich mir das Bauen natürlich gespart :winking_face:
    Bei DMM allerdings schon, und das führt dann auch zu dem "Problem": Mein Build hat nicht den Hash, den der von DMM hat, aber exakt die selbe Version. Da weigert sich opkg legitim, das zu installieren, könnte ja kompromittiert sein.

    Zitat

    opkg update && opkg install tcpdump


    Yep, sollte dann reichen. Ich detache dann hier mal das Attachment, da sich das jeder auch aktuell bei DMM ziehen kann, selbst wenn er nicht ohnehin an deren Feed hängt.


    Sorry für den Trubel,
    Andre.

  • Also tcpdump konnte ich nun zwar installieren, funktionieren tut es aber trotzdem nicht. Kommt immer nur:

    Code
    tcpdump: Can't open netlink socket 120:Protocol not supported


    Ich vermute aber mal, dass das sowieso gar nicht nötig ist. Ich habe nun gemäß dieser Anleitung mal ein Logfile erstellt und konnte da tatsächlich ein paar interessante Fehler protokollieren, die hoffentlich mehr Aufschluss über die Ursache geben sollten. :)
    Ich habe da etwas aufgenommen und in der Aufnahme fehlt ein Stück zwischen 17:23 und 17:26 (hab extra Phoenix aufgenommen, weil die eine Zeitanzeige im Bild haben und kann schön beobachten, wie das Bild unvermittelt 3 Min. vorspringt. Das ganze noch kombiniert mit ein paar Freezern davor und danach.)


    Und hier die Logdaten, die die Dreambox während der Aufnahme zu dieser Zeit protokolliert hat:


    Im Anhang noch das komplette Logfile

  • Hi,


    Im Logfile sieht man, dass der enigma2 interne Schreibcache volläuft, was heisst, dass über einen längeren Zeitraum die Daten nicht schnell genug geschrieben werden können.


    Es gibt im QNAP eine Option Schreibcache aktivieren wenn die interne Festplatte mit EXT4 formatiert ist.


    Aktiviere diese mal. Das sollte einiges bringen.


    cu

  • Ok, das habe ich nun mal gemacht. Mal abwarten, ob es was bringt.


    Gibts eigentlich noch eine Möglichkeit, den enigma2 interne Schreibcache zu vergrößern?!
    Ich hatte als ersten Lösungsansatz vor einiger Zeit mal ein Swap-File auf einer CF-Karte angelegt, in der Hoffnung damit für etwas mehr Puffer zu sorgen. Das scheint dafür aber nicht genutzt zu werden. :confused_face:

  • Update: Das Aktivieren des Schreibcaches am Qnap hat nichts gebracht. Bekomme nach wie vor die gleichen Fehlermeldungen. :frowning_face: