FHEM nutzen um mp3 Dateien an dlna Server (Radio) zu streamen?

[mumpitzstuff]

Ich benötige für das SIRD Modul eine Möglichkeit mp3 Dateien an ein Radio auszuliefern. Ich habe das jetzt über einen kleinen HTTP Server geschafft (das ist die erste Version die mal funktioniert hat):

Code Auswählen Erweitern

#!/usr/bin/perl

use strict;
use warnings;
use HTTP::Daemon;

my $d = HTTP::Daemon->new(LocalPort => 5000) or die $!;
while (my $c = $d->accept)
{
  while (my $r = $c->get_request)
  {
    print $r->method."\n";
    if ('HEAD' eq $r->method)
    {
      $c->send_header('Content-Type', 'audio/mpeg');
      $c->send_response(200, "ok");
      $c->send_header('Access-Control-Allow-Origin', '*');
      $c->send_header('Access-Control-Allow-Methods', 'GET, OPTIONS');
      $c->send_header('Access-Control-Allow-Headers', 'X-Requested-With');
      $c->send_header('Access-Control-Allow-Headers', 'Content-Type');
      #$c->send_header('Content-Type', 'audio/mpeg');
    }
    $c->send_file_response("/home/pi/1.mp3") if ('GET' eq $r->method);
  }
  $c->close;
  undef($c);
}


Meine nächste Idee war nun, das nicht über einen separaten Server zu machen, sondern gleich über FHEM. Ich habe daher ein mp3 file nach /opt/fhem/www/images/axe.mp3 kopiert und kann diese Datei über http://192.168.1.x:8083/fhem/www/images/axe.mp3 auch abrufen. Wenn ich diese URL dann an das Webradio weiter reiche, dann scheitert es zunächst daran, dass das Radio einen HEAD request abschickt und FHEM diesen unbeantwortet lässt. Mit allowedHttpMethods kann ich nun HEAD aktivieren und erhalte dann auch keine Fehlermeldung mehr im Log:

Code Auswählen Erweitern

2018.05.10 23:18:26 3: WEB_192.168.1.x_57396: unsupported HTTP method HEAD, rejecting it.

Leider scheint aber im HEAD request kein Content-Type mitgeschickt zu werden, den braucht das Radio aber unbedingt. In meinem Script ist das die Zeile:

Code Auswählen Erweitern

$c->send_header('Content-Type', 'audio/mpeg');

Ist meine Vermutung richtig und wenn ja, in welcher Funktion könnte ich mal testweise versuchen den Content-Type mitzuschicken? Im Log sehe ich leider nicht viel wenn das Radio den HEAD request los schickt:

Code Auswählen Erweitern

2018.05.11 00:24:56 4: Connection accepted from WEB_192.168.1.x_57399
2018.05.11 00:24:56 4: Connection closed for WEB_192.168.1.x_57399: EOF

Ist es überhaupt sinnvoll das so machen zu wollen? Soweit ich das mitbekommen habe, sollte FHEM die mp3 Datei problemlos streamen können ohne alles andere zu blockieren. Oder ist die Annahme grundsätzlich falsch und sollte ich das Ganze lieber gleich vergessen?

[rudolfkoenig]

Content-Type wird in HttpUtils.pm gepflegt.

Zu einem Streaming Server gehoert neben Implementierung der HEAD Methode die Dateien mit dem bestellten Offset und Laenge auszuliefern.
Das ist in FHEMWEB nicht implementiert.