Infoseite // Ursache für ständige Abstürze Resolve 16.1.1 gefunden

Frage von AndySeeon:


Hallo Resolve- User,

ich arbeite seit Version 15 mit der Studio- Version von Resolve und bin damit glücklich und zufrieden gewesen. Abstürze sind selten, das System lief stabil.
Seit Anfang November hatte ich aber lästige Probleme mit meinem Resolve, was bis zur absoluten Unbrauchbarkeit führte. Kaum greife ich einen Clip, um ihn in die Timeline zu ziehen, friert Resolve ein. Wenn ich von der Media- Page zur Edit- Page wechsele, friert Resolve ein.

Solange ich in meinen letzten Projekt gearbeitet habe, trat das nur sporadisch auf. Seit einer Woche versuche ich ein neues Projekt zu erstellen, aber das ist fast unmöglich. Permanentes Einfrieren, Neustarten und wieder Einfrieren haben mich soweit frustriert, dass ich beinahe wieder das Adobe- Abo (mit Cyber-Monday-Angebot) abgeschlossen hätte :(

Ich habe Slashcam nach einem ähnlichen Problem durchsucht, aber nichts dazu gefunden.

Ich habe weiter alles mögliche versucht; Resolve komplett deinstalliert und von Version 15.0 an Version für Version neu installiert.
Ich habe vor lauter Verzweiflung mein Windows 10 neu installiert, Motherboard- Treiber und BIOS aktualisiert, nichts hat geholfen.
Dann habe ich das englische BM- Forum durchsucht, aber auch nicht gleich etwas für mein Problem hilfreiches gefunden.

Aaaaaber dann: habe ich zufällig eine kleine Anmerkung und einen Link zu einem Beitrag gefunden, der mein Problem auf einen Schlag gelöst hat:
https://forum.blackmagicdesign.com/view ... 1&t=102152

Grundsätzlich wird das Problem vom aktuellen NVIDIA- Studio- Treiber V441.x verursacht. Die Installation der letzten Version vom 4. September (V431.86) hat bei mir das Problem behoben. Die V441.xx funktionieren aktuell nicht mit BRAW.

Nun ist mir auch klar geworden, warum das alte Projekt noch ging; hier waren 70% der Clips *.mp4, 10% CDNG und nur 20% BRAW. Das aktuelle Projekt ist 100% BRAW.

Ich hoffe, ich kann mit dieser Info dem einen oder anderen hier die Verzweifelung ersparen, die ich erleiden musste, bis ich den Beitrag gefunden habe.

Erleichterte Grüße, AndySeeon



Antwort von mash_gh4:

ja -- wirklich nervig an diesen problemen is vor allen dingen der umstand, dass resolve bzw. die BMD programmierer fast durchgängig keine vernünftigen fehlermeldungen einbauen, mit denen man ein bisserl gezielter nach den ursachen auftretender probleme suchen könnte. so ist man dann ständig nur auf das herumraten angewisen, od. eben auf hinweise im netz, wo andere nach langem rumprobieren irgendwann doch eine erklärung od. gar lösung für entsprechendes fehlferhalten gefunden haben.



Antwort von dienstag_01:

Inwieweit hängt denn die Verarbeitung von BRAW vom Grafikkartentreiber ab?



Antwort von roki100:

dienstag_01 hat geschrieben:
Inwieweit hängt denn die Verarbeitung von BRAW vom Grafikkartentreiber ab? Wahrscheinlich ist DaVinci Resolve + BRAW so konzipiert, unabhängig von der "Hardware Configuration"->GPU Processing , den GPU/Grafikbeschleuniger sowieso zu nutzen (also egal was der Nutzer unter GPU processing auswählt, läuft im Hintergrund für BRAW immer die Hardwaregrafikbeschleunigung).
BRAW muss ja schneller als alles andere da stehen. Das hat scheinbar eine höhere Priorität, auch dann, wenn das gesamte Programm instabil wird oder komplett abstürzt.

@mash_gh4
Ein Linux User, der DaVinci aus der (bash) Konsole startet, sieht (im Fall eines Absturzes) öfter die Fehlermeldung. ;) So wie es also aussieht, gibt es schon (default) Fehlermeldung...nur nicht für die GUI.



Antwort von dienstag_01:

roki100 hat geschrieben:
dienstag_01 hat geschrieben:
Inwieweit hängt denn die Verarbeitung von BRAW vom Grafikkartentreiber ab? Wahrscheinlich ist DaVinci Resolve + BRAW so konzipiert, unabhängig von der "Hardware Configuration"->GPU Processing , den GPU/Grafikbeschleuniger sowieso zu nutzen (also egal was der Nutzer unter GPU processing auswählt, läuft im Hintergrund für BRAW immer die Hardwaregrafikbeschleunigung).
BRAW muss ja schneller als alles andere da stehen. Das hat scheinbar eine höhere Priorität, auch dann, wenn das gesamte Programm instabil wird oder komplett abstürzt.

@mash_gh4
Linux User, der DaVinci aus der (bash) Konsole startet, sieht (im Fall eines Absturzes) öfter die Fehlermeldung. ;) So wie es also aussieht, gibt es schon eingebaute Fehlermeldung...nur nicht für die GUI. Wahrscheinlich ist das nicht so, aber egal.
Die Antwort könnte lauten, dass BRAW Cuda nutzt und Cuda in den Grafiktreibern integriert ist. Dort könnte der Fehler liegen. Ein Test mit OpenCL hätte vielleicht schon Abhilfe geschaffen.



Antwort von AndySeeon:

dienstag_01 hat geschrieben:
Inwieweit hängt denn die Verarbeitung von BRAW vom Grafikkartentreiber ab? Wenn in den Resolve- Preferences die Option "" aktiviert ist: 2019-12-01 14_49_11-Preferences.jpg dann wird eben die GPU für die BRAW- Verarbeitung genutzt. Diese Option kann man abwählen, dann funktioniert Resolve auch problemlos mit dem aktuellen V441.28 Treiber. Allerdings ist dann der Workflow an einigen anderen Stellen deutlich zäher. Den Unterschied spürt man vor allem, wenn man eine schnelle GraKa hat (2080Ti).

Gruß, AndySeeon



Antwort von AndySeeon:

dienstag_01 hat geschrieben:
Ein Test mit OpenCL hätte vielleicht schon Abhilfe geschaffen. Gute Idee, darauf bin ich noch garnicht gekommen. Könnte man mal ausprobieren - aber das mache ich erst, wenn der nächste neue Studiotreiber auch nicht funktionieren sollte. Vielleicht hat jemand hier noch das Problem und kann das mal testen...

Gruß, AndySeeon



Antwort von AndySeeon:

roki100 hat geschrieben:
Wahrscheinlich ist DaVinci Resolve + BRAW so konzipiert, unabhängig von der "Hardware Configuration"->GPU Processing , den GPU/Grafikbeschleuniger sowieso zu nutzen (also egal was der Nutzer unter GPU processing auswählt, läuft im Hintergrund für BRAW immer die Hardwaregrafikbeschleunigung).
BRAW muss ja schneller als alles andere da stehen. Das hat scheinbar eine höhere Priorität, auch dann, wenn das gesamte Programm instabil wird oder komplett abstürzt. das ist mal wieder ein typischer Roki - nichts verstanden, aber Verschwörungstheorien ausbrüten...



Antwort von roki100:

CUDA nicht, weil es muss ja auch mit AMD funktionieren, was bleibt also übrig?

Das ist höchstwahrscheinlich so bzw. DaVinci Resolve oder BRAW Player nutzt (im Hintergrund) entweder (QT) OpengGL(ES) oder OpenCL...was gibt es noch? Nichts anderes... Eine gute Idee, doch leider sind die passende (qt4/5) Library immer wieder von den proprietären Grafiktreiber Version abhängig...
Das DaVinci Resolve unter MacOS besser/stabiler funktioniert, hat sicherlich etwas damit zu tun, weil Apple die Treiber nur dann ändert wenn es tatsächlich damit Probleme gibt, also sehr selten (wenn DaVinci für macOS Compilert wird, dann kann der Nutzer davon ausgehen, dass es bei ihm genau so funktioniert wie auch bei dem Entwickler)... Das die MacOS Treiber und passende Library als veraltet gelten, kann man hier als positiv sehen, andere tun das nicht. In der 3D Welt z.B. von Blender... oder Autodesk Community, wird das sehr kritisiert. Siehe Beispiel: https://www.heise.de/mac-and-i/meldung/ ... 23044.html
AndySeeon hat geschrieben:
das ist mal wieder ein typischer Roki - nichts verstanden, aber Verschwörungstheorien ausbrüten... Quatsch. Ich versuche es eben zu verstehen. Hast Du eine andere Erklärung? Wieso gibt es einen extra (aktivieren/deaktivieren) Schalter - "use GPU..." BRAW?






Antwort von AndySeeon:

...Hast Du eine bessere Erklärung? Ja. Im Zusammenspiel zwischen dem neuesten NVIDIA- Treiber und Resolve gibt es ein Problem beim Decoden von BRAW. Kann man auch bei NVIDIA nachlesen. Wenn man das Decodieren per GPU deaktiviert, sind diese Probleme verschwunden (dafür wird's langsamer).
Ich denke (ohne es genau zu wissen), dass die Ursache nicht allein bei NVIDIA liegt, sondern auch bei Resolve bzw. dem BRAW- Decoder von BM, denn der spricht den Treiber von NVIDIA an und irgendetwas in dieser Kommunikation geht schief, so dass Resolve einfriert. Dieser Fehler (das Einfrieren) muss eindeutig von Resolve abgefangen und behandelt werden und das ist derzeit nicht der Fall.

Nur Du behauptest, dass BM absichtlich trotz abgeschalteter GPU- Beschleunigung die GPU nutzt um besser dazustehen und weil das nicht stimmt ist das eine Verschwörungstheorie - sieh es ein! xp

Gruß, AndySeeon



Antwort von roki100:

AndySeeon hat geschrieben:
...Hast Du eine bessere Erklärung? Ja. Im Zusammenspiel zwischen dem neuesten NVIDIA- Treiber und Resolve gibt es ein Problem beim Decoden von BRAW. Kann man auch bei NVIDIA nachlesen. Wenn man das Decodieren per GPU deaktiviert, sind diese Probleme verschwunden (dafür wird's langsamer).
Ich denke (ohne es genau zu wissen), dass die Ursache nicht allein bei NVIDIA liegt, sondern auch bei Resolve bzw. dem BRAW- Decoder von BM, denn der spricht den Treiber von NVIDIA an und irgendetwas in dieser Kommunikation geht schief, so dass Resolve einfriert. Dieser Fehler (das Einfrieren) muss eindeutig von Resolve abgefangen und behandelt werden und das ist derzeit nicht der Fall.

Nur Du behauptest, dass BM absichtlich trotz abgeschalteter GPU- Beschleunigung die GPU nutzt um besser dazustehen und weil das nicht stimmt ist das eine Verschwörungstheorie - sieh es ein! xp Dann hast Du etwas missverstanden, obwohl deine Erklärung sich von meine kaum unterscheidet (ich habe es fettmarkiert). Ich schreibe nichts anderes: Wahrscheinlich ist DaVinci Resolve + BRAW so konzipiert, unabhängig von der "Hardware Configuration"->GPU Processing , den GPU/Grafikbeschleuniger sowieso zu nutzen (also egal was der Nutzer unter GPU processing auswählt, läuft im Hintergrund für BRAW immer die Hardwaregrafikbeschleunigung).
Deswegen gibt es ja diesen extra Schalter für BRAW (use GPU...) den Du auch entdeckt hast. Dieser ist also unabhängig davon, was man unter GPU processing ausgewählt hat. Man kann nun meinen, dass beim aktivieren des Schalters, die ausgewählte "GPU processing mode" (unter Hardware Configuration) genutzt wird und m.M lautet hier: wahrscheinlich nicht...

BRAW hat also eine separate Leitung für die Kommunikation mit GPU.

Das BMD den eigenen Codec besser als andere Codecs darstellen, um das zu verstehen, muss man doch kein Verschwörungstheoretiker sein... Das was ich schreibe basiert auf Wahrscheinlichkeitstheorie. Die Idee von BMD mit BRAW, sehe ich sogar als sehr gut, nur wird es da m.M. öfter Abhängigkeitsprobleme geben (die GPU Hersteller müssen mitmachen bzw. das unterstützen). In der OpenSource Welt ist das eines der Gründe damals gewesen mit OpenSource Treiber für Nvidia & ATI zu starten... Denn das eine hat öfter mit dem anderen nicht immer gut funktioniert...öfter war das eine Bremse für die Weiterentwicklung unter Linux.



Antwort von dienstag_01:

Bevor es richtiger Quatsch wird:
*Blackmagic RAW is also GPU accelerated and works with Apple Metal, CUDA and OpenCL.*



Antwort von roki100:

dienstag_01 hat geschrieben:
Bevor es richtiger Quatsch wird:
*Blackmagic RAW is also GPU accelerated and works with Apple Metal, CUDA and OpenCL.* Ich sehe immer noch nicht wo der Quatsch ist?



Antwort von dienstag_01:

roki100 hat geschrieben:
dienstag_01 hat geschrieben:
Bevor es richtiger Quatsch wird:
*Blackmagic RAW is also GPU accelerated and works with Apple Metal, CUDA and OpenCL.* Ich sehe immer noch nicht wo der Quatsch ist? Prinzipiell wird bei Nvidia Hardware Cuda genutzt, wenn man OpenCL will, dann muss man das explizit auswählen, wenn es denn überhaupt in der entsprechenden Anwendung einen Weg dafür gibt. Zusätzlich muss man sich darüber klar sein, dass OpenCL von Nvidia nicht so unterstützt wird wie Cuda, man also auch mit Leistungseinbußen rechnen muss.



Antwort von roki100:

dienstag_01 hat geschrieben:
roki100 hat geschrieben:


Ich sehe immer noch nicht wo der Quatsch ist? Prinzipiell wird bei Nvidia Hardware Cuda genutzt, wenn man OpenCL will, dann muss man das explizit auswählen, wenn es denn überhaupt in der entsprechenden Anwendung einen Weg dafür gibt. Zusätzlich muss man sich darüber klar sein, dass OpenCL von Nvidia nicht so unterstützt wird wie Cuda, man also auch mit Leistungseinbußen rechnen muss. Das ist klar. Was ich aber angesprochen habe ist, dass BRAW eigene Leitung/Port hat, für das aktivieren und deaktivieren von GPU Hardwarebeschleuniger. Dieser funktioniert unabhängig davon, was unter "Hardware Configuration"->GPU processing mode ausgewählt ist. Das hat BMD u.a. deswegen gemacht, damit Drittentwickler, die sich mit BRAW SDK bedienen, BRAW mit GPU Hardwarebeschleuniger auch für andere NLE's zur Verfügung zu stellen (möglich ist also CUDA, Metal, OpenCL). Die Idee ist gut, doch dass es damit Probleme gibt, beweist sogar der Erfinder selbst und zwar mit der eigene NLE Software (DaVinci)... Denn, es ist von GPU Library Version abhängig, womit BRAW (SDK) compiliert ist. Und das funktioniert leider nicht immer gut. BMD selbst und auch die, die sich mit BRAW SDK bedienen, müssen bei eine Änderung (seitens GPU Hersteller) immer hinterherlaufen. Betroffen sind am ende die Nutzer, die sich darüber beklagen, dass die BRAW+GPU Wiedergabe das Programm zum Absturz bringt, dass das BRAW Plugin für Adobe nicht funktioniert... das Rosa streifen... oder schwarze Bild ..oder andere Artefakte beim BRAW abspielen zum Vorschein kommen usw. usf. ALL das hat damit zu tun, was ich versuche zu erklären. Apple hat das einfach gelöst, indem sie ein Treiber verwenden der bei MacOS standardmäßig dabei ist. Die Entwickler (außer Adobe ;) ) wissen und nutzen die eine GPU Library für eigene MacOS-Programme...

Wenn die Option "use GPU" für BRAW in DaVinci aktiviert wird, dann muss das nicht bedeuten, dass damit auch das genutzt wird, was man unter "Hardware Configuration"->GPU processing mode" ausgewählt hat. Wäre es so, dann ist die separate Option "use GPU...BRAW" eine Option zu viel...? Es kann also schon sein, dass z.B. OpenCL für die Wiedergabe genutzt wird, während alles andere das, was man unter GPU processing mode ausgewählt hat.



Antwort von mash_gh4:

roki100 hat geschrieben:
@mash_gh4
Ein Linux User, der DaVinci aus der (bash) Konsole startet, sieht (im Fall eines Absturzes) öfter die Fehlermeldung. ;) So wie es also aussieht, gibt es schon (default) Fehlermeldung...nur nicht für die GUI. ich verwende zwar resolve in genau dieser weise, aber auch hier schaut es leider icht wesentlich anders aus. du brauchst dir nur die unzähligen beispiele solcher ausgaben im resolve forum ansehen, um zu erkennen, wie wenig information über die tatsächlichen absturzursachen diesen logs zu entnehmen ist. nur in den allerseltensten fällen lässt sich daraus auf umwegen irgendwas sinnvolles od. gar eindeutiges ableiten. am ehesten noch aus den backtraces bzw. core dumps bei richtig gravierenden abstürzen. aber auch diese information kann man als endanwender ohne zugriff auf den zugrundeliegenden code im regelfall nicht wirklich sinnvoll nutzen od. nachvollziehen.



Antwort von roki100:

ja da hast Du recht. Ich hatte letztens so ein Fehler und als ich Resolve aus der Konsole gestartet habe, wusste ich genau, es liegt an falsch verlinkte lib Datei (ln -s ... war dann die Lösung).
Ich finde sowieso, wenn ein Softwareentwickler auf Ausgabe von Fehlermeldungen verzichtet, ist m.M. kein guter Entwickler.



Antwort von srone:

wobei das problem des to"s gelöst ist, auch ich habe vor ca 3 wochen, vor meinem urlaub, den neuesten nvidia-studio-treiber installiert, mangels zeit (2 wochen urlaub) eben nicht mit resolve, bis dato stabil, benutzt, nach meiner rückkehr allerdings häuften sich die unnachvollziehbaren programmabstürze im laufe letzter woche, ich werde also morgen auch den älteren studio-treiber aufspielen und berichten.

lg

srone

edit: ich benutze kein braw, sondern prores hq, avchd und dji mp4, als abzuspielende dateiformate.






Antwort von srone:

roki100 hat geschrieben:
ja da hast Du recht. Ich hatte letztens so ein Fehler und als ich Resolve aus der Konsole gestartet habe, wusste ich genau, es liegt an falsch verlinkte lib Datei (ln -s ... war dann die Lösung).
Ich finde sowieso, wenn ein Softwareentwickler auf Ausgabe von Fehlermeldungen verzichtet, ist m.M. kein guter Entwickler. dann beschreib doch mal du oder vielleicht auch mash-gh4, aus eurer programmierersicht, wie zutreffend solche ausgaben von fehlermeldungen von programmen sind bzw sein könnten, kostet das nicht auch rechenleistung damit ein prozess dan anderen zuverlässig überwacht? ich würde mir das gerne näher vorstellen können.

lg

srone



Antwort von dienstag_01:

srone hat geschrieben:
roki100 hat geschrieben:
ja da hast Du recht. Ich hatte letztens so ein Fehler und als ich Resolve aus der Konsole gestartet habe, wusste ich genau, es liegt an falsch verlinkte lib Datei (ln -s ... war dann die Lösung).
Ich finde sowieso, wenn ein Softwareentwickler auf Ausgabe von Fehlermeldungen verzichtet, ist m.M. kein guter Entwickler. dann beschreib doch mal du oder vielleicht auch mash-gh4, aus eurer programmierersicht, wie zutreffend solche ausgaben von fehlermeldungen von programmen sind bzw sein könnten, kostet das nicht auch rechenleistung damit ein prozess dan anderen zuverlässig überwacht? ich würde mir das gerne näher vorstellen können.

lg

srone Lade folgende Bibliothek -> Bibliothek gefunden J/N -> Bibliothek nicht gefunden -> weiter ohne (oder Absturz)
Dafür braucht es keinen eigenen Prozess.



Antwort von srone:

dienstag_01 hat geschrieben:
srone hat geschrieben:


dann beschreib doch mal du oder vielleicht auch mash-gh4, aus eurer programmierersicht, wie zutreffend solche ausgaben von fehlermeldungen von programmen sind bzw sein könnten, kostet das nicht auch rechenleistung damit ein prozess dan anderen zuverlässig überwacht? ich würde mir das gerne näher vorstellen können.

lg

srone Lade folgende Bibliothek -> Bibliothek gefunden J/N -> Bibliothek nicht gefunden -> weiter ohne (oder Absturz)
Dafür braucht es keinen eigenen Prozess. in meinem verständnis einen prozess oder handle der das j/n interpretiert und die fehlermeldung ausgibt, deswegen meine frage.

lg

srone



Antwort von dienstag_01:

srone hat geschrieben:
dienstag_01 hat geschrieben:

Lade folgende Bibliothek -> Bibliothek gefunden J/N -> Bibliothek nicht gefunden -> weiter ohne (oder Absturz)
Dafür braucht es keinen eigenen Prozess. in meinem verständnis einen prozess oder handle der das j/n interpretiert und die fehlermeldung ausgibt, deswegen meine frage.

lg

srone Ob eine Bibliothek geladen wurde oder nicht sollte ein Programm sowieso wissen, sonst wird's wild.



Antwort von srone:

dienstag_01 hat geschrieben:
srone hat geschrieben:


in meinem verständnis einen prozess oder handle der das j/n interpretiert und die fehlermeldung ausgibt, deswegen meine frage.

lg

srone Ob eine Bibliothek geladen wurde oder nicht sollte ein Programm sowieso wissen, sonst wird's wild. genau und auch dafür wird es wohl eine routine geben,welches selbiges erfasst, es nützt nix wenn wir da oberflächlich bleiben.

lg

srone



Antwort von dienstag_01:

srone hat geschrieben:
dienstag_01 hat geschrieben:

Ob eine Bibliothek geladen wurde oder nicht sollte ein Programm sowieso wissen, sonst wird's wild. genau und auch dafür wird es wohl eine routine geben,welches selbiges erfasst, es nützt nix wenn wir da oberflächlich bleiben.

lg

srone Eine Fehlermeldung ist eine Textausgabe, mehr nicht.



Antwort von roki100:

Öfter ist die Lösung eine einfache if-Anweisung, mit ein oder zwei elseif mehr dazu. Außerdem gibt es extra Debugger, die in eigenem Code geladen/integriert/verknüpft werden... Ein Wert wird an Debugger geschickt, da analysiert und mit return OK oder nicht-OK zurückgegeben, hinter "nicht OK" kommt die exakte Fehlermeldung, die vom Entwickler in einer verständlichen Sprache übersetzt werden muss, um so den Nutzern z.B. in GUI auszugeben und lesbar zu machen....



Antwort von srone:

für mein verständnis ist also der debugger der überwachungsprozess?

und quasi die entscheidungsinstanz?

lg

srone



Antwort von roki100:

srone hat geschrieben:
für mein verständnis ist also der debugger der überwachungsprozess? Es ist einfache Methode für die Entwickler um Fehler zu analysieren...Überwachungsprozess muss der Entwickler selbst einbauen, wie bereits erwähnt, handelt es sich dabei öfter um ein elseif (also wenn if x/y nicht zutrifft, dann else und wenn das auch nicht zutrifft, dann elseif...) und sowie es aussieht, fehlt einige elseif Zeilen bzw. falschwerte abgreifen, auswerten, (fehler) ausgeben und/oder weitere Prozesse starten - wie Beispiel: wenn das verdammte "use GPU BRAW" Probleme macht, dann markiere es grau und informiere den AndySeeon dass er "use GPU BRAW" nicht aktivieren/deaktivieren kann, weil es Probleme bei #include nvidia.so gibt und funktioniere trotzdem weiter... ;)
BMD macht aber, wenn das verdammte "use GPU BRAW" Probleme macht, NIX = Absturz. ;)

Es gibt auch Debugger, die ein kompiliertes (C++) Programm auf Fehler Analysieren, siehe gdb: https://www.uni-muenster.de/AMM/num/Vor ... bugger.pdf Doch um das zu nutzen, muss BMD das DR Programm mit Flag -g kompilieren... Ob BMD das tatsächlich getan hat, kann ein Linux user mal testen.






Antwort von srone:

roki100 hat geschrieben:
srone hat geschrieben:
für mein verständnis ist also der debugger der überwachungsprozess? Es ist einfache Methode für die Entwickler um Fehler zu analysieren...Überwachungsprozess muss der Entwickler selbst einbauen, wie bereits erwähnt, handelt es sich dabei öfter um ein elseif (also wenn if x/y nicht zutrifft, dann else und wenn das auch nicht zutrifft, dann elseif...) und sowie es aussieht, fehlt einige elseif Zeilen bzw. falschwerte abgreifen, auswerten, (fehler) ausgeben und/oder weitere Prozesse starten - wie Beispiel: wenn das verdammte "use GPU BRAW" Probleme macht, dann markiere es grau und informiere den AndySeeon dass er "use GPU BRAW" nicht aktivieren/deaktivieren kann, weil es Probleme bei #include nvidia.so gibt und funktioniere trotzdem weiter... ;)
BMD macht aber, wenn das verdammte "use GPU BRAW" Probleme macht, NIX = Absturz. ;)

Es gibt auch Debugger, die ein kompiliertes (C++) Programm auf Fehler Analysieren, siehe gdb: https://www.uni-muenster.de/AMM/num/Vor ... bugger.pdf danke roki, für deine erläuterung, so wild brauch ichs nicht, ich wollte eigentlich nicht finale programme analysieren, sondern nur verstehen wie so eine fehleranalyse programmtechnisch ausschaut.

lg

srone



Antwort von dienstag_01:

srone hat geschrieben:
roki100 hat geschrieben:

Es ist einfache Methode für die Entwickler um Fehler zu analysieren...Überwachungsprozess muss der Entwickler selbst einbauen, wie bereits erwähnt, handelt es sich dabei öfter um ein elseif (also wenn if x/y nicht zutrifft, dann else und wenn das auch nicht zutrifft, dann elseif...) und sowie es aussieht, fehlt einige elseif Zeilen bzw. falschwerte abgreifen, auswerten, (fehler) ausgeben und/oder weitere Prozesse starten - wie Beispiel: wenn das verdammte "use GPU BRAW" Probleme macht, dann markiere es grau und informiere den AndySeeon dass er "use GPU BRAW" nicht aktivieren/deaktivieren kann, weil es Probleme bei #include nvidia.so gibt und funktioniere trotzdem weiter... ;)
BMD macht aber, wenn das verdammte "use GPU BRAW" Probleme macht, NIX = Absturz. ;)

Es gibt auch Debugger, die ein kompiliertes (C++) Programm auf Fehler Analysieren, siehe gdb: https://www.uni-muenster.de/AMM/num/Vor ... bugger.pdf danke roki, für deine erläuterung, so wild brauch ichs nicht, ich wollte eigentlich nicht finale programme analysieren, sondern nur verstehen wie so eine fehleranalyse programmtechnisch ausschaut.

lg

srone Programmtechnisch wird man natürlich erstmal das protokollieren, was man sowieso abfragt. Debugging geht tiefer und hilft beim Suchen nach Fehlern im Programm.



Antwort von srone:

dienstag_01 hat geschrieben:
srone hat geschrieben:


danke roki, für deine erläuterung, so wild brauch ichs nicht, ich wollte eigentlich nicht finale programme analysieren, sondern nur verstehen wie so eine fehleranalyse programmtechnisch ausschaut.

lg

srone Programmtechnisch wird man natürlich erstmal das protokollieren, was man sowieso abfragt. Debugging geht tiefer und hilft beim Suchen nach Fehlern im Programm. ja, verstanden, aber wie läuft das genau ab? wieviel systemzeit verbraucht der debugger?

lg

srone



Antwort von dienstag_01:

srone hat geschrieben:
dienstag_01 hat geschrieben:

Programmtechnisch wird man natürlich erstmal das protokollieren, was man sowieso abfragt. Debugging geht tiefer und hilft beim Suchen nach Fehlern im Programm. ja, verstanden, aber wie läuft das genau ab? wieviel systemzeit verbraucht der debugger?

lg

srone Debugger sind, wie der Name sagt, Werkzeuge um Bugs zu finden. Wenn z.B. Resolve ausgeführt wird, läuft kein Debugger.



Antwort von srone:

dienstag_01 hat geschrieben:
srone hat geschrieben:


ja, verstanden, aber wie läuft das genau ab? wieviel systemzeit verbraucht der debugger?

lg

srone Debugger sind, wie der Name sagt, Werkzeuge um Bugs zu finden. Wenn z.B. Resolve ausgeführt wird, läuft kein Debugger. ach so, aber wer entscheidet dann über die finale fehlermeldung im laufenden betrieb und deren ressourcenverbrauch, darum gings mir....;-)

lg

stone



Antwort von dienstag_01:

srone hat geschrieben:
dienstag_01 hat geschrieben:

Debugger sind, wie der Name sagt, Werkzeuge um Bugs zu finden. Wenn z.B. Resolve ausgeführt wird, läuft kein Debugger. ach so, aber wer entscheidet dann über die finale fehlermeldung im laufenden betrieb, darum gings mir....;-)

lg

stone Das ist natürlich alles etwas komplexer, als hier besprochen werden kann, aber wie oben schon geschrieben, können Abfragen einfach protokolliert werden. Das kostet eher keine Ressourcen, z.B. Nvidia vorhanden, verwende Cuda. So eine Meldung hilft allerdings nicht, wenn im Treiber von Cuda ein Fehler auftritt. Nur die Programmierer der Anwendung können letztlich entscheiden, an welchen Punkten sie Meldungen generieren lassen, um im Fehlerfall Hilfestellungen zu haben.



Antwort von srone:

genau, aber wer entscheidet, weshalb, über code ok oder nicht?

welche instanz macht sich das zu eigen?

lg

srone



Antwort von dienstag_01:

srone hat geschrieben:
genau, aber wer entscheidet, weshalb, über code ok oder nicht?

welche instanz macht sich das zu eigen?

lg

srone Code ist ok, wenn er läuft.
Wenn du allerdings ein Video sehen willst und sich dein Email Programm öffnet, dann kann es sein, dass das Programm perfekt läuft, aber irgendwie anders als erwartet ;)



Antwort von mash_gh4:

ich glaub, dass man die geschichte nur sehr schwer verallgemeinern kann.

es gibt fehler, gerade im zusammenhang mit grafiktreibern, die man beim besten willen kaum abfangen und vernünftig behandeln kann. um derartiges zu vermeiden, verwendet man in der regel eher automatisierte systeme, die laufend alle möglichen betriebssystemversionen durchprobieren und auf diese weise versuchen, fehler ausfindig zu machen, die sich nach irgendwelchen änderungen im code od. in der systemumgebung plötzlich zeigen.

aber die dinge, wo es oft viel wichtiger wäre, das man vernünftige rückmeldungen erhält, sind im falle vom resolve oft deutlich einfacher gelagert. z.b. braucht das programm wirklich nicht unkommentiert abstürzen od. stecken bleiben, wenn beim programmstart ganz offensichtlich irgendwelche komponenten od. systemumgebungsvoraussetzungen nicht passen.

das ist den meisten fällen wirklich nur der schlampigkeit der programmierer geschuldet, weil man in solchen fällen wirklich fast immer irgendwelche aussagekräftigen resultate von den entsprechenen befehlen zurück erhält, die man programmtechnisch sauber auswerten und in fehlermeldungen übersetzten kann.

und selbst, wenn das nicht immer gleich von anfang an immer perfekt gelöst ist, was ja bei einem derart komplexen programm durchaus vorkommen kann, macht es zumindest sinn, an jenen stellen nachzubessern, wo sich angesichts von benutzerrückmeldungen od. automatisch erfassten fehlermeldungen ganz offensichtlich eine häufung an problemen zeigt. im fall von resolve unterbleibt aber genau das auffallend konsequent. man findet daher weit eher irgendwo in einem forum einen tipp, worauf man besser selber achten sollte, statt dass einer der zuständigen programmierer die paar trivialen zeilen code einfügen würde, um derartiges im programmablauf automatisiert zu überprüfen und ggf. eine vernünftige warnung od. fehlermeldung auszugeben.

derartiges verstehe ich einfach nicht, weil für mich das programmieren ja nicht unbedingt nur dazu dient, völlig an den benutzern vorbei irgendeinem fernen technokratischem ideal nachzujagen, sondern uns vielmehr mühsame routine durch automatisierungsmöglichkeiten abnehmen sollte, so dass die menschen vor den computern unterstützt und von sorgen entlastet werden. und dazu gehört eben einfach auch ein verantwortungsvolles bemühen um brauchbare fehlermeldungen.






Antwort von MK:

Ich kenne das eigentlich so dass die Softwarehersteller im professionellen Umfeld bestimmte Treiberversionen als getestet freigeben und wenn man andere Versionen nutzt ist das auf eigenes Risiko (bzw. z.B. bei manchen I/O-Karten funktionieren die ohne den vorgeschriebenen Treiber gar nicht) und dann gibt es teilweise nicht mal Support, selbst wenn Probleme offensichtlich nichts mit dem Grafiktreiber zu tun haben.

Nervig natürlich wenn der Hersteller träge und mit dem Testen und anpassen immer stark im Rückstand ist, oder verschiedene Programme auf dem selben Rechner verschiedene Freigaben haben und man den kleinsten gemeinsamen Nenner beim Treiber selber suchen muss.



Antwort von mash_gh4:

MK hat geschrieben:
Ich kenne das eigentlich so dass die Softwarehersteller im professionellen Umfeld bestimmte Treiberversionen als getestet freigeben und wenn man andere Versionen nutzt ist das auf eigenes Risiko... ja -- diese zugangsweise vernehme ich ich auch immer wieder.

gleichzeigig eklären dann aber dieselben hersteller gleich im nächsten atemzug, dass man unbedingt immer die aktuellsten treiber ihrer hardware benutzen soll, wenn man fehler vermeiden will.

auch die grafikkartenhersteller werden dir in der regel eher letzteres erzählen -- also, dass code, der korrekt geschrieben wurde, selbstverständlich mit den neuen treiber kompatibel sein sollte und nur fehler ausgemerzt wurden und ein paar neue features hinzugekommen sind.

in bereichen wo man das nich ganz so oberflächlich und alleine aus der sicht der hersteller heraus vernünftig zu handhaben versucht, verwendet man in diesem zusammenhang gerne sgn. semantic versoning. dort erkennt man dann alleine schon an hand der veränderten versionsnummer, ob es sich wirklich nur um kleine fehlerbereinigungen handelt, oder aber inkompatible änderungen an den schnittstellen vorgenommen wurden.

aber auch das ist natürlich eher nur graue theorie bzw. nicht viel mehr als ein bemühter versuch. in der praxis ist die qualitätskontrolle -- am besten parallel in beta-testzweigen und produktionsversionen -- durch automatisierte tests weiterhin weiterhin unabdingbar.

trotzdem gibt es im falle von resolve wirklich sehr viele probleme, die sich mitr ein bisserl klareren fehlermeldungen ohne großen aufwand besser lösen ließen.
schau dir einfach an, welchen unglaublich großen anteil die fragen von verzeiweifelten usern einnehmen, die versuchen resolve unter linux zu starten, aber keine nvidia karten eingebaut haben oder die inkompatiblen nouveau treiber installiert haben.

beides ist wirklich sehr einfach abzufragen und sinnvoll in inkompatiblitätswarnungen zu übersetzten. im falle von resolve ist das aber auch nach jahren und unzähliger diesbezüglicher fragen im forum noch immer nicht der fall. das programm bleibt einfach in ziemlich unnachvollziehbarer weise beim hochfahren stecken.

in solchen fällen finde ich es einfach besser, wenn man tatsächlich das programm verbessert bzw. entsprechende unmittelbare rückmedungen vorsieht, statt jeden betroffen wieder erneut auf die suche nach antworten in foren, handbüchern od. der hotline zu schicken.

solche dinge kann man im programmablauf genauso vernünftig automatisiert abarbeiten, wie man den benutzern eben auch die umrechnungen von irgendwelchen farbpixeln durch die automatisierten abläufe zu erleichtern versucht, statt sie mit irgendwelchen in hinweisen im handbuch dazu aufzufordern, notwendige werte für die berechnung vorher auf einem externen taschrechner od. mit papier und bleistift für den befriedigenden programmablauf vorzubereiten.

wie gesagt, ich hab durchaus ein gewisses verständnis dafür, dass sich in komplexer software regelmäßig irgendwelche fehler einschleichen, die erst im laufe der praktischen verwendung entdeckt und schritt für schritt beseitigt werden können. damit das aber wirklich einigermaßen geordnet und effizient funktioniert, verlangt es halt ein bisserl kommunikations- und kooperationsbereitschaft auf seiten aller beteiligter. bei BMD kann ich derartiges bemühen kaum ausmachen. deren zeifelhafter umgang in puncto software qualitätskontrolle, fehlender öffentlichen issue tracker u.ä. ist leider alles andere als vorbildlich. das schlägt sich natürlich auch in der praktische zuverlässigkeit und dem ständigen ärger mit diesem programm nieder.

mir persönlich wäre es wirklich lieber, BMD würden nicht ganz so viel geld alleine nur in öffentlichkeitsarbeit und das erschließen neuer massenmärkte stecken, sondern eben auch in die dringend notwendige qualitätsverbesserung ihrer software investieren.



Antwort von dienstag_01:

Wer sich einen Eindruck verschaffen will, was Meldungen zur Laufzeit aussagen und wie sich ein zusätzlich generierbares Reportfile auswirken können, kann sich bei Hybrid (Encoder) umsehen, das geht bis zur Ausgabe des SSIM Index für das exportierte Video. Und einen Debug Output kann man auch noch anstoßen.



Antwort von MK:

mash_gh4 hat geschrieben:
gleichzeigig eklären dann aber dieselben hersteller gleich im nächsten atemzug, dass man unbedingt immer die aktuellsten treiber ihrer hardware benutzen soll, wenn man fehler vermeiden will. Naja, man muss allerdings auch dazusagen dass Blackmagic seit jeher die größte Frickelbude ist die es am Markt gibt... bis da mal was fehlerfrei wie beworben läuft können bei vereinzelten Produkten schon ein paar Monate bis Jahre vergehen (Decklink 3D ohne 3D-Funktion ausgeliefert, oder der Teranex der nach jahrelangem Lieferverzug kaum funktioniert hat und über weitere Jahre durch Firmwareupdates erst nutzbar wurde), oder es werden von heute auf morgen neue Fehler eingebaut. Wie damals als der Ton in deren eigenem Capturetool Media Express in der neuen Version über die Zeit immer mehr asynchron wurde, der Fix dazu kam erst Monate später, die wo neue Karten hatten die mit den alten Versionen nicht liefen schauten in die Röhre. Die wo damit Material eingespielt haben und es erst hinterher gemerkt haben ebenso.

Die dümmlichen Videos in denen Pomadenkönig Grant Petty (Marcus Schmalzlockus) grenzdebil in die Kamera predigt wie toll alles ist, setzen dem Ganzen häufig die Krone auf. Ich kann mir nicht vorstellen dass der nicht mitkriegt was bei ihm im Laden bei einzelnen Produkten läuft.

Klar gibt es auch ein paar Sachen die gut funktionieren, aber häufig gäbe es auch genug Gründe dem Verantwortlichen nach Monaten des Ärgers das Geraffel um die Ohren zu hauen :D

So ein bisschen Grafikkarten-Treiberinkompatibilität bei Resolve ist da doch noch eher harmloserer Natur.



Antwort von Frank Glencairn:

Du, ruf doch mal in Hollywood an, und sag denen mal was da Phase ist, die armen wissen das immer noch nicht, und müssen mit den schrecklichen BM Produkten arbeiten. Ich weiß gar nicht wie die ohne solche Experten wie dich überhaupt einen Film in die Kinos bekommen haben.



Antwort von MK:

"Frank Glencairn" hat geschrieben:
Du, ruf doch mal in Hollywood an, und sag denen mal was da Phase ist, die armen wissen das immer noch nicht, und müssen mit den schrecklichen BM Produkten arbeiten. Ich weiß gar nicht wie die ohne solche Experten wie dich überhaupt einen Film in die Kinos bekommen haben. Was ist am Begriff "vereinzelte Produkte" und "ein paar Sachen die gut funktionieren" für Dich nicht zu verstehen???



Antwort von MK:

Davon mal abgesehen habe ich nicht generell geschrieben Blackmagic ist Schei** sondern dazu konkrete Beispiele genannt... widerlege die Aussagen doch bevor Du hier rumpolterst...



Antwort von Darth Schneider:

Keine Software die so viele verschiedene Kunden, Workflows und nicht zuletzt auch verschiedenste Computersysteme zufriedenstellen muss wird jemals perfekt für alle sein....
Und schaut euch doch mal an was Resolve in den letzten Jahren für riesige Schritte gemacht hat ??
Ich habe das Gefühl BMD steckt mehr als genug Zeit und Energie in die Software Verbesserung, vor allem wenn man bedenkt das die Software einerseits gratis ist und andererseits aber auch in Hollywood inzwischen Standart ist...und das schon lange nicht mehr nur für Colorgrading.
Das sind wirklich viele verschiedenste Mäuler zum stopfen, von blutigsten Amateuren bis zu Vollprofis mit jahrzehntelanger Erfahrung...Die einen wollen schneiden, die anderen nur Color graden, der nächste konzentrieret sich auf Compositing, noch ein anderer braucht vielleicht mehr Speed.....und will alles mit einem nicht für Resolve idealen Rechner machen......
Black Magic macht doch dabei eine sehr gute Figur, finde ich wenigstens.
Grüsse Boris



Antwort von Jörg:

mag ja alles sein, BM erlebt dann eben das Gleiche, wie alle anderen NLE.
Der Nutzer jammert, egal ob seine Problematik an der Software, seiner hardware oder seinen persönlichen Unzulänglichkeiten liegt.

Warum sollte ausgerechnet BM von diesen Zuständen ausgenommen sein?
Da sind Hinweise auf Hollywood wenig zielführend...eher lächerlich anmaßend.






Antwort von Darth Schneider:

Im Idealfall stellt man sich das Computersystem auch passend zu den Anforderungen der Software, mit der man arbeiten möchte, zusammen...
Und nicht umgekehrt, das ist der Fehler den die meisten machen, die Software Probleme haben.
Zuerst eine geile, teure Kiste kaufen und dann sich wundern wenn’s am Schluss nicht so recht läuft, dann ist natürlich der Softwarehersteller schuld...
Gruss Boris



Antwort von GaToR-BN:

Kann den aktuellen Frust schon verstehen - und doch war Videobearbeitung immer schon eine extreme Anwendung mit vielen Variablen von Hard- und Software als Basis. Resolve läuft bei mir verhältnismäßig sauber.

Welche NLE-Lösung siehst du denn als postives Beispiel dagegen an?



Antwort von MK:

Ich glaube manche springen hier nur auf Irgendwelche Triggerwörter an und lesen gar nicht... es ging um Hardware die erst mal Ewigkeiten ohne den gekauften Funktionsumfang geliefert wird oder erst mal Jahre beim Kunden reifen muss bis sie unzählige Updates später funktioniert, Programme wie das Blackmagic-eigene Media-Express kaputtprogrammiert werden und es keiner für nötig befindet da kurzfristig für Abhilfe zu sorgen, und das vor dem Hintergrund doch ein eher kleines Problem ist wenn es Schwierigkeiten mit Resolve auf Grund einer Inkompatibilität mit einem bestimmten Grafikkartentreiber gibt.

Das wäre alles nur halb so tragisch wenn der Geschäftsführer nicht immer so extrem selbstbewusst auftreten würde und Produkte als das Allergrößte bewirbt obwohl er wissen müsste dass es bei manchen derart klemmt dass man lieber die Klappe halten sollte ;)

Warum soll man immer nur das Positive schreiben? Aber gut: Ich nutze BM-Produkte seit der ersten Stunde, durch BM sind in vielen Bereichen erst die Preise (auch anderer Hersteller) in Regionen gekommen die sich jeder leisten kann, selbst die ersten Decklink-Karten funktionieren heute noch mit aktueller Software Dank den neuesten Treibern (geht bei AJA z.B. nicht, die setzen Produkte konsequent EOL und dann gibt es auch keine neuen Treiber mehr).

Aber einiges geht halt überhaupt nicht und das muss man dann halt auch mal ansprechen... würde Blackmagic in manchen Bereichen Reklamationen eloquenter handhaben und den Hintern schneller hochkriegen wäre das was Anderes...



Antwort von Frank Glencairn:

MK hat geschrieben:

Was ist am Begriff "vereinzelte Produkte" und "ein paar Sachen die gut funktionieren" ... die größte Frickelbude ist die es am Markt gibt...

Die dümmlichen Videos - Pomadenkönig - grenzdebil..

.. das Geraffel um die Ohren zu hauen.

Wie war das mit dem "Herumpoltern" nochmal?

Fass dich mal an die eigene Nase, und dann versuch's nochmal.



Antwort von Jörg:

das muss man dann halt auch mal ansprechen... das ist Sinn eines Forums, da ändert auch die gereizte Reaktion von Nutzern ( ich vermeide bewusst den Ausdruck "Fanboys" ) nichts.
So wie in diesem Beitrag, wo sich die Lösung fand, egal wer für die Störung nun verantwortlich war.



Antwort von MK:

"Frank Glencairn" hat geschrieben:
die größte Frickelbude ist die es am Markt gibt...

Die dümmlichen Videos - Pomadenkönig - grenzdebil..

.. das Geraffel um die Ohren zu hauen.

Wie war das mit dem "Herumpoltern" nochmal?

Fass dich mal an die eigene Nase, und dann versuch's nochmal. Das ist kein Herumpoltern sondern meine Wahrnehmung aus 15+ Jahren Nutzung von Blackmagic Produkten.

Dass es nicht auf alle Produkte zutrifft hatte ich bereits geschrieben, bei denen wo es zutrifft stehe ich auch zu meinen obigen Aussagen.



Antwort von roki100:

@MK
man darf BMD hier nicht kritisieren. ;) Obwohl Du recht hast, haben manche ein Problem damit dir zuzustimmen.



Antwort von srone:

so nun heute mittag wieder auf den nvidia studiotreiber 431.87 zurück und siehe da, es rennt wieder einwandfrei...:-)

lg

srone



Antwort von roki100:

@MK,

leider traue ich mich nicht dir Daumenhoch zu geben (obwohl ich hier Nr.1 Daumenhoch-Geber bin) weil Darth Schneider und Frank dann sauer auf mich sind und das möchte ich nicht, weil ich die beide sehr mag. Ich finde z.B. andere BMPCC4K sch*... außer die von Darth Schneider, Frank, cantsin... derer BMPCC4K nicht, die sind etwas besonderes und können auch cinematisch, aber alle andere, besonders die 5 Stück von Mr.Keksi, einfach nur schrecklich, die IQ ist wie von eine gute Smartphone Kamera und kaum zu unterscheiden ;) Da ist RX10 Mark 1 viel besser, GH2 von srone sowieso... ;)






Antwort von Frank Glencairn:

roki100 hat geschrieben:
@MK
man darf BMD hier nicht kritisieren. ;) Falls dir der Unterschied zwischen "kritisieren" und

"die größte Frickelbude ist die es am Markt gibt -dümmlichen Videos - Pomadenkönig - grenzdebil.."

nicht geläufig sein sollte, letztere is keine Kritik sondern nur kindisches Getrolle,
da nichts davon irgendwas mit den Produkten zu tun hat.



Antwort von dosaris:

srone hat geschrieben:
so nun heute mittag wieder auf den studiotreiber 431.87 zurück und siehe da, es rennt wieder einwandfrei...:-) na prima.
das war für NVIDIA (hattest Du in diesem thread nicht verkündet)?

Leider gips für meine AMD-GPU keine neueren/anderen Treiber :-(
Die Symptome unter Resolve passen aber zu den hier (und im BMD-Forum) dargestellten
Problemen.



Antwort von mash_gh4:

"...da nichts davon irgendwas mit den Produkten zu tun hat."

genau das denke ich mir auch jedesmal, wenn ich wieder ein mit BMD werbung zugepflastertes messeportal sehe od. über die bunten pseudo-studio bilder auf der resolve webpage wiedereinmal ungläubig den kopf schütteln muss. ;)



Antwort von srone:

dosaris hat geschrieben:
srone hat geschrieben:
so nun heute mittag wieder auf den studiotreiber 431.87 zurück und siehe da, es rennt wieder einwandfrei...:-) na prima.
das war für NVIDIA (hattest Du in diesem thread nicht verkündet)? hatte es gestern weiter oben erwähnt und gerade ergänzt...;-)

lg

srone



Antwort von MK:

"Frank Glencairn" hat geschrieben:
"die größte Frickelbude ist die es am Markt gibt -dümmlichen Videos - Pomadenkönig - grenzdebil.." Der Pomadenkönig hat's rausgerissen, hm? ;)

Irgendwann ist halt der Punkt erreicht wo sachliche Kritik ausgereizt ist, die Formulierung mag kindisch rüberkommen, inhaltlich trifft es aber zumindest auf einen Teil der von mir genutzten Produkte zu.

Wenn jemand gebetsmühlenartig in Werbevideos manche Produkte im Superlativ anpreist die Monate und Jahre brauchen um den verkauften Funktionsumfang annähernd zu bekommen (oder auch nicht), in einer Art als ob er selber noch nie davon gehört hat dass die Hardware das aktuell noch gar nicht kann, dann hat man entweder von den Produkten selber keine Ahnung oder nimmt es bewusst in Kauf Kunden zu täuschen. Würde der Herr Petty sich nicht immer dermaßen aufblasen, könnte man da über einiges leichter hinwegsehen...



Antwort von Frank Glencairn:

Bei so einer Aversion gegen den Laden - warum kaufst du dann überhaupt immer wieder BM Produkte und behältst sie auch noch, statt sie einfach zurückschicken und was zu kaufen, das kann was du willst?



Antwort von dosaris:

MK hat geschrieben:

Wenn jemand gebetsmühlenartig in Werbevideos manche Produkte im Superlativ anpreist die Monate und Jahre brauchen um den verkauften Funktionsumfang annähernd zu bekommen (oder auch nicht), in einer Art als ob er selber noch nie davon gehört hat dass die Hardware das aktuell noch gar nicht kann, dann hat man entweder von den Produkten selber keine Ahnung oder nimmt es bewusst in Kauf Kunden zu täuschen das ist aber kein BMD-spezifisches Problem.
In USA ist alles das superlativste, darunter tun die's halt nicht.

love it or leave it



Antwort von MK:

"Frank Glencairn" hat geschrieben:
Bei so einer Aversion gegen den Laden - warum kaufst du dann überhaupt immer wieder BM Produkte und behältst sie auch noch, statt sie einfach zurückschicken und was zu kaufen, das kann was du willst? Weiß ich vorher dass das gelogen ist wenn ein Zettel in der Packung liegt dass die Kernfunktionalität in Kürze nachgeliefert wird?

Wenn es Grund zur Beschwerde gibt besser die Klappe halten und nichts sagen? Nö...