MP3-Support für HttpUtils.pm

[Christoph Morrison]

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:

Code Auswählen Erweitern

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 anzubieten. Dazu muss aber File::MimeInfo installiert sein ...)

[rudolfkoenig]

Habs eingebaut.

Das heisst aber nicht, dass FHEMWEB ein Mediaserver ist, und ich habe auch keine Plaene in diese Richtung.

[Christoph Morrison]

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.

[rudolfkoenig]

HTTPSRV 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?

[Christoph Morrison]

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.

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?