Beiträge von buers

Am Samstag (06.09.25) Vormittag werde ich ein Update der Forensoftware (inkl. aller Plugins) durchführen. Das Forum wird deshalb auf unbestimmte Zeit nicht verfügbar sein. Neuigkeiten wird es im Matrix Chat geben: https://www.kodinerds.net/thread/79927-freischaltung-matrix-chat/

    Die Fragen sind etwas rätselhaft.

    Welcher Anbieter ist das denn, wenn man fragen darf ?

    Hatte schon erwähnt, dass ich bei der Telekom bin. Die Techonlogie dahinter nennt sich GPON - Gigabit Passive Optical Network. Gigabit Passive Optical Network – Wikipedia Dort findet man auch explizit die 2,5 Gbit/s und 1,25 Gbit/s erwähnt (und anderswo findet man es bestätigt für meinen Provider).

    Ist das eine Fritzbox vom Anbieter, bzw. hast Du da im Uplink den Anbieter konfiguriert ?

    Ist dein Beitrag an mich gerichtet? In #33 hatte ich den Routertyp genannt: Speedport Smart 4. In #41 hatte ich dich, te36 zitiert, wo du selbst von meinem "Speedport" schreibst - hattest also offenbar den Router-Typen wahr genommen. Mein Speedport ist insofern vom Anbierter, dass ich ihn bei der Telekom gekauft habe. Aber war vollkommen unabhängig gekauft von meinem Internet-Tarif. Mein ca. 10 Jahre alter Router (der zunächst immer noch mit dem neuen FTTH Anschluss zurecht kam) hatte angefangen Spirenzchen zu machen.

    Auf meine Frage, woher mein Speedport Smart 4 die genauen Bandbreitenparameter des Glasfaser-Anschlusses kennt ...

    Da da nicht genau die gebuchten Geschwindigkeiten angezeigt werden denke ich mal, das im Speedport ein internes speedtest eingebaut ist, das bei Bedarf mal laufen gelassen wird.

    Das mit dem Speedtest kam mir nicht plausibel vor, insbesondere weil ich immer die gleichen Geschwindigkeiten angezeigt sehe, auch kurz nach absichtlicher Trennung. Ein Speedtest müsste mehr Varianz zeigen.

    Bin dem nochmals selbst nachgegangen - KI-Bots scheinen deine Annahme zu bestätigen. Ist wohl aber anders. Das Glasfasermodem kennt in der Tat die Geschwindigkeit nicht, das weiß nur die "Connect-Daten" - 2,5 Gbit/s Download, 1,25 Gbit/s Upload typischerweise. Diese Bandbreiten werden im Allgemeinen im Zeitmultiplex-Verfahren von mehreren Endpunkten geteilt. Das Modem erkennt die eigenen Pakete (und entschlüsselt sie, fremde Pakte kann es nicht entschlüsseln). Der Zeitmultiplex ist übrigens erwartungsgemäß dynamisch - ich nehme stark an, dass das im Zweifel auch "overcommitted" sein kann (die Summer aller an einer Leitung gebuchter Leistungen der Kunden ist größer, als die physisch vorhandene Bandbreite).

    Die eigentliche pro Kunde verfügbare Bandbreite (was mein Router anzeigt im Screenshot in #33) wird wohl über Service-Provider spezifische Autokonfigurations-Protokolle bzw. über PPPoE bekannt gemacht. Scheint normal zu sein, dass zumindest manche Service Provider da einen Aufschlag geben zu der gebuchten Leistung. (Bei mir 550/120 vs. 500/100). Ich denke, diese Daten sind primär wichtig für QoS / Traffic Shaping. "Normaler" Datenverkehr ohne Priorisierung sollte vollkommen unabhäng davon sein.

    Hmm, ich frage mich wie das dann mein Speedport Smart 4 macht. Internet ist auch über externes Glasfaser-Modem angeschlossen, Speedport zeigt mir 550 Mbit/s Download und 120 Mbit/s Upload an. Das entspricht auch meiner Erfahrung mit Speedtest oder Downloads und Uploads (bei sehr guter Gegenseite natürlich nur).

    Gebucht habe ich übrigens 500 Mbit/s und 100 Mbit/s Download/Upload. Für alle Ethernet-Ports selbst inkl. der Verbindung zum Modem wird mir selbstverständlich 1 Gbit/s im Status angezeigt.

    Noch ein Randthema zum Beitrag. Bei uns in der Straße waren seit längerem Bauarbeiten. Habe mal den mutmaßlichen Kapo angesprochen, was Sie machen. "Spülbohrung [o.s.ä.] für Glasfaser". (Anderswo wurde der Asphalt aber auch komplett durchgehen aufgefräst) Ich: "Wir haben hier doch schon seit Jahren Glasfaser". - "Ja, von der Telekom. Wir verlegen jetzt für Vodafone". Großartig ...

    Zu Hochformat kenne ich mich nicht aus. Habe aber auch Kodi auf "Touch-Devices" installiert. Auch ich sehe da leider keine gute "Usability". Die Touch-Skins scheinen alle nicht mehr supportet. Manches ist bei mir bei großer Bibliothek einfach kaum mehr sinnvoll zu bedienen mit Touch. Mehrere Minuten zu Swipen macht keine Spaß. Hatte hier früher auch schon mal ähnliche Anfragen gestellt, ohne wirklich hilfreiche Antwort. Wieso ich das jetzt schreibe - vielleicht gibt es ja doch noch mal Skin-Entwickler oder Kodi-Entwickler die das verbessern möchten. Das wäre schön.

    Ich sehe schon, was du willst. Ich würde es lassen ...

    Zu deiner as.xml Datei:

    - sources.xml sollte man nicht nutzen bei pathsubstitution. as.xml.xml - Official Kodi Wiki: "Note: Path substition for "sources" and profiles is broken, and will NOT be fixed."
    - cache settings zu Puffergröße etc. werden bei einigermaßen aktuellen Kodi Versionen ignoriert. Kann man in der GUI einstellen. Abgesehen davon erscheint mir dein Wert sinnlos hoch. Oder hast du sowas mal getestet und einen Vorteil festgestellt? Meine Tests zeigen, dass es eher kontraproduktiv wird. Wenn es nicht ein Problem gibt, das nachweislich gelöst oder besser wird, würde ich Defaults lassen. (Ich weiß, dass es Empfehlungen im Netz gibt, das groß zu machen - mir scheint die Empfehlungen waren meist ohne Nachweis nach Gutdünken "Viel hilft viel")
    - Wie gesagt funktioniert nach meinem Verständnis pathsubstitution für addon-data nicht (korrekt/zuverlässig).
    - Wo hast du Doku zu epgdatabase und tvdatabase gefunden? Ich sehe die in kodi.wiki nicht erwähnt.
    EDIT: Habe es interessehalber im Kodi-Quelltext gesucht, und dort auch gefunden in xbmc/settings/AdvancedSettings.cpp: for (const auto& dbname : { "videodatabase", "musicdatabase", "tvdatabase", "epgdatabase" }). Sollte gehen, aber verstehe noch nicht ganz, was es bringt. Anders als die videodatabase sind tv/epg in Kodi ja immer im Fluss, und werden normalerweise bei jedem Start/regelmäßig komplett neu befüllt aus den konfigurierten Quellen. Siehst du einen funktionalen Vorteil, diese DBs auf zentralen DB-Server auszulagern? (Klar, mag bisschen Platz sparen)

    Dass verschiedene Clients verschiedene Daten speichern müssen, hört sich ja eher schlecht für mein Vorhaben an.

    Vielleicht hatte ich mich da missverständlich ausgedrückt. "Daten" meinte ich nicht nur als Konfigurations-Daten, sondern im Sinne aller Dateien, die dort rumliegen. Und das sind für PVR Addons auch Binaries (d.h. der in binäre Maschinensprache übersetzte Quelltext des Addons - der ist abhängig vom Prozessor und vom Betriebssystem). Das ganz pathsubstitution-Zeugs ist sowieso ein "Hack". Für rein lesende Dinge mag das gut funktionieren. Aber bereits bei Thumbnails (die meist rein lesend sind) schreibt die Kodi Doku vor, dass man das Verzeichnis nicht zwischen verschiedenen Clients teilen darf. Wenn parallel Clients auf umgeleitete Dateien gleichzeitig schreibend zugreifen - dafür ist Kodi nach meinem Verständnis nicht designed. (Oft ist es für die Benutzer nicht ersichtlich/transparent wann Kodi auf Dateien schreibend zugreift).

    Möglicherweise funktioniert dein Vorhaben für einzelne Dateien wie pvr.iptvsimple/resources/settings.xml. Mit Glück für das ganze Verzeichnis. Ich kenne den Aufwand für deine Settings nicht - bei mir bin ich für eine Neuinstallation mit der PVR Konfig in 1 Minute durch und muss das danach praktisch nie ändern. Das auf ein paar Clients ist meines Erachtens ein erträglicher Aufwand. Die zwei Beiträge hier zu schreiben hat länger gedauert. Die settings-xml könntest du auch kopieren von einem Client zum nächsten. sources.xml und passwords.xml auch.

    Kannst du bitte mal deine as.xml.xml zeigen?

    Pathsubstitution für Addons / addon data funktioniert nicht. Hast du irgendwo gefunden, dass das gehen sollte? PVR-Addons sind eh nochmals komplexer, da sie binary Addons sind - d.h. verschiedene Clients müssen unterschiedliche Daten in addons\pvr.iptvsimple haben.

    Beeindruckend, insbesondere auch Tiefenschärfe, weiche natürlich wirkende Bewegung, Schattenwurf und sogar Widerschein des Feuers auf dem Boden.

    Kannst du bitte für ein oder wenige Beispiele den exakten kompletten Prompt nennen? Und wo du den eingegeben hast und ggf. Kosten (einmalig? Pro ...?)

    Ok, sieht mir aber schon verdächtig aus mit dem logupload am Ende des Logs. Du hast auch mit dem Zeitstempel im Log gegengeprüft?

    Es ist schon so, dass man beim Killen von Kodi durch das Android OS (z.B. wegen Speichermangels) davon keine Spur im Kodi-Log findet. Allerdings scheint Speichermangel nach deinen Beobachtungen unwahrscheinlich.

    Bei Kodi-Fehlern selbst kann sich das Problem im Log andeuten (z.B. wenn immer vor dem Absturz was Ähnliches im Log ist, vielleicht von einem Addon, etc.) Aber echte harte Fehler (sagen wir ein Nullzeiger-Zugriff) wird man auch nicht sehen im Kodi-Log.

    Das OS selbst sieht es und schreibt dazu auch was in Systemlogs. Vielleicht kennst du dich schon aus mit adb und logcat oder hast Interesse dich da einzulesen.

    Diese Erläuterung

    das war schon korrekt so und insgesamt lief es ca. 10 Minuten, aber habe es ca. 4 Minuten überhaupt nicht angerührt bevor es beendet wurde. Ob ich in Kodi ein Video schaue oder einfach nichts tue ändert nichts am Ergebnis.

    ist für mich unklar. Ganz oben steht "immer nach ca. 4 Minuten". Dann sagst du, "überhaupt nicht angerührt" - unter den Umständen also doch länger? Dann folgt der Widerspruch "Ob ich [...] einfach nichts tue ändert nichts" Hmmm?

    Als ich hier im Forum gerade nach "logcat" suchte, sprang mir ein Beitragstitel ins Auge

    Weejas
    13. Dezember 2023 um 23:00

    . War aber für den Moment zu faul, das durchzugehen. Möglicherweise interessant für dich.

    Ich kann mir nicht vorstellen, dass es am RAM liegt. Jedenfalls lief bei mir Kodi mit 1,5 GB RAM zuverlässig. Wenn es doch am RAM liegen sollte, solltest du es mit aktivierter Debug-Protokollierung sehen im Onscreen Display/Overlay (wie immer das heißt) - dort findest du es unter MEM. Was wird dort angezeigt?

    bisher nur TVDB und MovieDB hinzugefügt

    Und Loguploader?

    Doofe Frage - hast du möglicherweise das falsche Log hochgeladen? - weil ich sehe 2 Zeilen vor Schluss loguploader erwähnt. Ein abgestürztes Kodi kann aber kein loguploader nutzen ... Selbst nutze ich loguploader nicht, aber wenn du es benötigst - es wird sicherlich eine Option geben das alte Log hochzuladen (kodi.old.log). Außerdem schriebst du

    Auf dem Xiaomi TV Gerät "verabschiedet" sich Kodi immer nach ca. 4 Minuten

    Das Log lief aber 10 Minuten?

    Des weiteren finde ich immer nützlich, eine kurze Textbeschreibung zu machen, neben dem Log, möglichst sekunden-genau. So "11:45:03 habe ich Film xyz unter Menupunkt Filme gestartet. Lief an und spielte korrekt ab. 10 Sekunden später hat sich Kodi verabschiedet".

    Ich finde es grundsätzlich auch erstrebenswert, nicht viele Geräte mitlaufen zu lassen bei uns im Haushalt ("nur" um einen Film zu schauen) und schon gar nicht dauerhaft.

    Ist sichergestellt, dass jeweils nur ein Gerät Kodi öffnet? (Z.B. weil es nur einen Nutzer gibt, aber in verschiedenen Räumen verschiedene Kodi-Clients)

    Falls ja: Für Windows und Linux wäre es sehr einfach ein Skript zu schreiben, das Kodi startet, davor die DB-Dateien vom NAS an die richtige Stelle im lokalen Dateisystem zu verschieben und am Ende wieder zurück verschieben. (Verschieben statt Kopieren verhindert auch ein paralleles Modifizieren). Für deinen FireTV wüsste ich jetzt auf Anhieb keine Lösung, denke aber würde man auch so ähnlich hinkriegen. Könnten bestimmt hier andere helfen.

    Unklar ob unter diesen Umständen (sicher gestellt, dass niemals ein zweites Kodi gestartet wird) nicht doch path substitution funktionieren würde. Ich habe nichts Konkretes dazu gefunden, halt nur die sehr dicken Warnungen das nicht zu tun und die grundsätzliche Aussage, das ginge nicht.

    Mit meinem Mini-PC BMAX B1Pro würde man eine DB für Kodi in unter 3 W Energieverbrauch hinkriegen. Kodi braucht bei den meisten Installationen keine performante DB. Andere noch sparsamere (und weniger bemerkbare) Geräte sind denkbar, Fritzbox selbst leider kaum.

    Selbst habe ich mich entschlossen, auf DB-Synchronisierung/Watched State/... zu verzichten. Merkt bei uns im Haushalt niemand wirklich.

    Nein. Hier ist es erklärt: Special protocol - Official Kodi Wiki

    Wie gesagt, ich würde es nicht machen. <from>special://masterprofile/Database/</from> oder auch <from>special://database/</from> bezeichnen das Verzeichnis der lokalen Datenbank-Tabellen.

    Wo die im Filesystem liegen weiß Kodi schon. Der genaue Pfad dorthin kann von verschiedenen Dingen abhängen. Auch auf eigentlich gleichem System (z.B. zwei Fire-TV Sticks) kann der Pfad unterschiedlich sein. Auf verschiedenen Systemen sowieso. Die special-Methode funktioniert unabhängig davon.

    Allerdings eben fast Null technischer Nerd Content bezueglich Kernspaltung etc. was bei dem Freund, mit dem ich im Kino war, zur Abwertung gefuehrt hat ("30 Minuten haetten gereicht").

    Hatte das schon Mal kommentiert. Zufällig begab es sich heute, dass im Mainzer Theater die Veranstaltung "Physik im Theater" lief, mit einem Vortrag "Zur Physik des Films Oppenheimer" von dem Kernphysiker Harald Giessen. Da zeigte sich ein ganz anderes Bild. "Physikalisch sehr sehr akkurat" und andere Formulierungen. Er wies auf viele Details im Film hin, die nerdig exakt waren - auch solche die für Dramaturgie/Verständnis unwichtig waren und auch solche, die sich nur mit Background-Wissen wirklich genießen ließen. Der Vortrag war 90 Minuten lang, vollgestopft mit Referenzen zum Film.

    Ich denke in Kürze wird man ein Video davon finden, Suchstring "Physik im Theater Mainz". War wirklich ein kurzweiliger informativer Vortrag - selten so einen guten akademisch populärwissenschaftlichen Vortrag gehört. Hätte mir den Film vorher nochmals ansehen sollen. Will das in Kürze tun. Das Video zum Vortrag könnte für manche Nerds hier auch interessant sein.

    Das war die Einführung von Matthias Neubert, mit nettem Hintergrundbild für einen Physik-Vortrag

    Und noch ein Foto des Vortragenden Harald Giessen mit selbstkritischem, traurigen Robert Oppenheimer auf der Leinwand.

    Syntaktisch sieht es für mich grundsätzlich korrekt aus. Die Forums-SW und deren Konfig macht aus dem Wort (bewusst falsch geschrieben) "advancedsettngs" immer einen Link, ich meine selbst im Code, daher kann man es nicht ganz sicher sagen. Empfehlenswert ist es noch, eine Version mitzugeben. Außerdem würde ich auch auf "masterprofile" referenzieren. Ich hatte einen Artikel verlinkt aus dem Kodi-Wiki, der das zeigt.
    Ein Beispiel von mir, das funktioniert, wieder mit kleinem Tippfehler bei advanced-settings:

    Code
    <advancedsettngs version="1.0">
     <pathsubstitution>
       <substitute>
         <from>special://masterprofile/Thumbnails/</from>
         <to>smb://user:pw@hpms/Bay4/kodithumbsmagentatvone/</to>
       </substitute>
     </pathsubstitution>
    </advancedsettngs>

    Wobei die AMD Linux Treiber leider auch Einschränkungen gegenüber WIndows haben, z.B. was HDMI 2.1 Features angeht und manche hohen Videoauflösungen. AMD hatte den Quelltext entwickelt, das HDMI Forum hat aber die Freigabe blockiert. (Lizenzierungs und Patent-Problem) Ich kann mich nur ärgern.

    Mit Displayport gibt es die Einschränkungen wegen Lizenzierung nicht, spielt aber halt kaum eine Rolle in unserem Universum hier.

    Wenn ich es richtig verstanden habe, können proprietäre Nvidia-Treiber da manche Aspekte durchaus besser mit HDMI.

    Eins wundert mich trotzdem bei dem Thema. Ich dachte immer, eine Videocodierung von unkomprimiertem Material ist ja nicht lossless und nicht eindeutig. Unterschiedliche Algorithmen / Optimierungen / Konfigurationen können zu verschiedenem Ergebnis kommen. Aber wenn man das wieder in unkomprimierte Farbpixel umrechnet in der nativen Auflösung - sollte das nicht grundsätzlich eindeutig sein? Natürlich erhält man nicht das Raw-Bild zurück, aber sollte nicht jede SW/HW-Kombination (je nach Farbmodell) sagen wir mal die identischen RGB Werte für jedes Pixel pro x-y-t-Koordinate berechnen?

    Wo kommt dann der Qualitätsunterschied her? Bei Farbraum-Umrechnungen, Rundungen, Kalibrierungen, Gamma-Korrekturen - da verstehe ich schon, dass es sehr kleine Unterschiede geben kann. Aber sind die dann wirklich für so dramatische Effekte wie in #1 beschrieben verantwortlich? (Insbesondere wenn man keine Skalierung benötigt - also die ganze Wiedergabekette in der Auflösung und Frequenz des Bildschirms stattfindet).

    Vielleicht ist mein Punkt nicht ganz klar geworden. Ansonsten, sorry für die Wiederholung.

    Laut Hypertext Live Streaming (HLS) Standard, können sich Komponenten/Streams in einer Playlist (im "Master-Manifiest", typischerweise .../master.m3u oder playlist.m3u) schon ändern für Live Streams (nicht für VOD). RFC 8216: HTTP Live Streaming

    Dort steht z.B.: "The client MUST periodically reload a Media Playlist file [...]". Die genaue Periodizität ist nicht spezifiziert. Bei einer resilienten Komponente, die die Playlist auswertet und die Streams verarbeitet könnte zumindest ein Übertragungsfehler (404) einen Reload der Playlist triggern.

    Für ein Programm wie ffmpeg mag das sehr unpraktisch sein, beispielsweise wenn es mit expliziten map x:y Parametern aufgerufen wird - da könnte sich die Bedeutung der y mit der Zeit ändern. Auch wenn das Ausgabeformat so einen dynamischen Wechsel nicht unterstützt. Transport-Stream unterstützt so einen Wechsel.

    Sind das HLS Streams mit "master-m3u8-Manifest" und "modernen" modularen Streams - also Audio und Video (und Untertitel) separat und nicht in einem Transport Stream zusammen? In so einer Situation könnte ich mir vorstellen, dass der vorige Audio-Stream wegfällt, im Master aber auch ein anderer neuer angeboten wird mit jedem Wechsel des Audio-Formats. (Und bei 404 einfach Master neu einlesen?)

    Irgendwie habe ich da ein Deja Vu, bei der Fehlerbeschreibung im Kontext mit IPTV-Streams auf Enigma2 und Werbeunterbrechungen dort. (Wenn 2.0 - 5.1 Wechsel in DVB-Quellen wie DVB-S, DVB-T, DVB-C stattfindet, haben die Enigma2 Boxen sicher kein Problem damit, und auch nicht bei den RTP-Streams von Magenta-TV. Die sind allerdings kein HLS)

    Das Dolby-Audiosignal wechselt bei blue TV zwischen 2.0 und 5.1 hin und her, deswegen kommt es zu den Abbrüchen.

    Sorry, falls ich da was missverstehe. Mich würde interessieren - der Wechsel beim Audio-Signal scheint nach deiner Analyse der Auslöser, aber welche Komponente ist verantwortlich für den Abbruch?

    Wechsel von Audiosignal ist nicht ungewöhnlich und sogar Bestandteil von DVB-Standards. RTL, Pro7, SAT.1 etc. machen das andauernd bei den Werbeblöcken. Ein Programm wie ts-Doctor kann das sogar ausnutzen, Filme mit Werbe-Unterbrechungen automatisch zu schneiden. Auch bei ÖR kann man so automatisch schneiden (wenn beispielsweise in ZDF Film in 5.1 ausgestrahlt wird, WISO davor und heute journal danach in Stereo). ffmpeg kommt bei mir mit den IPTV-Streams von Magenta-TV Gen1 auch damit zurecht. Ich meine es gab sogar einen ARD-IPTV-Test-Sender, der die Stream-Eigenschaften dauernd gewechselt hat. Kodi Simple IPTV kommt bei mir auch mit dem 2.0 - 5.1 Wechsel zurecht bei den Magenta-TV Gen1 Streams.

    Interessanter Lesestoff dazu, eine frei erhältliche Masterarbeit mit subjektiven und objektivem Vergleich von h265 und AV1 (Fokus 4k Material). Microsoft Word - Masterarbeit_2021_01_12.docx

    Wie so oft, ist es im Detail kompliziert ... Tlws. gewinnt AV1 deutlich gegen H265 bei identischer Bitrate, tlws. nicht (abhängig von Video)

    Wen sowas interessiert, eine wissenschaftliche Arbeit zum Vergleich H264/H265 hatte ich schon mal erwähnt: https://iphome.hhi.de/wiegand/assets…Performance.pdf

    Dort habe ich mitgenommen, dass ein guter Daumenwert ist: für gleiche Videoqualität spart H265 etwa ein Drittel Daten. Wie ich weiter oben schon erwähnte - beim Recodieren verliert man allerdings zwangsweise Qualität, da sich die Schwächen/Artefakte/.. der Codecs addieren. Die wissenschaftliche Vergleichstests nehmen eher den Standpunkt eines Produzenten, der aus einem Master höherer Qualität das beste rausholen will pro Datenrate. Das passt ja auch zu der Diskussion hier. Es ist auch anzunehmen, dass die Produktionsfirmen bessere SW haben, als wir und auch Spezialisten, die sich wirklich sehr gut auskennen. Das wiederum unterscheidet sie kaum von uns [ag]

    Nein, ich will niemanden die Freude nehmen, da Volumen zu sparen. Mich persönlich hat Recodieren allerdings nicht überzeugt. Natürlicherweise sind da nicht alle Leute gleich penibel.

    Sagen wir mal 30Mbps netto pro transponder

    Solche Abschätzungen mag ich auch.

    Eher 43 Mbit/s, zumindest der Transponder mit Das Erste, Arte und zwei SWR, den ich gerade geprüft habe. Alle Astra 19.2° Ost Sender auf Frequenz 11494, Transponder 19

    Die anderen Zahlen kann ich einigermaßen nachvollziehen. Mit 43 Mbit/s Transpondern komme ich auf 81 Tage Lebenszeit für 300 TBW. 4 Stück -> 1 Jahr. Dazu kommt, dasss man für so ein Szenario den Platz vielleicht nur zu 80-90% nutzen sollte.

    Meine Erfahrung aus Enterprise IT zeigte, dass die TBW in vielen Szenarien schon realistisch sind, bei vielen parallelen Zugriffen (das war sogenannter Citrix Write Cache von 80 parallelen Sessions pro Platte) gingen sie aber schneller kaputt, als wir abgeschätzt hatten. Das Risiko war uns bewusst. Ich denke mal 8 Files sind noch nicht "viele" parallelen Zugriffe, aber sollte man sich schon Gedanken drüber machen. In die 8 Files wird ja dauernd geschrieben.

    Ein kleiner Test zeigt z.B. für meine SSD hier im Desktop, dass die Datenrate bei 8 parallelen Zugriffen (mein eigener Lastgenerator, der sich in dem Fall wie ein Transponder-aufnehmendes Programm verhält und Zufallsdaten auf Platte brennt) auf unter 50% fällt des Maximalwertes bei nur einem File. Komme aber immerhin noch auf 180 MByte/s pro File, zeigt also, dass noch viel Luft ist für die pro Transponder benötigte Bandbreite. Zeigt aber auch, dass sich da schon schlechtere Skalierung äußert, als man erwarten könnte. Die Schreibzugriffe pro File sind ja streng sequentiell (und das Filesystem ist jetzt auch nicht extrem fragmentiert). Bei 4 parallel genutzen Platten mag TBW-Abschätzung durchaus gut sein.

    Interessanter Weise vergroessren sich die laufenden Kosten nicht, wenn man laenger pufferen will, da braucht man zwar initial mehr Platten, aber dafuer werden die auch seltener beschrieben.

    Ja. Allerdings werden die SSDs auch so Mal ein Ende ihrer Lebenszeit erreichen, unabhängig von den TBW. Wäre technisch eine Herausforderung, mit mehr SSDs nicht auch signifikant mehr Energie zu verbrauchen.

    kannst Du 2666 Leute mit bespassen.

    Wird trotz irrwitziger IOPS-Kennzahlen in den Datenblättern bei Weitem nicht funktionieren. Insbesondere, wenn auf die identischen Platten auch noch geschrieben wird. Ich will oder kann das jetzt im Detail nicht technisch begründen, aber die SSDs skalieren nicht sooo gut bei Parallel-Zugriffen, wie man das aus den Datenblättern erwarten könnte.

    Kostet also pro Jahr 156 Euro an Festplatten.

    Plus weitere Kosten. Z.B. schätze ich Mal bei Dauerschreibzugriff 5 W pro SSD. Was sonst noch hinzukommt, kommt bisschen auf die Situation an. Brauche ich extra SAT-Karten/einen Sat-IP Server oder habe ich den eh schon oder muss ich was größeres/teureres kaufen. Energieverbrauch von SAT-IP wird oft mit ca. 10 W angegeben. Das "ca." steht auch in den Datenblättern. Könnte mir vorstellen, dass das in Wirklichkeit signifikant höher ist bei 8 durchgehend genutzten Tunern. Vielleicht kann das hier mal jemand interessehalber messen? Bei Unicable mag es nochmals anders sein. Brauche ich extra Server? Könnte mir vorstellen, dass echte Low-Energy Server den Workload nicht schaffen. Die ganze HW muss auch abgeschrieben werden.

    Der Gesamtenergieverbrauch alleine kann leicht teurer werden, als der jährliche SSD Wechsel.

    Zu dem Wohneinheiten-Szenario - wer soll es machen? Wenn es eine Firma macht und wartet, werden da hohe Wartungskosten drauf kommen. Nicht alle SSDs werden 1 Jahr durchhalten - also auch störanfällig oder noch teurer mit RAID. Wenn man das als Nerd für sich macht, ist es anders. Unsere Zeit mit sowas verbrauchen wir ja gerne ...