@st.esser:
mit dem VM-Serververgleich habe ich nur auf den Umstand hingewiesen, dass ein Gerät grundsätzlich die korrekten Funktionen anbieten kann, dem Nutzungsprofil von der Leistung her aber nicht gewachsen ist.
Du erwartest hier die Leistung eines vollwertigen NAS, vergisst aber die Tatsache, dass die FritzBox 7390 in erster Linie ein DSL-Modem-Router mit WLAN und Telefonfunktion inkl. DECT ist, dass nur als Beigabe eine NAS und Mediaserverfunktion hat.
Offensichtlich hast du keinen der Artikel gelesen, in denen ich meine Erwartung formuliert habe: Ich erwarte, dass der USB-Stick mit nicht einmal 1500 Audio-Files, der unter 04.88 sogar an einer (viel schwächeren) 7270 problemlos lief, überhaupt sinnvoll nutzbar wird. Und mein Hauptanliegen ist dabei, dass eine Sortierung nach Tracks funktioniert, anstatt einer alphabetischen Sortierung nach ID3-Tag "Titel" bei Zugriff über "Ordner" und einer anscheinend unsortierten Listung bei Zugriff über "Album". Ist das zuviel verlangt?
Manche UPnP/DLNA-Clients sortieren die empfangenen Listen intern, mein Denon S-32 tut dies aber nicht (und das finde ich auch richtig so, der DLNA-Server hat den gesamten Kontext für die richtige Sortierung, der Client kann nur raten, was richtig ist).
Das Argument: Wer lesen kann ist klar im Vorteil kann ich somit nur dankend zurückgeben.
Ich nehme es von dir nicht zurück. Du hast meine Artikel offensichtlich nicht gelesen, sonst wüsstest du, dass ich ziemlich triviale Anforderungen an den Media-Server in der FB habe.
Kauf Dir ein QNAP 459 Pro II und Dein Problem ist erledigt. Das Teilchen kostet nur ca. 600+ Euro ohne Platten. Siehe einfach Verhältnis Anforderungen und gelieferte Leistung. Dazu habe ich wie Du jetzt ebenfalls keine weitere Lust tiefergehende Erklärungen abzugeben.
Deine Arroganz spricht Bände ... Wie schon vorher in diesem Thread geschrieben habe ich einen Server mit 12TB Platten, von denen ein paar TB ebenfalls Medien-Dateien (die komplette Klassik-Sammlung in FLAC und eigene DVB-S/S2-Aufzeichnungen) enthalten. Der ist aber nur nach Bedarf an und die Fritz!box ist der Audio-Server für rund um die Uhr.
Du hast anscheinend nicht das Prinzip der Limitierung durch die Hardware begriffen: Es kommt nicht darauf an, ob in der Software die Funktion in ähnlicher Weise schon vorhanden ist. Selbst wenn html-Server und UPnP-Server zu 99% gleich sind. In dem Augenblick laufen die Prozesse parallel ab und verbrauchen dafür mehr Rechenkapazität, die dann wieder für andere Dinge fehlt.
Ich habe seit über 30 Jahren Erfahrung im HW-Design, beginnend mit 4Bit Microcontrollern Mitte der 70er Jahre, aber ich kenne auch die MIPS Prozessoren seit über 20 Jahren und habe viel darauf gearbeitet (in Assembler und Hochsprache). Bitte erzähl mir nichts von HW-Limitierung, damit habe ich sehr viel Erfahrung. Und genau deshalb erlaube ich mir das Urteil, dass AVM hier ein trauriges Bild abgibt.
Also dann zum Thema Limitierung:
Es geht hier um ein System gemischter Nutzung, zum Teil mit harten Echtzeit-Anforderungen (Voice).
Telefonie ist am kritischsten, weil hier kein Buffering möglich ist (würde zu störenden Delays führen) und deshalb keine großen Puffer eingesetzt werden können. Das betrifft insbesondere VoIP, wo der Prozessor ja auch Kompression und wahrscheinlich Echo-Unterdrückung etc. leisten muss. Das könnte aber zum Teil auch in einen Signal-Prozessor ausgelagert sein. Der absolute CPU, Speicher und I/O-Bedarf ist aber relativ gering.
Das DSL-Modem ist sicher ausgelagert, belastet den Hauptprozessor (außer vielleicht beim Messen und Aushandeln der Leitungsparameter) also nicht, wie auch der Ethernet-Switch ein Hardware-Modul auf dem SoC sein dürfte.
Video-Streaming benötigt relativ hohe I/O-Leistung, die CPU-Belastung hängt u.a. davon ab, ob USB und LAN/WLAN mit DMA benutzt werden können. Die CPU dürfte aber sogar schnell genug sein, um PIO-Transfers mit den geforderten Raten zu implementieren. Durch Puffern von Daten im RAM (1/2 Sekunde sollte reichen? das wären dann 1-2MB pro Stream) ist das aber weit weniger kritisch als bei Telefonie. Und Audio-Streaming stellt nur eine minimale Last dar.
Andere NAS-Zugriffe werden nach Best Effort ohne Echtzeit-Anforderungen bedient, wofür aber auch ein Cache (mit einigen MB) für spürbar bessere Performance sorgen kann (ist aber in Linux ohnehin Standard). In diese Kategorie fallen auch alle UPnP-Funktionen (Query-Interface u.a. für die Medien-Inhalte, liefern URLs zu den Streams). Wenn es etwas länger dauert, dann ist das Ergebnis trotzdem korrekt und brauchbar (obwohl der neue Media-Server die Geduld manchmal schon etwas strapaziert - ist aber schon weit besser als vor ein paar Monaten noch).
VPN etc. benötigen die CPU für die Crypto-Routinen, es gibt hier aber keine Durchsatzgarantien (von denen ich wüsste), daher stufe ich die auch mal als Best Effort ein.
Weitere Funktionen (Telefonanlage, Web-Interface, Kindersicherung) sind zeitunkritisch, benötigen zwar teilweise durchaus Speicher, aber devon ist zumindest für diese Funktionen noch genug frei.
Wenn wir von knappen Ressourcen sprechen, dann kann das also sowohl geringen NAS-Durchsatz beim Zugriff auf Dateien bedeuten (lästig aber idR. nicht fatal) oder aber erhebliche Latencies im VoIP-Processing (macht VoIP dann weitgehend unbrauchbar).
Aber da VoIP (und andere Prozesse mit harten Echtzeitanforderungen) nur einen kleine Bruchteil der CPU- und I/O-Leistung und des RAM fordern ist es kein Problem, dies durch Priorisierung bzw. Reservierung zu gewährleisten.
Anders sieht es bei Video-Streaming aus. Und da kann die FB tatsächlich ins Limit getrieben werden. Ich habe es nicht getestet, aber 2 HD-Video-Streams über Ethernet sind wahrscheinlich schon zu viel Last. RAM sollte dafür keine Rolle spielen.
Ressourcen ist keine Teilsumme von Speicher, sondern umgekehrt.
Mir ist klar, dass Speicher eine der (im Embedded-Bereich relativ knappen) Ressourcen ist. Und meine Vermutung ist, dass SQLite mit seinem Speicherbedarf nicht die ideale Wahl (jedenfalls keine skalierbare) für ein System mit begrenztem RAM ist. Aber das spricht nicht gegen einen leistungsfähigen Media-Server auf der Fritz!box, sondern deutet nur auf eine Spezifikation hin, die den Media-Server bewusst "klein" gesehen hat.
SQLite ist ja entstanden als RAM billig wurde und man daher auf im RAM gehaltene Tabellen setzen konnte. Diese Architektur setzt aber, anders als traditionelle DBMS, Limits für die Größe der DB. So sehr ich SQLite schätze, so wenig ist es für große Tabellen auf Speicher-beschränkten Systemen geeignet, jedenfalls wenn man keine harten Limits für die Tabellengröße setzt. Es ist legitim, solche Limits zu setzen. Aber man sollte dann nicht mit "auf dieser Hardware ist nicht mehr möglich" argumentieren.
Da Du anscheinden auch seit ca. 20 Jahren Code in die Linux-Kernel-Entwicklung einbringst: Hallo Kollege, schön mal einen Mitentwickler ausserhalb der Entwicklertreffen, Mailinglisten und Fachchats kennenzulernen...
Nein, sorry, ich bin kein Linux-Entwickler, nicht die ganze Open-Source-Welt besteht aus Linux. Mein Code wurde auf Bitte eines Linux-Entwicklers von mir nachträglich unter Dual-License (BSD und für Linux alternativ GPL2) gestellt und ersetzte dann einen Treiber, den die Linux-Community trotz großem Aufwand (und Sponsoring durch Heise) nie stabil bekam. Aber Treiber für Multitasking-OS (also mit Multi-Threading, Echtzeit etc.) habe ich schon Ende der 70er-Jahre geschrieben. Leider komme ich die letzten 10 Jahre kaum noch dazu (habe mich beruflich auf einen ganz anderen Bereich spezialisiert).
Was Assembler-Programmierung angeht, bin ich anscheinend noch nicht so lange dabei, hab 1981 mit dem 6502 von MOS Technology angefangen (Vorläufer des 6510, der im C64 berühmt wurde). Ansonsten können wir die virtuellen S*-Vergleiche lassen.
Von mir aus ... Ich will nur klar machen, dass ich eigene Erfahrungen mit der Programmierung habe und glaube mir ein Urteil zur Leistungsfähigkeit der Fritz!box-HW (auf den verschiedenen Modellen) erlauben zu können.
Wenn Du nur die 1.500 Musikstücke abgespielt haben willst, dann schmeiß den Rest der html-Dateien und anderer für den Mediaserverbetrieb unwichtigen Daten einfach runter oder bleib bei 04.88 (ach ja, willst ja nicht, weil Du die neuen Features der neuen FW nutzen willst -> komisch, sage nur Ressourcenverbrauch!)[/quote]
Welche HTML-Dateien und für den Media-Server unwichtigen Dateien???
Da ist bei mir nichts drauf und deshalb kann ich auch nichts runter schmeißen ...
Ich habe den Media-Server mit identischem USB-Stick unter der 04.88 an einer 7270 betrieben, und da gab es nie Probleme (in Tests hat sich gezeigt, dass es da große Reserven gab). Und jetzt soll es plötzlich wegen neuer Features auf der viel stärkeren 7390 mit doppelt so viel RAM nicht mehr realisierbar sein?
Die neuen/verbesserten Features, die ich benutzen will, sind vor allem IPv6, Kindersicherung und die bessere Kompatibilität mit Gigaset DECT-Telefonen.
Keins dieser Features braucht viel Ressourcen (weder CPU noch RAM), jedenfalls bei weitem nicht so viel, dass die durch die stärkere Hardware gegenüber 7270 gewonnenen Ressourcen dadurch erschöpft werden könnten.
Der OS-Bezug war nicht auf Dich gemünzt, sondern auf Maxi.
Die ID3-Tags haben sich wirklich auf Dich bezogen.
Wenn die Fritte anscheindend nicht nach Dateinamen sortiert, sondern eher nach ID3-Tags (Songname, so nach Deiner Auflistung vermutet), dann sind die Tracknummern im Dateinamen uninteressant. Und dann würde ich einfach trotzdem versuchen, mal eine Nummerierung in den Namen im Tag einzufügen um zu sehen ob es dann klappt. Es war ein Nutzungsvorschlag um zunächst mal den Medienplayer so nutzen zu können, wie Du es vorhast. Ansonsten sortiert er weiter nach den Namen der Kapitel, was leider nicht der Reihenfolge der Kapitel entspricht.
Sorry, es geht hier um Mängel im Media-Server, und der von mir beschriebene ist trivial abzustellen (wenn man die Sourcen hat) und kostet praktisch keine extra Ressourcen.
Wenn ich über "Album" zugreife, dann erwarte ich eine Sortierung nach DiscNo, TrackNo, Title (bisher ist keine Sortierung erkennbar). Hier kann ich auch nichts über Veränderung der ID3-Tags erreichen (da wie gesagt anscheinend gar nicht sortiert wird).
Wenn ich über "Ordner" zugreife, dann ist die zweckmäßigste Sortierung die nach Dateinamen (keine Beachtung von ID3-Tags), aber von mir aus kann die Sortierung gleich sein wie bei Album.
War auch mein letzter Vorschlag, das Thema ist für mich uninteressant geworden, da ich nicht gegen Beratungsresistenz ankomme und meine Ressourcen lieber anderweitig nutze.
Sorry, aber hier ist nichts zu beraten. Wenn ich die Sourcen hätte, dann hätte ich es längst selbst geflickt. Das hätte mich weniger Zeit gekostet als die Fehlermeldungen an AVM (von den Postings hier gar nicht zu reden).
Ich schreibe hier (wie viele andere) auch über schlechtes Qualitäts-Management bei AVM oder aber zumindest über ein in Kauf nehmen von schweren Regressionen in beworbenen Produkteigenschaften.
Der Grund zum Kauf eines 7390 ist doch wohl in der Regel, dass man die Integration von DSL-Modem, WAN-Router, WLAN (a/g/n), GB-Ethernet-Switch, IP-Telephonie, DECT, NAS, Media-Server wünscht (bzw. einem Subset, das zumindest aus weit mehr als nur DSL-Router, Switch und WLAN besteht).
Wenn es bei mir nicht so wäre, dann hätte ich viel Geld gespart und anstatt dessen für deutlich unter 100 Euro einen Buffalo WZR-HP-AG300H oder Netgear WNDR3700 gekauft. Mit 680MHz CPU und 128MB RAM, 5 Gigabit-Ports und schnellem WLAN sind die der 7390 zumindest ebenbürtig. Was fehlt ist das DSL-Modem und DECT, alles andere ist über OpenWRT in guter Qualität vorhanden.