Fehlermeldung "Zieldatenträgerlaufwerk zu langsam" unter EDIUS 4.54

1. offizieller Beitrag

    Hallo,




    seitdem ich EDIUS auf die 4.54er Version geupdated habe kommt beim Capturen gelegentlich bis regelmäßig die Fehlermeldung "Zieldatenträgerlaufwerk zu langsam".




    Was mich daran wundert ist, dass auf dem 2-TB-Hitachi-HDD-RAID-0-Video-Verbund


    - der gesamte PC rundherum optimiert war (CHKDSK durchgeführt, Fehlerbereinigung durchgeführt, Registry gesäubert, System-Partition defragmentiert, System virengecheckt etc.)


    - noch über 50 % HDD-Space beim RAID-0-HDD-Verbund vorhanden ist


    - die Fragmentierungsrate beim RAID-0-HDD-Verbund lediglich 9,75 % betrug (mittels O & O Defrag 10 Pro ermittelt)


    - die durchschnittliche Transferrate beim RAID-0-HDD-Verbund 95,4 MB/sec betrug (Max.: 100,3 MB/sec; Min.: 81,2 MB/sec) (mittels HDD Tune 2.53 ermittlet)




    Diese Fehermeldung bekam ich drei Male hintereinander beim Einlesen eines SONY-PHDVM-63DM-Tapes (1440x1080-50i-Material) mittels eines SONY-HVR-M15-Recorders (1. nach 33 Min. 2. nach 47 Min., 3. nach ? Min.)


    Ein anschließendes Capturen auf ein Nicht-RAID-HDD-Laufwerk mit geringeren Transferraten (Average: 63,2 MB/sec) gelang auf Anhieb.




    Was mich nun wundert ist, dass ich diese Fehlermeldung nie vor der 4.54er Version bei ansonsten gleicher Hard- und Software-Konfiguration auf den Bildschirm bekam.




    Nun habe ich die Video-RAID-HDD einmal schweren Herzens defragmentiert. Die ermittelten Transferraten-Werte sind dabei nahezu identisch mit denen vor der Defragmentierung festgestellten bzw. sogar 0,2 MB/sec, nämlich durchschnittlich 95,2 MB/sec., geringer. Der Fragmentierungsgrad beträgt nun 0,00 % (vorher: 9,75 %).


    Ein anschließend durchgeführtes Capturing unter ansonsten gleichen Hardwarebedindungen brachte nun ein positives Ergebnis und es lag kein Capturing-Abbruch vor.




    Wie ist solch ein Verhalten zu verstehen? Es kann doch nicht Sinn der Sache sein, dass man ein Video-HDD-Laufwerk regelmäßig defragmentiert. Vorher - und damit vor EDIUS 4.54 -hatte ich dies jedenfalls nie getan und EDIUS lief stets anstandslos. Was kann der Canopus-Support dazu sagen?

    Zitat von Louca

    Hallo,
    Vorher - und damit vor EDIUS 4.54 -hatte ich dies jedenfalls nie getan und EDIUS lief stets anstandslos.


    Vielleicht ist das schon des Rätsels Lösung. Irgendwann ist der Fragmentierungsgrad überschritten. Das war anscheinend in diesem Fall so.


    Manche Programme kommen auch mit einem Schreibcache nicht klar, der soweit mir bekannt, standardmäßig im Auslieferungszustand aktiviert ist. Das undurchsichtige bei der Digitaltechnik ist nun mal, daß Störungen sich weniger ankündigen als bei Analogtechnik. Dort kann man ggf. z.B. ein lauterwerdendes Rauschen "hören". Im digitalen funktioniert es nur oder auch nicht.

    Gruß
    Homer


    Canon EOS 600D, GoPro Hero 3 Black Edition, Canon HF 100, DaVinci Resolve 9, Production CS5

    Hallo Marcus,




    das




    Zitat

    Vielleicht ist das schon des Rätsels Lösung. Irgendwann ist der Fragmentierungsgrad überschritten.






    habe ich mir auch schon durch den Kopf gehen lassen. Was mich dabei allerdings zutiefst wundert ist, dass die Datentransferraten nach der Defragmentierung geringfügig niedriger ausfielen als vorher, zumal ja die Fehlermeldung lautete "Zieldatenträgerlaufwerk zu langsam" und es damit dann auf Anhieb funktionierte.




    Hat schon einmal jemand diese EDIUS-Fehlermeldung auf den Schirm bekommen? Bei Letzterem würde mich insbes. einmal die Ansicht des Canopus-Support interessieren.


    Wie interpretiert EDIUS denn ein "zu langsam"? In Transferratenkapazität(en) pro Zeiteinheit(en) oder welche Parameter spielen hierbei noch eine (mit)entscheidene Rolle?


    Danke!!

    Gruß :thumbup:


    Louca




    P. S.: Ich muß mich bei dem Streß hier jetzt aber wirklich auch einmal um's leibliche Wohl kümmern...




    "Sollten Ihnen meine Aussagen zu klar gewesen sein, dann müssen Sie mich missverstanden haben" (Alan Greenspan)

    Den Fehler hatte ich auch schon einmal auf meinem 2xDual Opteron. Mag am Chipsatz gelegen haben oder daran, daß ich die OS-Platte zum Digitalisieren benutzt hatte. Dann hatte ich mal ein, zwei PCI-Karten aus dem Opteron ausgebaut und es funktionierte auf einmal besser. Auch die Abstürze, die ich mit den Platten im Opteron hatte, sind beim Core2Duo und Quad verschwunden. Inzwischen ohne viele PCI-Karten arbeitet der Opteron im Musikbereich anstandslos. Ich denke irgendwas hat sich darin zusammen nicht vertragen. Das fatale an den Abstürzen war, daß jeder weitere Absturz noch mehr Datenmüll auf den Festplatten hinterlassen hat und das System bis zum Neuaufsetzen immer instabiler wurde.


    Inzwischen habe ich ein von Canopus empfohlendes System Asus Deluxe DH Board, welches mit Core2Duo 6600 keinerlei Probleme machte und jetzt mit Core2Quad6600 ebenso stabil, aber noch schneller bei mehreren Prozessen arbeitet.

    Gruß
    Homer


    Canon EOS 600D, GoPro Hero 3 Black Edition, Canon HF 100, DaVinci Resolve 9, Production CS5

    Ich sehe gerade, daß du dein System ganz schön übertaktest. Könnte der Bus vielleicht darunter leiden? Hast du mal mit normaler Taktung probiert, ob die Platten dann immernoch Probleme machen ? Bei manchen Platten/Controllern machen falsche Kombinationen (SATA 150 und SATA 300) Probleme, wo dann empfohlen wird alles auf SATA150 zu betreiben. Das kann man an der Festplatte, wenn es eine zu "schnelle" ist jumpern. Jeder Kommunikationsfehler sorgt dafür, daß Daten erneut angefordert werden, was im Extremfall das System ausbremsen kann.

    Gruß
    Homer


    Canon EOS 600D, GoPro Hero 3 Black Edition, Canon HF 100, DaVinci Resolve 9, Production CS5

    Hallo Marcus,




    Zitat

    Hast du mal mit normaler Taktung probiert




    die Übertaktung wende ich nur gelegentlich an (Transcodieren u. dgl. CPU-intensive Anwendungen). Bei diesem von mir beschriebenen "Phänomen" lief alles bei 2400 MHz. Allerdings habe ich mit dem Rechner in seiner beschriebenen Konfiguration weder im normalen, noch im übertakteten Zustand, jemals einen Absturz (Blue Scree od. dgl.) erlebt.

    Gruß :thumbup:


    Louca




    P. S.: Ich muß mich bei dem Streß hier jetzt aber wirklich auch einmal um's leibliche Wohl kümmern...




    "Sollten Ihnen meine Aussagen zu klar gewesen sein, dann müssen Sie mich missverstanden haben" (Alan Greenspan)

    Moin,
    glaube ich nicht. Habe seit drei Jahren ein Windows Stripset und kenne diese Meldung nur von Single Platten, wenn auch sehr, sehr sporadisch.

    Hallo Arndt,


    Zitat


    könnte es sein, daß das raid0 ein software-raid ist? wenn ja, dann hast du ziemlich sicher die erklärung für das problem.



    Nein, nein... ich nutze das Mainboard-RAID.




    http://www.technic3d.com/artic…-review-auf-technic3d.htm

    Gruß :thumbup:


    Louca




    P. S.: Ich muß mich bei dem Streß hier jetzt aber wirklich auch einmal um's leibliche Wohl kümmern...




    "Sollten Ihnen meine Aussagen zu klar gewesen sein, dann müssen Sie mich missverstanden haben" (Alan Greenspan)

    Louca,


    ich habe auch so merkwürdige Sachen seit 4.54 auf meinem 8 Core Raid System.
    Ich wollte gestern nur mal einen DV(nicht HDV)!!! Clip aus Band schreiben und habe einmal die Fehlernachricht "PCI Bus überlastet" mit Abbruch bekommen und danach
    hat er mehrmals die Ausgabe auf Band einfach beendet mit der Nachricht "Wiedergabe beendet".


    Ich habe dann für die gleiche Tätigkeit mein log. 4 Core RAID System und als Recorder die Kamera genommen und da hat es mit 4.54 funktioniert.


    Seltsam ?

    Gruss
    Jürgen
    _______________________________________________________________________________________________________________________
    Triple Boot:Win10 Pro/I7-5930K/GTX 780/SSD-RAID/Intel X550 10GbE/BMD 4K Extreme 6G/32 GB RAM/

    Triple Boot:Win10 Pro/I7-6950X/GTX 1080/SSD-RAID/HDD-RAID/BMD 4K Extreme 12G/2 x 10GbE/64 GB RAM

    both on:10Gbps Media sharing Network, 10Gbps NAS

    you are not alone............engish + login erforderlich


    13 Things to Try if you get "Disk too Slow"
    http://ediusforum.grassvalley.…hlight=hard+disk+too+slow


    Edius 4.5 disc too slow error message
    http://ediusforum.grassvalley.…hlight=hard+disk+too+slow


    HDV Capture Issues
    http://ediusforum.grassvalley.…hlight=hard+disk+too+slow


    .....ich erinnere mich an mehr "topics", obige sind nur Jene, welche auf die Schnelle zu finden waren....


    es hat scheints nicht nur direkt mit den Platten selbst zu tun,
    scheints gleiche Meldung, wenn der kontiunierliche Datenstrom zur Platte durch was immer unterbrochen\beeinträchtigt wird


    manchmal hilft scheints auch abgeschalten der"autom. speichern Funktion" .... zumindest zum Eingrenzen.......


    freundliche Grüße vom ViennaLowLevelService ... old Hans ;)

    Zitat


    Seltsam ?



    Das ging auch mir durch den Schädel, Jürgen. Und da dachte ich, der dtsch. Canopus-Support könnte zum neuen Jahr vielleicht ein wenig Licht in dieses Dilemma bringen, auf dass ein User nachvollziehen kann, was da geschieht. An meiner Hardware kann das o. g. Dilemma mit den Transferraten ja eigentlich nicht liegen - insbesondere, da es auf einer anderen HDD mit geringeren Datentransferraten dann ja anstandslos funktionierte.



    Danke auch in den "Wiener Wald" an Old Hans!!


    Zitat


    When capturing from DV in v4.5 I get the error meassge "disc too slow" and capture stops. Edius then has to be re-started before it will respond properly.
    The target disc is a 300Gb RAID 0 array so I can't see it being too slow.
    Any ideas or is this a known v4.5 bug with a workaround?


    Zitat


    I have two near identical PC's (one has the NX HD expansion card the other doesn't) and this has happened on both when I installed v4.5.
    I've rolled then both back to v4.23 and they capture fine now.


    Zitat


    Hi I also have this problem since updating to 4.51! Any other ideas?



    Zitat


    I have this problem as well. Was capturing from NX Bay Composite-S from a VHS tape when the record window froze and the player window was sort of flickering. Error message was "drive too slow". Edius appeared to be locked up. Rebooted and it seemed to work. I was capturing to a 250Gb SATA drive of which almost all of the space was free. This started happening with upgrade to 4.51c.



    Zitat


    I've had this a couple of times when starting capture. Turning off edius and restarting it has sorted it both times. I also have a raid 0 set up.





    Zitat


    Premiere seems to be capturing the same tapes just fine.


    I'm also on NX PCIe - firewire capture - NTSC DV 4:3 - 2 drive SATA Raid 0 - scene detection on


    This error has only occurred with 4.5x builds for me. After reporting the error, Edius is sluggish and can't communicate with the deck or display Overlay of the video in the player window. Restart/Reboot didn't help.



    Zitat


    The reply I got from the UK impoters was "try v4.52 and see if that works" which is not really what I expected, or was lead to believe at the Mnachester roadshow at which I was told Holden were going to be investing in full time support people, but something I will try once the current project is signed off.
    Other than that its pretty obvious to me, based on the replies to this thread, that there is a problem.
    I notice that GV have kept well out of it, probably so they can maintain the "we are not aware of any such error message" line of reply.


    I too am getting the drive to slow error on 4.5 with update using NX pciE. Any ideas please. I have raid drive also. Thanks



    Zitat


    Welcome to the club.



    Zitat


    I've had this error also. But only in firewire mode, not with analog in. Try changing to S-VHS capture, then back to firewire. Usually that will stop the error, at least it did for me. I changed firewire cables and tried a new fully scanned harddrive, and sometimes I still get the error.


    Zitat

    I have the same problem with edius 4.52.I can only capture with mpeg capture.



    Zitat


    Me too. Also have this problem.







    Zitat


    Hello All, well add me the the slow disk club. I just upgraded from 3.6 to the current 454. was capturing thru a Storm2 to an Ext Seagate 750 SATA ( I've got 2 hooked up). kept getting the error and noticed the counter said I only had about 55:00 of capture time left. it would go for a minute or so then dump. cleared some footage off and still no joy.





    Dann habe ich "zum Glück" noch diesen Advise gefunden...


    Zitat


    SRsupport
    Senior Member
    You can use dv capture .



    ... und möchte es einmal ausprobieren mit dem RAID-0-HDD-Video-Verbund. Das wiederum macht aber ja erst dann einen tieferen Sinn, wenn das Problem wieder einmal "akut" ist. Aber was heißt hier schon "You can use..."? Ich wollte mich ja mit der angeschafften EDIUS-Plattform nicht gerade freiwillig wieder ins DV-Storm-Zeitalter zurückbeamen lassen. Insofern erlaube ich mir einmal an dieser Stelle die Frage, welche Rückschlüsse man ziehen kann bzw. können wird, wenn sich herausstellen sollte, dass bei ein und dem selben Tape per EDIUS-4.54-Capturing das Problem (weiterhin) besteht und bei DV Capture zur gleichen Zeit eben nicht?!?


    Nun habe ich mich noch einmal eines Canopus-eigenen Datentransferraten-Tools bedient und zwar des DVStorm Environment Checkers in der Version 2.00 vom 10.09.2002 (s. Anlage 1), das auch auf einer EDIUS-Plattform lauffähig ist. Auch hierbei liegt die Transferrate der NICHT-Raid-HDD (D:\ 16 MB Cache) geringer als die des RAID-0-HDD-Verbundes (E:\ je 32 MB Cache), wie eingangs auch schon mittels HDD Tune aufgezeigt. Insofern verwunderte mich der Inhalt der o. g. EDIUS-Fehlermeldung ("Zieldatenträgerlaufwerk zu langsam") schon, zumal es nicht logisch zu interpretieren ist, warum auf einem Laufwerk mit geringerer Datentransferrate das Capturing ohne Reboot anstandslos funktioniert(e), wohingegen es auf einem RAID-System mit analoger höherer Datentransferrate nicht klappt(e).


    Ich habe nun den Video-HDD-RAID-0-Verbund mittels O & O Defrag Pro 10 noch ein weiuteres Mal mit einer anderer Defragmentierungsmethode als beim ersten Defragmentieren bearbeitet - also defragmentiert - und die Datentransferraten des Video-HDD-RAID-0-Verbundes noch einmal - dieses Mal mittels HD_Speed Vers. 1.5.1.55 - sozusagen in einem Idle-Zustand (also ohne geladenes EDIUS, welches auf den HDD-Verbund E:\ zugreift od./u. dgl.) ermitteln lassen (s. Anlage 2). Hierbei habe ich jetzt zwar nur die Read(-Burst-Rate)-Werte genommen, da beim Write-Test der Festplatteninhalt überschrieben worden wäre, aber im SATA-Zeitalter sollte doch jegliche Win-XP-SP2-zertifizierte Video-Software in der Lage sein bei Transferraten jenseits der 100 MB/sec "kollegial" zusammenzuarbeiten.


    Ich habe die mittels HD-Speed gemessenen Werte noch einmal von HD Tach v. 3.0.4.0 bestätigen lassen (s. Anlage 3). Insofern fällt es - zumindest mir als technisch interessiertem Mensch und als Kunden, der ja auch einen monetären Gegenwert erbracht hat - schon ein wenig schwer Antworten wie




    einfach stillschweigend hinzunehmen.



    Hat der dtsch. Canopus-Support vielleicht irgendeinen Hinweis zur Hand, was das sein könnte bzw. was man dagegen effizient machen kann, außer das System in einen "prähistorischen" EDIUS-Zustand zurückzuversetzen? Danke sehr!!



    P.S.: Ich weiß, ich weiß... auch Ihr müßt erst einmal in 2008 ankommen - welcome back. Aber vielleicht klappt's dann ja nächste Woche... :thumbup:

    Aus " oversea" .. incl.US Support ........in zeitlicher Reihenfolge, mit Übersetzungsversuchen......







    freundliche Grüße vom ViennaLowLevelService ... old Hans ;)

    rein so aus dem Bauch heraus........in "remember of...."


    Was immer an der 4er bzw.4.5er anders\anspruchsvoller geworden ist, von der Auswirkung her, klingt alles ähnlich dem
    Ex-"PCI is to busy" von Canopus bzw. den entsprechenden Ex-Meldungen bei Avid oder Adobe.......
    War nicht von der NLE-Applikation abhängig.

    Meist in Zusammenhang mit den (Consumer) onboard Raid-Controller
    Hatte nichts mit der eigentlichen Plattengeschwindigkeit zu tun


    Asus_Boards waren darob gefürchtet ........
    weil immer alles was es gerade an "geilen Markting-Features" gab, aufs Consumerboard dazu draufgelötet wurde
    ohne Rücksicht ob dies auch alles bei gleichzeitigiger Aktivierung überhaupt noch vom Board bewältigbar ist.


    Raid-Controller verursachte an irgendeinem Datenknoten mit seiner hohen Priorität einen "Knopf"
    Raid-Controller deaktivieren >>Capture auf eine "normale", nicht mal all zu schnelle Platte ....Fehler weg


    Konflikt von Raid-Controller mit Firewire
    Raid-Controller + 1394er chip am selben Interrupt\Lane untrennbar verlötet,
    zusätzliches 1394er Karterl auf einen Steckplatz der nicht vom Raid-Controller belästigt wird ... Fehler weg



    freundliche Grüße vom ViennaLowLevelService ... old Hans ;)

    Hallo Louca und Hans,


    danke für die Clubmitgliedschaft.
    Ich hatte gedacht diese Fehler aus der Frühzeit des Video Editings gäbe es nicht mehr und deshalb die entsprechenden Beiträge im amerikanischen Forum überlesen.
    Kann sich nur um eine SW - Verschlimmbesserung in der Rel. 4.54 handeln.Ich hoffe mal das da bald ein Fix kommt.

    Gruss
    Jürgen
    _______________________________________________________________________________________________________________________
    Triple Boot:Win10 Pro/I7-5930K/GTX 780/SSD-RAID/Intel X550 10GbE/BMD 4K Extreme 6G/32 GB RAM/

    Triple Boot:Win10 Pro/I7-6950X/GTX 1080/SSD-RAID/HDD-RAID/BMD 4K Extreme 12G/2 x 10GbE/64 GB RAM

    both on:10Gbps Media sharing Network, 10Gbps NAS

    Hallo Old Hans,


    das


    Zitat


    Raid-Controller verursachte an irgendeinem Datenknoten mit seiner hohen Priorität einen "Knopf"
    Raid-Controller deaktivieren >>Capture auf eine "normale", nicht mal all zu schnelle Platte ....Fehler weg



    hört sich in meinen Augen sehr interessant an...


    Letzteres auch insofern, als dass ja das von mir eingesetzte GigaByte-Mainboard von Canopus für den HD-Schnitt offiziell freigegeben wurde:







    Hi Jürgen,


    dies


    Zitat


    Ich hoffe mal das da bald ein Fix kommt.



    wünsche auch ich mir nebst einem kleinen Kommentar vom dtsch. Distributor.



    Ist beispielsweise in Pegasus die gleiche Capturing-"Engine" implementiert wie in der EDIUS-Express-Hardware oder handelt es sich hier lediglich um ein Software-Problem?


    Zitat


    HQ Rekorder ist eine Capture-Anwendung, die speziell für Pegasus entwickelt wurde...


    Ich denke, dass die mit dem 4.5x-Update zusätzlich installierten Komponenten und Treiber für ihre Kommunikation mehr Pufferspeicher benötigen, als das 32-Bit-XP-System dafür seinerzeit bzw. bei EDIUS 4.0 reserviert hat(te). Könnte man einen etwaigen Speicherstandardwert im Registrierungs-Editor nicht vergrößern und ggf. mit welchen Parametern (DWORD-Wert-Kontextmenü-Änderung/-Ergänzung?)? :wacko:

    Gruß :thumbup:


    Louca




    P. S.: Ich muß mich bei dem Streß hier jetzt aber wirklich auch einmal um's leibliche Wohl kümmern...




    "Sollten Ihnen meine Aussagen zu klar gewesen sein, dann müssen Sie mich missverstanden haben" (Alan Greenspan)

    3 Mal editiert, zuletzt von Louca ()

    Hallo zusammen,


    ich hatte bisher zweimal diese Fehlermeldung, als ich über die ACEDVio Karte von meinem S-VHS Rekorder Filme in EDIUS eingespielt habe. Beide Filme hatten eine Laufzeit von ca. 100 min. Das für mich verblüffende war, das die Filme komplett augezeichnet wurden und erst am Ende der Filme, wenn vom Videorekorder kein durchgängiges Videosignal mehr kam, diese Fehlermeldung auftrat. Könnten evtl. fehlende und / oder zeitlich falsche Synchronsignale zu dieser Fehlermeldung führen?


    Gruß Werner

    Hallo Werner,


    interessante Hypothese!


    Zitat


    Könnten evtl. fehlende und / oder zeitlich falsche Synchronsignale zu dieser Fehlermeldung führen?



    1. Mit was für Hardware (welches S-VHS-Videorecorder-Modell?) hast Du zum Capturen verwendet?
    2. Welche Schnittstellen hast Du zum Capturen sowohl beim Recorder als auch beim PC in Anspruch genommen?
    3. Mit welcher EDIUS-Version arbeitest Du bzw. bei welcher ist der o. g. Fehler bei Dir aufgetreten?

    Gruß :thumbup:


    Louca




    P. S.: Ich muß mich bei dem Streß hier jetzt aber wirklich auch einmal um's leibliche Wohl kümmern...




    "Sollten Ihnen meine Aussagen zu klar gewesen sein, dann müssen Sie mich missverstanden haben" (Alan Greenspan)

    Hallo Louca,


    der Videorekorder ist ein JVC HR-S6611EU, angeschlossen über S-Video an die Karte ACEDVio, ebenso der Ton über Cinch-Kabel ebenfalls an die ACEDVio.


    Zur Zeit läuft EDIUS 4.54. Bei meiner letzten EDIUS-Version 3.62 gab es bei gleicher Konstellation keine Probleme.


    Gruß Werner

    Welchem Baujahr entspricht denn Dein JVC HR-S6611EU?

    Bilder

    Gruß :thumbup:


    Louca




    P. S.: Ich muß mich bei dem Streß hier jetzt aber wirklich auch einmal um's leibliche Wohl kümmern...




    "Sollten Ihnen meine Aussagen zu klar gewesen sein, dann müssen Sie mich missverstanden haben" (Alan Greenspan)