Hallo zusammen, hallo Rudi,
ich würde mich freuen wenn direkter MIME-Support für MP3-Dateien aufgenommen werden könnte. Aktuell werden diese (über einen Fallback) als text/mp3 ausgeliefert. Browser (zumindest mein aktueller Chrome) zeigen dann binary babble an, aber keinen Player für Mediendateien. Ein einfacher Fix für dieses Problem wäre folgender Patsch (https://bitbucket.org/christoph-morrison/fhem-patches/raw/0b7b63d041f3da637a72ce2aa38e84a967832dc4/FHEM/HttpUtils.pm/oxooM7Choh.patch):
diff --git a/fhem/FHEM/HttpUtils.pm b/fhem/FHEM/HttpUtils.pm
index 057e4d23f..747de2fab 100644
--- a/fhem/FHEM/HttpUtils.pm
+++ b/fhem/FHEM/HttpUtils.pm
@@ -22,7 +22,7 @@ my %ext2MIMEType= qw{
png image/png
svg image/svg+xml
txt text/plain
-
+ mp3 audio/mpeg
};
my $HU_use_zlib;
(Alternativ habe ich auch noch ein umfangreicheres MIME-Handling (https://bitbucket.org/christoph-morrison/fhem-patches/raw/0b7b63d041f3da637a72ce2aa38e84a967832dc4/FHEM/HttpUtils.pm/oogahd4oB3.patch) anzubieten. Dazu muss aber File::MimeInfo installiert sein ...)
Habs eingebaut.
Das heisst aber nicht, dass FHEMWEB ein Mediaserver ist, und ich habe auch keine Plaene in diese Richtung.
Danke. HTTPSRV sollte aber schon Files mit dem richtigen Content-Type ausliefern (können), egal was man dort serviert, findest du nicht? War nun eher Zufall, dass es MPEG-Files sind, bei denen mir das aufgefallen ist.
ZitatHTTPSRV sollte aber schon Files mit dem richtigen Content-Type ausliefern (können)
Content-Type hilft nicht, wenn der Abspieler ressourcenschonend erst mit HEAD nach der Groesse fragt, dann mit Range die ersten und die letzten Bytes liest, und dann den Rest, stueckweise, mit Range. Kenne ich, habe ich fuer Android implementiert, und ich wollte damit hier nicht auch anfangen.
Btw: Ich habe noch nie den Sinn von HTTPSRV verstanden: was kann der anders/besser als FHEMWEB?
Zitat von: rudolfkoenig am 27 Juli 2018, 09:59:37
Content-Type hilft nicht, wenn der Abspieler ressourcenschonend erst mit HEAD nach der Groesse fragt, dann mit Range die ersten und die letzten Bytes liest, und dann den Rest, stueckweise, mit Range. Kenne ich, habe ich fuer Android implementiert, und ich wollte damit hier nicht auch anfangen.
Mag sein, aber absichtlich einen falschen Content-Type-Header zu setzen bringt es halt auch nicht.
Zitat von: rudolfkoenig am 27 Juli 2018, 09:59:37
Btw: Ich habe noch nie den Sinn von HTTPSRV verstanden: was kann der anders/besser als FHEMWEB?
Keine Ahnung, es ist mir bei einem Test mit HTTPSRV aufgefallen. Ich liefere meine aufgezeichneten Webradio-Clips über FHEMWEB aus, allerdings hab ich da ja das gleiche Problem - bzw. hatte, dank deinem Update ja nun nicht mehr.
Vielleicht die Möglichkeit eine eigene Index-Seite hinterlegen zu können?