Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 7 of 7
  1. #1
    Junior Member
    Join Date
    Nov 2013
    Posts
    5

    Stream not working after update

    Hi everyone First of all - many thanks for the amazing products, you guys are the best!

    I have a small issue:

    After an update from 7.9.2 to the version below, there are a small number of manually entered streams (in the Tune In url menu) that don't work anymore. I get:

    [20-05-25 10:47:06.1321] Slim::Player::Song:pen (409) Error: Couldn't create command line for application/octet-stream playback for [http://zeddigital.blob.core.windows....-10-16-00.mp3]

    http://zeddigital.blob.core.windows....5-10-16-00.mp3

    Some other still work. I thought maybe the station changed something, but I'm currently listening on my old 7.9.1 installation on another computer. Any idea what could have caused this? Another piece of the puzzle is that I had installed bpa's PlayHLS at the same time?
    Thanks heaps
    Simon

    ---------------
    Logitech Media Server Version: 7.9.3 - 1589867173 @ Wed May 20 04:08:01 WEDT 2020
    Hostname: riko
    Server IP Address: 10.1.1.5
    Server HTTP Port Number: 9000
    Operating system: Windows 10 - EN - cp1252
    Platform Architecture: 8664
    Perl Version: 5.14.1 - MSWin32-x86-multi-thread

  2. #2
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    18,864
    PlayHLS has nothing to do with this issue.

    I think the problem is a result of a change to LMS. There were AAC stream which had a MIME type of AAC but extension of mp3 - which LMS incorrectly tried to play as mp3.

    Your stream is an MP3 stream with an extension of mp3 but with a MIME type of application/octet-stream. This MIME type is not a standard supported type (i.e. LMS doesn't know what it means) and so LMS fails to play the stream. In cases of MIME type / extension contradiction, I thought LMS "probed" the stream but perhaps not .

    Workaround is to have a custom-types.conf file adding "application/octet-stream" to mp3 with the following lines.
    Code:
    mp3     mp2,mp3         audio/mpeg,audio/mp3,audio/mp3s,audio/x-mpeg,audio/mpeg3,audio/mpg,application/octet-stream audio
    Alterntaively you could manually edit the types.conf file and add "application/octet-stream" to the mp3 line but this change would be lost with each LMS update.

    Any change to fix this issue in LMS will probably only be implemented in 7.9.3 and 8.0

  3. #3
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    5,824
    in Scanner::Remote::ReadRemoteHeader there is no case handling mimetypes application/octet-stream. I've not tracked the code difference between 7.9.1 and 7.9.3 but obviously for nasty server not setting properly Content-Type. It's either a test to be added in Scanner::Remote.pm when content-type is octet-type (unknown) or it's a change to Music::Info::SetContentType which seems to be happy with octet-stream and does not use typeFromPath. I've submitted a patch, or maybe Michael will return to a previous solution that I don't know
    Last edited by philippe_44; 2020-05-25 at 02:19.
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

  4. #4
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    18,864
    Quote Originally Posted by philippe_44 View Post
    in Scanner::Remote::ReadRemoteHeader there is no case handling mimetypes application/octet-stream. I've not tracked the code difference between 7.9.1 and 7.9.3 but obviously for nasty server not setting properly Content-Type. It's either a test to be added in Scanner::Remote.pm when content-type is octet-type (unknown) or it's a change to Music::Info::SetContentType which seems to be happy with octet-stream and does not use typeFromPath.
    I think any processing should be based on what is defined in types.conf - no assumption to be made in any undefined types or suffixes.
    My inclination is that if a MIME type is not defined in types.conf but the suffix matches one defined in types.conf - then the suffix type should be used.

  5. #5
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    5,824
    Quote Originally Posted by bpa View Post
    I think any processing should be based on what is defined in types.conf - no assumption to be made in any undefined types or suffixes.
    My inclination is that if a MIME type is not defined in types.conf but the suffix matches one defined in types.conf - then the suffix type should be used.
    I investigate a bit after my post and it seems that at some point, when LMS parses the headers of a remote stream, if application/octet-stream is found as a content-type but the stream has a recognized extension, then the extension prevails to set the type of audio. But that "prevails" was not fully made, so in the case of the OP, it was failing.

    Code:
    sub isSong {
    	my $pathOrObj = shift;
    	my $type      = shift;
    
    	if (!$type) {
    		$type = _isContentTypeHelper($pathOrObj, $type);
    	}
    	elsif ($type eq 'application/octet-stream') {
    		$type = _isContentTypeHelper($pathOrObj);
    	}
    
    	if ($type && $slimTypes{$type} && $slimTypes{$type} eq 'audio') {
    		return $type;
    	}
    }
    That isSong is called by Utils::Scanner::Remote::readRemoteHeaders as a "last" check, but the return value was not used
    Last edited by philippe_44; 2020-05-25 at 10:23.
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

  6. #6
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    18,864
    Quote Originally Posted by philippe_44 View Post
    I investigate a bit after my post and it seems that at some point, when LMS parses the headers of a remote stream, if application/octet-stream is found as a content-type but the stream has a recognized extension, then the extension prevails to set the type of audio. But that "prevails" was not fully made, so in the case of the OP, it was failing.
    Interesting that MIME application/octet-stream is embedded in code and not in types.conf - must remember that.

  7. #7
    Junior Member
    Join Date
    Nov 2013
    Posts
    5

    Thanks! ;)

    Thanks all! The custom-types.conf did the trick. My local (and favourite) radio station must have changed that MIME header recently.

    And once more - a general thanks, both for the quick replies but also for your efforts to keep the entire system alive. Especially bpa's BBC plugins are constantly used.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •