Hast du auch in Debug-Logging aktiviert?
Wenn du dort auch nichts siehst noch Komponenten-spezifische Logging aktivieren, dort als Idee Webserver auswählen. (Evt. auch noch libCEC oder vielleicht fällt dir selbst noch was anderes ein).
Du hast vermutlich Einstellungen -> DIenste -> Steuerung -> Steuerung über http aktiviert (schließe ich aus deinem FB Test). Ändert das Deaktivieren was?
Ich habe mal in 2 Files reingeschaut. Bei erster Versuch wird ffmpeg erfolgreich gestartet, und es schreibt auch die .ts Segmente für HLS, bis Segment 9. Dann wird ffmpeg wieder gestoppt:
025-01-22 16:49:54.893 Info App: ProcessRun 'StreamTranscode 58fafd': Stopping ffmpeg process with q command for /config/transcoding-temp/F59A45/F59A45_0.ts
Warum kann vielleicht Emby-Experte rausfinden. ffmpeg Prozess lief soweit fehlerfrei.
Wieso 22 Kugeln ffmpeg benötigt, Dampfnudelblues jedoch nicht, sollte auch Emby Experte sehen können im Log. Ich habe mal in die Mediathek gesehen. 22 Kugeln gibt es nur von 3sat. Laut ffmpeg in deinem Log sehen die CODECS so aus:
16:49:54.511 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/Movies/22 Kugeln.mp4':
16:49:54.511 Metadata:
16:49:54.511 major_brand : mp42
16:49:54.511 minor_version : 1
16:49:54.511 compatible_brands: isommp42
16:49:54.511 creation_time : 2024-09-14T10:51:39.000000Z
16:49:54.511 Duration: 01:44:47.92, start: 0.000000, bitrate: 5385 kb/s
16:49:54.512 Stream #0:0[0x1](deu): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 5215 kb/s, Level 42, 50 fps, 50 tbr, 1k tbn (default)
16:49:54.512 Metadata:
16:49:54.512 creation_time : 2024-09-14T10:51:39.000000Z
16:49:54.512 handler_name : GPAC ISO Video Handler
16:49:54.512 vendor_id : [0][0][0][0]
16:49:54.512 Stream #0:1[0x2](deu): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 160 kb/s (default)
16:49:54.512 Metadata:
16:49:54.512 creation_time : 2024-09-14T10:51:39.000000Z
16:49:54.512 handler_name : GPAC ISO Audio Handler
16:49:54.512 vendor_id : [0][0][0][0]Dampfnudelblues gibt es vielfach in der Mediathek. 3sat Download sieht so aus
Duration: 01:26:48.92, start: 0.000000, bitrate: 5487 kb/s
Stream #0:0[0x1](deu): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 5317 kb/s, 50 fps, 50 tbr, 1k tbn (default)
Metadata:
creation_time : 2024-01-15T16:47:17.000000Z
handler_name : GPAC ISO Video Handler
vendor_id : [0][0][0][0]
Stream #0:1[0x2](deu): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 160 kb/s (default)
Metadata:
creation_time : 2024-01-15T16:47:17.000000Z
handler_name : GPAC ISO Audio Handler
vendor_id : [0][0][0][0]Fast identisch, aber nicht ganz - z.B. Level42 fehlt (zeigt allerdings mein ffprobe auch nicht an beim 3sat Download). Anderer sieht so aus
Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 3412 kb/s, 50 fps, 50 tbr, 12800 tbn (default)
Metadata:
handler_name : Hessischer Rundfunk mp4toolbox 1.17.0
vendor_id : [0][0][0][0]
encoder : Lavc61.3.100 libx264
Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
Metadata:
handler_name : Hessischer Rundfunk mp4toolbox 1.17.0
vendor_id : [0][0][0][0]Andere Audio-Rate, tbn anders (keine Ahnung was das heißt). Scheint auch noch eine Datei mit 25 fps zu geben. Irgendwas scheint Emby bei den leicht unterschiedlichen CODECs/Bitraten dazu veranlassen, ein Mal ffmpeg anzuwerfen, ein Mal nicht. Aber das ist nicht das ganze Problem. Auch wenn das benötigt würde - jemand kann vielleicht rausfinden, wieso der Transcoding Prozess wieder gestoppt wird.
Die Beispiele ändern sich (am Anfang war Bilder eines Jahres, dann 22 Kugeln), da war dann Conversion failed im ffmpeg Log, jetzt nicht mehr. Habe aber nicht alle Dateien angesehen.
Es macht für mich auch keinen Sinn, runtergeladene MP4 Dateien irgendwie umzuwandeln
Jedenfalls von mir war das nicht als Workaround gemeint, sondern als Hilfe zur Analyse des Problems. Ich gebe dir recht - das sollte einfach funktionieren.
Wenn hier niemand helfen kann, wende dich doch an den Support von Emby.
Hast du ffprobe? Kannst du mal ffprobe "/Movies/Dampfnudelblues.mp4" ausführen, und Ergebnis hier posten (nicht als Anhang, nur Copy+Paste wie ich das oben gemacht habe, ab Input #0 Zeile). Das gleiche noch für 22 Kugeln. (Ergibt im Prinzip ähnliche Info wie die Frage von bennySB)
Zu 1. DIe Shield hat viel Storage. Mit deinen 16000 Video-Dateien sollten in einem normalen Setup die Cover angezeigt werden, ohne dass du was einstellen musst. Ich würde bei typischer Installation mit tmdb und tvdb Scraper schätzen, dass die ganzen Cover (und Schauspieler-Bilder, und Poster und ...) ca 7 GB Speicher benötigen. Das klappt dann fast auf Anhieb. Mag allerdings klein bisschen dauern, bis alle Cover im sogenannten "Tumbnail-Cache" vorhanden sind. Wenn du überall ein Mal durchgescrollt bist, sind die Bilder da.
Bei mir (mit vielleicht gut halb so vielen VIdeo-Dateien wie bei dir) ist der Thumbnail-Cache 3,5 GB groß und es geht schnell, bis die Bilder alle wieder da sind, wenn ich den mal gelöscht habe.
Bei mir zumindest verschluckt sich Kodi immer Mal wieder mit dem EPG. Wenn sonst alles korrekt ist (das EIngabefile) hilft dann Einstellungen -> PVR und TV -> Allgemein -> Daten löschen -> Alle. (Du hast Kodi 20 - ich meine das hat sich bisschen geändert kürzlich, solltest du aber finden). Gehe davon aus, dass du keine Senderlisten manuell umgeordnet hast oder Gruppen manuell erstellt hast. Sonst Vorsicht mit dem Löschen und erst mal nur Programmübersicht löschen. Danach neu starten.
Ja - hatte auch meinen Beitrag entsprechend ergänzt. Warten wir mal ab, ob das Sternenzauber testet unter seinen Bedingungen. Allerdings wird Cache selbst unter den vorgeschlagenen Bedingungen sich kaum so äußern, wie von dir erwartet, denn
68GB
war die genannte Dateigröße, der Datei die das Problem verursachte (und Vergleichsdatei war noch größer). Je nach Ergebnis des Tests, kann man ggf. die Parameter nochmals nachschärfen.
Auch ohne Cache-Effekte könnte sowas wie Read-Ahead und vom OS optimierter (Device-abhängiger) Zugriff schon signifikanten Effekt haben, bzw. das Fehlen davon je nach Situation die Plattenperformance als praktisch zu niedrig erscheinen lassen.
Grundsätzlich ist aber schon wichtig, bei Testmessungen/Benchmarks höllisch sorgfältig zu sein, bzgl. solcher Effekte. Für Bandbreitentests vervielfache ich typischerweise die Testdateien und vergleiche ...
Fuer den cache nimmt Linux anscheinend gerne auch mal allen freien Hauptspeicher.
Nicht nur "gerne" sondern nach meinem Verständnis eher grundsätzlich. Genauso wie Windows und andere modernen Betriebssysteme. Den für Cache genutzten Speicher können die Betriebssysteme ja jederzeit sehr schnell (ohne Swappen/sonstwie die Daten sichern) freigeben, wenn das RAM anderweitig benötigt wird. (Bei VMs mit Ballooning und Speicher-Overcommitment ist es allerdings wieder etwas anders.)
Also bei den Einstellungen--> Dienste--> Caching sind es die vom Werk eingestellten Werte.
Wie gesagt, dann würde ich Mal mit Einstellungen--> Dienste--> Caching -> Puffermodus: "Alle Dateisysteme puffern inkl. lokale Dateien" prüfen.
dd if=4kfile.mkv ibs=100k iflag=direct | pv -brf > /dev/null 2> /tmp/log
Cool. pv kannte ich noch nicht - habe ich mir gleich mal installiert. iflag=direct vielleicht für diesen Test besser weglassen. Jedenfalls finde ich in Kodi-Quellcode nirgends das Wort "O_DIRECT" was beim Öffnen der Dateien dem dd direct-Parameter entspricht. Wenn ich nichts übersehen habe, benutzt Kodi unter POSIX lediglich O_RDONLY flag für open der Medien-Dateien. Welche blocksize Kodi verwendet konnte ich nicht auf Anhieb rausfinden. Wenn du das so testen willst, Sternenzauber, kannste es ja auch mal mit anderen Werten probieren, wie ibs=10k. Aber grundsätzlich passt der Test schon, wie genannt.
EDIT: Kodi scheint normalerweise Blöcke ("chunks") zwischen 64 kiB und 2048 kiB für Files zu nutzen. Eine kleine Blocksize im dd-Befehl genauso wie das iflag=direct mag allerdings etwas leichter "langsame Sektoren" finden.
(O_DIRECT bzw. i/oflag=direct verlangsamt normalerweise I/O, da Cachemechanismen des Betriebssystems und sowas wie automatisches Read-Ahead übergangen werden. Normale Anwendungsprogramme benutzen deshalb typischerweise nicht diesen Direct-Modus).
Selbst vermute ich bisschen aus dem Thread, dass es nicht an USB oder Festplatten-Durchsatz liegt, wenn das selten sporadisch auftritt. "Matschige Sektoren" sollten ja bisschen reproduzierbar sein - hast du das mal überprüft (ob das Nachpuffern immer an der selben Stelle passiert)? Systemauslastung zu kontrollieren - z.B. parallel laufendes top oder Kodi Bildschirmanzeige im Debug-Modus - könnte noch sinnvoll sein.
Ich denke, sehr gute Antworten von dir, bennySB, bis auf einen Punkt:
Grob kann man sagen es sollten mehr als 2GB RAM vorliegen und ein 64bit Betriebssystem
64bit Betriebssystem kann ich nicht bestätigen und nicht nachvollziehen, zumindest nicht bei Android/Android-TV und einer Box mit weniger als 4 GiB RAM. Kodi gibt es für Android als 32 bit Version und als 64 bit Version - man muss die passende nehmen (bzw. der Playstore macht das automatisch für einen). Funktionale Unterschiede kenne ich keine.
Am Rande: die CPUs der Boxen (die ich so sah in letzter Zeit) sind 64 bit fähig. Oft wird bewusst ein 32 bit Betriebssystem genommen. Die CPUs können dennoch 64 bit lange Berechnungen machen, können aber nicht Speicher jenseits der 4 GiB nutzen.
Persönlich habe ich mehrere Fire TV und Android TV Geräte genutzt oder nutze sie - keines mit mehr als 2 GiB RAM bisher. Ich komme damit gut zurecht und die von mir genutzten Apps inkl. Kodi offenbar auch. Wenn man wirklich mehr als 2 GiB und 64 bit Betriebssystem will, wird die Auswahl halt dünn. Soll nicht heißen, dass das eine schlechte Wahl wäre. Vermute für dein Budget bedeutet das Angebote von Ali.
Für Kodi selbst ist Storage (im Flash) u.U. noch ein wichtiges Kriterium. Wenn du eine sehr große externe Festplatte mit vielen Medien hast, kann der sogenannte Thumbnail-Cache eine beträchtliche Größe haben. Out of the Box landet der im internen Storage. Dann wären meines Erachtens mindestens 16 GB anzuraten. (Man kann den Cache auch auf die Festplatte umleiten - je nach technischem Geschick nicht 100% Anfänger-tauglich).
Zudem sollte man darauf achten, welche Filesysteme für externe Medien genutzt werden können. Fire-TV ist da praktisch wertlos, da weder ext4, noch NTFS noch exfat supportet wird, und damit Dateien nicht größer 4 GiB werden dürfen. (Fire-TV würde ansonsten ins Budget passen, ist aber für Kodi auch nicht 100%-Anfänger tauglich, da Kodi nicht im Playstore vorhanden).
Habe dann die beiden Befehle aus #14 wieder umgekehrt, also so eingestellt wie es werksmäßig ist und habe anschließend auch gestern und heute ca. 10 Filme laufen lassen. Auch hier kein Fehler [buers: mit Windows Client].
Es ist für mich nicht klar aus der Formulierung, ob die Fehler im Log mit den Befehlen aus #14 $False oder $True geschah. Dass das einem Windows Client nix ausmacht, ist zu erwarten. Bei einem Linux/Android/... Client kann das anders sein (und ist Bestandteil tausender Diskussionen im Internet, seit MS das für Win 24H2 geändert hat).
In der Tat trat dein Fehler wieder auf, auch beim Deaktivieren von SMB Signing - aber bezieht sich das Log darauf? Möglicherweise gibt es da auch eine Koinzidenz, irgendwas zufälliges, was mal auftrat, und zu falschen Schlüssen führt. Ich habe auch bei Aufnahmen normalerweise keine Fehler, aber hin und wieder ist einer drin. Ist ja schon auffällig, dass zunächst das Deaktivieren des Signing zu helfen schien und dass es halt die zeitliche Korrelation mit 24H2 gibt.
In den Logausschnitten, die ich sah, waren jedenfalls immer Fehler zu SMB drin. Ich sehe allerdings nicht, das typische Muster, wenn die Bandbreite nicht ausreicht.
Was die Größe der Anhänge angeht: kenne das Limit nicht, aber bequemer für Leser ist paste.kodi.tv. Besser als Anfang Wegschneiden bei so einem Problem: Sagen wir Kodi startet um 15:00, Film startet um 15:03, Fehler tritt 16:00 auf, dann wird Kodi beendet. Wenn File zu groß, am besten die Zeilen zwischen 15:05 und 15:55 löschen.
Scheint du hast Komponenten-spezifisches Debug-Logging eingeschaltet? Falls ja - jedenfalls für mich bringt FFMPEG-Bibliothek für dieses Problem nix (und das scheint an zu sein?). SMB mag hier was bringen. Du wurdest (nicht von mir ...) nach Debug-Log gefragt. Konvention hier im Forum ist bei solchen Anfragen, dass wenn nicht explizit gefordert, die bei der komponenten-spezifische Protokollierung normalerweise alles auf aus ist. Das kann die Länge (und Lesbarkeit) des Logs extrem beeinflussen.
EDIT: Wenn Debug-Logging an ist, sieht man CPU-Auslastung des Systems. Hast du mal darauf geachtet? War die hoch und evt. sogar besonders hoch, als das Problem auftrat? Ggf. wäre es auch interessant zu beobachten, ob CPU-Auslastung sich signifikant ändert, abhängig von der SMB-Signing-Einstellung.
Für mich ist das Log zu viel, können andere vielleicht mehr mit anfangen. Klar, Fehler findet man zu smb. Sieht aber auch so aus, als wäre SMB-Signing wieder aktiv. Also ich würde das nochmals sorgfältig prüfen (ich gab den Hinweis, dass auf dem Windows-Rechner nur die Server-Seite ne Rolle spielen sollte, würde aber sicherheitshalber beide genannten Parameter nehmen, also auch Client-Seite). Anfang des Logs fehlt (wo man beispielsweise Cache Einstellungen sehen würde).
Wundere mich bisschen, dass ich überall nur SMB2 sehe. Bei nur leidlich aktuellem Windows, der als SMB-Server arbeitet, würde ich SMBv3.x erwarten. Mag aber sein, dass die "2" sich einfach nur auf das Signing bezieht. Ansonsten, hast du die Parameter verstellt zu SMB in Kodi? (Mag sein, dass das schon diskutiert wurde, aber nach über 2 Wochen Pause ...)
Zu anderen Hinweisen habe ich bislang keine Rückmeldungen gesehen (Reboot, Last auf dem Server).
Welche Einstellungen hast du unter Einstellungen -> System -> Dienste -> Caching? Nehme an, dass du Kodi 21.x verwendest (bei Anfragen am besten immer angeben), sonst sind die Einstellungen evt. in advanced-settings.xm (falls du da was verändert hast). Nach dem Hinweis on te36 können gutgemeinte hohe Cache-Einstellungen kontraproduktiv sein. Per Default nutzt Kodi allerdings den Video-Cache nicht für lokale Medien (zu denen externe Festplatte gehört). Falls du bei Puffermodus "Alle Dateisysteme puffern, inkl. lokale Daten" eingestellt haben solltest, das mal wieder zurückstellen. (Falls nicht, dann halt auch mal gerade diese Einstellung mit alle Dateisysteme prüfen.)
Wobei:
das es Kodi und/oder der Dateisystemtreiber schaffen, so viel vom Video zu cachen, das dann (periodisch) lange genug nicht auf die Platte zugegriffen wird
das eher nicht bei 4k Videos vorkommen würde, die Sternenzauber explizit nannte, sondern zunächst bei kleineren Auflösungen auffallen sollte.
Wenn du schreibst
seit geraumer Zeit wird zwischengespeichert beim Abspielen von 4k Videos von der externen Festplatte
heißt das, dass es zuvor nicht der Fall war? Die naheliegende Frage ist dann selbstverständlich: was hat sich geändert inzwischen?
Genau: https://forum.kodi.tv/showthread.php?tid=376161
Manches der Diskussion zu Bandbreiten kommt mir etwas wirr, wenig definiert, unnötig kompliziert gemacht durch Wechsel der Einstellungen, Jumbo-Frames und mehr vor. "Viel hilft viel" ist nicht immer richtig. Dauert nur wenige Minuten, das etwas kontrollierter nachzumessen und zu prüfen/dokumentieren ob/wie Änderung der Einstellungen hilft. Die Defaults sind per se nicht schlecht (Ausnahme ist Audio für Fire-TV was neuerdings leider Anpassungen an advanced-settings benötigt).
Donald Knuth: "premature optimization is the root of all evil"
Ich habe 19MBit´s was ca. 150Mbps entspricht
Vermutlich meinst du 19 MByte/s und 150 Mbit/s. Sehe hier im Thread viele verschieden Schreibweisen/Einheiten zu den Geschwindigkeiten. Bitte viel Sorgfalt verwenden, das eindeutig auszudrücken. Die Erfahrung zeigt, dass man sich hier leicht missverstehen kann. Auch ist beim Nachlesen des Threads nicht immer klar, welche Messungen sich auf USB-LAN Adapter beziehen, welche auf WLAN. Und wenn ich
Unter NFS (Protokoll 4) bekomme ich beim kopieren zum Cube ca. 22Mbit/s wenn ich vom NAS auf ein anderen Datenträger kopiere ca. 11Mbit/s. Filme ab 80mbit ruckeln da leider.
muss ich vermuten, dass da auch einiges durcheinander gekommen ist. Wenn nur 11 Mbit/s irgendwo zustande kommen, läuft vermutlich was schief (in den Einstellungen, oder grundsätzliche Fehler im Netzwerk, oder schlechte Connectivity/große Entfernung/viel Fremdverkehr im WLAN). Wenn 11 MByte/s gemeint sein sollen, ist das eine in etwa zu erwartende Geschwindigkeit bei 100 Mbit/s Ethernet Connect (über LAN-Kabel):
DivX Plus sollte eine kommerzielle Alternative zu dem "normalen" h264 werden,
Auch "normales" H264 ist ein kommerzieller Standard, geschützt durch Patente und gebührenpflichtig.
Wobei ich mich da schon frage, ob es Vereinbarungen gibt bzgl. der Open-Source Implementierungen (x264) und deren Nutzung in Programmen wie VLC, Kodi, ffmpeg. Oder einfach geduldet? Bei H265 hatte man da ja auch öfters Mal von Streitereien gelesen, weswegen wohl aktuelle Windows Rechner per Default H265 nicht abspielen können.
Bei VP9 kann man ja überall lesen, dass zwar durch Patente geschützt, Google aber gebührenfreie Nutzung garantiert. Ähnlich AV1.
David Lynch 1946 - 2025
RIP
Ein kleine bebilderte Werkschau - nix tiefgreifendes, dennoch nett durchzublättern: David Lynch ist tot: Surreale und düstere Ästhetik – Rückblick auf die berühmtesten Werke des Regisseurs - DER SPIEGEL
"Mullholland Drive" ist aktuell in die Flatrate von Magenta-TV aufgenommen worden. David Lynch schrieb auch das Drehbuch. Beste Regie beim Filmfestival in Cannes. Ich hab's mir vorgemerkt, nochmals zu sehen.
Nun hast du offenbar weitere Einstellungen geändert *bevor* du die Checks gemacht hast (CPU, Files in transcoding-tmp, ...), Ich sehe z.B.: EnablePlaybackRemuxing: False. Damit wird ffmpeg nicht mehr aufgerufen, die temporären Files für HLS werden nicht erzeugt, das ffmpeg-Logfile wird nicht erzeugt. Mir scheint, der emby-Client auf dem Samsung TV kann den Film ohne Remuxing einfach nicht abspielen. Hatte ich auch so befürchtet oben. Daher könnte es hilfreich, die genannten Checks mit den alten Parametern zu machen.
Den Vorschlag von Publish3r oben zu wiederholen mit den veränderten Einstellungen könnte auch noch Sinn machen. Evt. auch wandeln in .ts (weil halt HLS auf ts basiert, und Emby Server das laut früheren Logs für notwendig hielt). Wandeln in .ts geht mit ffmpeg, z.B. sowas wie /bin/ffmpeg -i "/Movies/22 Kugeln.mp4" -map 0 -c copy -copy_unknown "/Movies/22 Kugeln.ts" (ungetestet, nur erschlossen aus deinem Log).
Wird schon lange diskutiert:
PDF-Dokumente als Angriffsvektor | heise online
Werde auch mal drauf achten, ob typische PDF-Formulare funktionieren, wenn man JS sperrt. (Viele der "intelligenten" PDF-Files nerven eh, sind klobig in der Bedienung, überkorrekt in der Inhaltsüberprüfung wie keine Leerzeichen, +, Klammern in Telefonnummern, IBANs, ... Aber keine Ahnung, ob für solche Formulare wirklich JS genutzt wird)
Eine Herausforderung: Doom für TeX - eine Turing-komplette Sprache genutzt insbesondere für zahllose wissenschaftliche Artikel, Zeitschriften und Bücher. TeX – Wikipedia
Und für Emacs.
Danke. Interessante Herstellerseite bei Innopia. U.a. "Deutsche Telekom MagentaTV One (3. Gen)" und auch Benchmarks verlinkt für Stick. Dort steht auch tatsächlich als CPU Synaptics VS640.
das Ding wird wirklich für die Teledoof hergestellt.
Klar, merkt man ja schon am T auf Dons Foto und am Datenblatt. Meine Frage wollte ja darauf hinaus - von wem? Ist bei den Speedport-Routern auch ähnlich - Telekom tritt als Hersteller auf. Hergestellt werden/wurden sie dann von Arcadyan, AVM, Huawei, Sagemcom, Siemens, .... (Wobei es wohl auch da grundsätzliche Unterschiede sind - minimal modifizierte Fritzbox mit Telekom Branding vs. wohl explizit für Telekom entwickelt und nicht unter anderem Markennamen bei Mediamarkt und Co erhältlich. Vielleicht jedoch schon bei anderem Internet-Provider in ganz anderem Land)
Bei T-Phone kann man aber auch lesen "Eigenentwicklung in Zusammenarbeit mit Google" und hergestellt von Wingtech. Man würde vermuten, der Eigenentwicklungs-Anteil konzentriert sich auf die Anforderungen
Ist aber letztlich nicht so entscheidend - interessierte mich einfach.
Ich habe mir mal das Datenblatt angesehen https://www.telekom.com/resource/blob/…-stick-data.pdf. Da steht: "Hersteller Telekom Deutschland GmbH". Weiß jemand, wer der eigentliche Hersteller dahinter ist? Oder ist das wirklich ne Eigenentwicklung? Schwer vorstellbar ...
Prozessor Synaptics VS630-XMED, A55 Quad, 24k DMIPS
Kennt ihr den Prozessor? Ist der in anderen bekannten Medienplayern/Geräten drin? Habe jetzt auf Anhieb keinen Benchmark gefunden (bis auf die DMIPS Angabe hier).
Leider funktioniert der Stick nicht mit altem Magenta TV 1. Gen Tarif. Selbst hadere ich mit der Umstellung, da man mit dem alten Tarif bei vielen Kanälen noch kein DRM hat und damit problemlose Aufnahme möglich ist (auch mit 5.1 Ton, im Ggs. zu Mediatheken / offiziellen ÖR Streams, wo das nicht möglich ist).
Wenn ihn jemand kauft, bitte gerne hier berichten - insbesondere wie Kodi läuft und ob Sprachsteuerung mit Kodi funktioniert.
Kannst ja so wie ich mindestens 2 davon hintereinander stecken, und schauen, was das erste anzeigt (nämlich den Verbrauch des zweiten). Zur Konsistenzprüfung dann noch hinten und vorne vertauschen. Falls die Leistung zu niedrig ist, damit das "anspringt" kannst du kleinen Verbraucher dran hängen - z.B. USB Ladegerät mit 5 W oder so.
(Mein Shelly Plug S Plus springt bei 0,4 W an, zeigt dann aber konsistente Werte zum klassischen Messgerät - wenn das klassische Messgerät 0,3 anzeigt, hängt der Plug auf 0,0. Mir ist schon klar, dass es in dem Bereich heikel wird bzgl. Genauigkeit ...)
Wenn du oder sonstwer Intersse hat: Um Messgenauigkeit der Plugs wenigstens einigermaßen zu beurteilen, können ohmsche Verbraucher dienen. Die wenigen Glühbirnen, die ich noch (für diese Zwecke) habe scheinen sehr nahe und konsistent an der aufgedruckten Leistung zu liegen. Auch Wasserkocher und Toaster (die sieht man dann auch gut auf einem Gerät wie Shelly 3EM, dessen Genauigkeit man mit dem Stromzähler plausibilisieren kann). Persönlich habe ich dann auch 2 Glühbirnen über Mehrfachstecker genommen - zeigt ob die Summe auch nah an den Einzelmessungen liegt.
Hatte oben die Bitte
Vielleicht können einige von euch auch eigene Erfahrungen/Messungen beisteuern, auch mit anderer Funktechnik.
vorgetragen. Rückmeldungen nach über 1 Woche: exakt 0 Messungen. Finde ich bisschen schade, daher nochmals die Erinnerung, ob das nicht jemand mal schnell bei sich messen kann. Zwei Geräte (mit hinreichend Empfindlichkeit) genügen. Ich weiß ja, dass einige die hier im Smarthome-Forenbereich unterwegs sind, mehrere solche Plugs haben, und sicherlich auch manche klassische Energie-/Leistungs-Messgeräte. Um der Bitte nachzukommen muss man ja auch nicht zwingend mein Interesse an dem Overhead der Geräte teilen, sondern kann es als kleinen Gefallen an anderen Forenteilnehmer sehen.
Auch nicht abschrecken lassen durch langen Text/meinen komplizierten Aufbau. Dadurch konnte ich bisschen die Messgenauigkeit steigern und Konsistenz/Plausibilität prüfen und auch prüfen, ob der Energieoverhead von der Verbraucherlast abhängt. Hat auch gezeigt, dass die Plugs selbst konsistente Daten zu den beiden traditionellen Leistungsmessgeräten zeigten und dass auch zeitliche Schwankungen/Rauschen gering sind. Quantifizieren will ich aber die Genauigkeit keinesfalls.
Noch kleine Beobachtung am Rande: Die 6-fach hintereinander gesteckten Plugs wurden bei mir deutlich handwarm. Im Vergleich dazu: mein ca. 250 ml Mini-PC ohne Last (aber laufend mit paar selbstgeschriebenen Serveranwendungen) wird nicht fühlbar wärmer, als Zimmertemperatur.
