Beiträge von DosAmp


    ich finde einen Monat schon recht lang. Gibt es eine Statistik, wieviele neue Posts pro Woche/Monat im Schnitt so kommen? Ich würde eher so dran gehen, und schauen was eine Schmerzgrenze sein könnte, die ein durchschnittlicher User aufholen wollen würde.

    Im jährlichen Durchschnitt wird im WHF alle 10¾ Minuten ein Beitrag erstellt bzw. reichlich 4000 Beiträge pro 30 Tage, die sich im Moment auf reichlich 100 Threads verteilen.
    Im Moment enthält die Lesezeichen-Tabelle Einträge zu 76 Benutzern mit jeweils etwa 25 Threads (60 als Maximalwert für mein Konto).

    http://community.mybb.com/thread-51330.html

    Das ist kein Bug, das ist eine Frage der Konfiguration. Der besagte Wert "Gelesene Themen in Datenbank" ist im Moment im WHF auf 7 Tage eingestellt, d. h. nach mehr als einer Woche Abwesenheit "vergisst" die threadsread-Tabelle deine letzte Position im Thread und "showthread.php?…&action=newpost" springt einfach auf den ältesten Beitrag, der nicht älter als eine Woche ist.
    Wir können den Wert gerne etwas höher (d. h. größer als die durchschnittliche Urlaubslänge) drehen.

    MOD:
    >Mods are memes, post asleep.
    Ich hab mal den gröbsten Müll aus dem Thread ins OT verschoben, weil hier ansonsten noch wenigstens ein paar gute Ratschläge zum Sinn und Unsinn einer Nahe-null-Latenz bei der reinen Wiedergabe (nutzt FL Studio fürs Preview eines effektlastigen Projekts z. B. überhaupt mehr als einen Kern?) vs. beim synchronen Einspielen von Tracks eingegangen sind. Ob Michael_ als eher ergebnisorientierte Person diese annimmt, ist am Ende seine Sache. Wenn das aber weiter so geht, haben wir sehr wohl Threadschließungen im Haus.


    Zum Thema hat auch Image-Line einen eigenen Supporteintrag: https://www.image-line.com/support/FLHelp/html/app_opt.htm
    Auch sie empfehlen ausdrücklich nicht, die ASIO-Buffergröße kleiner als 10 ms zu stellen, da dem (ohnehin nur fürs Einspielen relevanten) vernachlässigbaren Gewinn an Schwuppdizität dann eine überproportionale CPU-Belastung (die gerade mit einem komplexen Projekt leicht zu Dropouts führt) gegenübersteht. Im Gegenteil soll man sich langsam nach oben tasten, bis nicht nur keine Dropouts mehr auftreten, sondern auch die CPU-Auslastung bei der Wiedergabe spürbar abnimmt.
    Optionen wie „Mix in buffer switch“ sind eher für Systeme mit einer schwachbrüstigen CPU gedacht, die ansonsten keine zufriedenstellende Latenz erreichen können.

    Die von LatencyMon angezeigten Maße sind auch eher als Richtwerte zu betrachten. Für mein aktuelles System zeigt es mir z. B. als Maximalwert auch 220 µs an, das wäre selbst mit einer Soundkarte mit nativen ASIO-Treibern (die trotz allem auch noch eigenen Overhead haben, bis die Daten tatsächlich im Soundchip sind) viel zu gewagt für einen 2 ms großen Buffer. Das ist Quark, da ist immer noch ein Faktor 10 Unterschied dazwischen, die wohl einfach aus der Hardware selber herrührt.

    Zum Vergleich: Die Hersteller einiger professioneller Soundsysteme, die ich gerade auf die Schnelle nachgeschlagen habe, geben an, dass man mit einem 512 Sample (11,6 ms!) großen ASIO-Buffer anfangen und sich, wenn keine Probleme auftreten, auf 256 oder gar 128 herabtasten kann. Dass es bei dir sogar mit einem Bruchteil dessen funktioniert, sollte insofern mehr als zufriedenstellend sein.


    Wieso hat den dies scrot zu kaputtkomprimiert :b2:

    Liegt an Imgur.

    Zitat von https://help.imgur.com/hc/en-us/articles/210076663-Upload-images

    You can upload JPEG, PNG, GIF, APNG, TIFF, PDF, and XCF (GIMP) files to Imgur. Please note that TIFF, PDF and XCF (GIMP) will be converted to PNG on upload. PNGs over 756KB are automatically converted to JPG.

    Die nächsten zwei regnerischen Tage (heute ziehe ich noch PC auf Win10 um) werde ich jedenfalls mich mit den WHF-Plugins beschäftigen. Im Zweifelsfall werden die Themes wohl kein Showstopper sein.

    Wer will, kann im Übrigen schon mal Vorschläge für MyBB-1.8-kompatible Themes einreichen.
    Beim Rest ist eine der größten Baustellen nur, ob und wie GoMobile noch auf 1.8 laufen wird – ansonsten müsste man die Zeit bis 2.0 mit einem Theme überbrücken, das auf mobilen Browsern einigermaßen bedienbar ist.


    Hat meine Änderung etwas gebracht?

    War vorhin bei mir in Edge noch mal aufgetreten, aber kann auch daran liegen, dass die Fritzbox hier nicht durchgehend stabilen DNS-Server gemacht hat.
    Sollte weiterhin in Firefox 46 beobachtet werden.

    Ähnliche Probleme scheint es im Übrigen mit Edge zu geben, wo ich jetzt jeweils drei Anläufe zum Anmelden und Verfassen eines Beitrags gebraucht habe. Mit IE11 funktioniert alles problemlos. Korrigiere: Dieser Post wurde auch erst beim zweiten Versuch korrekt abgesendet.

    Aus den Fehlerlogs von nginx (PHP-FPM betrifft es nicht, weils schon an der SSL-Verbindung abschmiert) kann man auf der derzeitigen Logstufe nichts Auffälliges erkennen.

    Die 0,5 bis in deinem Fall weit über 10 Millisekunden beziehen sich im Übrigen auf Code, der eben nicht mit höchster Priorität (wozu mit einiger Wahrscheinlichkeit auch kritische Sektionen von ASIO-Treibern gehören sollten) ausgeführt wird. Das ist in der Tat atypisch viel, sollte mit einem gut funktionierenden DAW aber erst mal kein Problem sein.

    Hier ist ein Thread aus TechNet zum Thema:
    https://social.technet.microsoft.com/Forums/en-US/a…d-driver-issues

    Einerseits könntest du vergleichsweise ein anderes Tool namens DPC Latency Checker (und ggf. die auf der Herstellerseite empfohlene Holzhammermethode, ein Gerät nach dem anderen zu deaktivieren und aktivieren, und zu schauen wann es sich näher an der für Win7 typischen 500-Mikrosekunden-Marke einpendelt) heranziehen, andererseits wie dort beschrieben aus dem Windows ADK das "Windows Performance Toolkit" installieren und mit xprof ein CPU-Profiling betreiben, um dann genau zu analysieren, in welchem Treiber oder Prozess der Kernel so exorbitant lange hängt.

    highlight_string erwartet rohen PHP-Code als Eingabe, keinen durch htmlspecialchars vorgefilterten String, der zum Beispiel das einleitende PHP-Tag <? zu &lt;? verstümmelt.

    htmlspecialchars_decode kann die Umformung von htmlspecialchars rückgängig machen.