Please add support for Opus in Jamstash

[ripdog]

Opus is a perfect fit for streaming via subsonic, but unfortunately software support is a bit lacking. Luckily, firefox supports it natively, and so does Jplayer.

I set up opus transcoding in subsonic, and it works fine, when I take stream URLs and access them in firefox. For whatever reason, though, it seems to download ~20kb of the stream, then ditch it and start a new download that does nothing - though I may be misinterpreting what I'm seeing on the dev tools network tab.

I took the 20kb that is downloaded, and after base64 decoding it, it does indeed have an OGG header, and my opusenc command line visible. It appears the download is simply cut off for some reason.

So, after playing around with manually resending the requests for the stream, the problem with the second request is that it has a range request. I guess the transcoding setup can't handle this, and so nothing comes through at all. Just need to find out why the download is cut off.

Jamstash appears to believe it is playing, the play/pause button stays as if it is playing and the page title continues scrolling.

My transcoding settings:

From: ogg mp3 oga aac m4a wav wma aif aiff ape mpc shn

TO: oga (opus fails similiarly)

Decode: ffmpeg -i %s -ab %bk -v 0 -f wav -

Encode: opusenc --quiet --bitrate 52 --downmix-stereo --title %t --album %l --artist %a - -

If you want, I'll be happy to give you access to my server to test, if you don't wanna bother changing your transcodes.

Thanks!

[ripdog]

Jplayer's opus support works fine, I stuck my subsonic stream URL into http://jplayer.org/latest/demo-01/ and it played fine.

[tsquillario]

Make me an account on your server to test. tsquillario [at] gmail.com

[ripdog]

Have you had a chance to have a bash at this?

[tsquillario]

Yea, I looked at it a few times. Everything seems to be configured correctly but I can't figure out why it isn't working! I'm able to do FLAC > MP3 transcoding and directly play .ogg files without transcoding. Not sure why your method isn't working.

[ghost]

Ping, has anyone tried this with the current version?

[RomanHargrave]

I'm having this issue with Opus streaming and am wholly confused as to why subsonic, or rather web browsers, seem allergic to everything but MP3 and FLAC streams.

If I give it (subsonic) Opus encoded audio in a WebM stream, it plays for a few seconds and gets confused about the file length and then gives up. Jamstash doesn't like this at all.

If I give it (subsonic or jamstash) opus encoded audio in an Ogg stream, nothing happens.

If I give DSub opus audio in an ogg stream, it's more than happy, since it justs feeds the stream to android MediaPlayer.

Obviously, my encoding pipeline works, but what the hell is going on in the browser. I'm going to jump to the "HTML5" audio API, since it's javascript and I hate javascript.

[ae-g-i-s]

Just a little input, since I just (unsucessfully) tried to get this working in the current git version and a relatively new Chrome. Had to sift through the code of Libresonic (Subsonic fork, but I'm pretty sure this part was not modified) and Jamstash to get the following insights:

• Your transcoding options in Subsonic/Libresonic must specify the format as "oga" or the Content-Type will be set incorrectly. You could also specify "opus" as far as the server side goes, but...
• Jamstash has severe limitations on the "suffix" returned, see app/player/player-directive.js:116. If it's not exactly "oga", it will not jump into the correct branch. If you set the format in Subsonic to "opus", it will not set up the media object correctly.
• Subsonic sends an incorrect Content-Range header. Firefox does not care, as soon as it detects this fact it just pretends like it doesn't know the stream duration (which for users just means that the stream becomes unseekable). Chrome does care, refuses to start playback and constantly spams ERR_CONTENT_LENGTH_MISMATCH. The same goes for mpv (console player backed by ffmpeg).

Since the following is not really relevant for the average user, the short Summary: Opus playback does not work in Chrome because Subsonic is broken and Chrome doesn't handle it too well.

---

Here's a few excerpts from mpv's log that should explain what's going on...

• Initial request

  [ffmpeg] http: request: GET /libresonic//rest/stream.view?... HTTP/1.1 [ffmpeg] User-Agent: mpv 0.25.0 [ffmpeg] Accept: / [ffmpeg] Range: bytes=0-

• Initial reply, note the Content-Length and Content-Range headers

  [ffmpeg] http: header='Server: nginx' [ffmpeg] http: header='Date: Wed, 06 Dec 2017 01:34:10 GMT' [ffmpeg] http: header='Content-Type: audio/ogg' [ffmpeg] http: header='Content-Length: 3720000' [ffmpeg] http: header='Connection: close' [ffmpeg] http: header='Accept-Ranges: bytes' [ffmpeg] http: header='Content-Range: bytes 0-3719999/3720000' [ffmpeg] http: header='X-Content-Duration: 155.0'

• Everything (kinda) good so far, ffmpeg probes the format and extracts the headers...and then it tries to fetch the rest of the stream, because it only got 3654693 bytes so far, not 3720000.

  [ffmpeg] http: request: GET /libresonic//rest/stream.view?... [ffmpeg] User-Agent: mpv 0.25.0 [ffmpeg] Accept: / [ffmpeg] Range: bytes=3654693-

• This is where it gets interesting. Subsonic should now return the remaining 65307 bytes (3654693 have already been sent, but not 3720000).

  [ffmpeg] http: header='HTTP/1.1 206 ' [ffmpeg] http: http_code=206 [ffmpeg] http: header='Server: nginx' [ffmpeg] http: header='Date: Wed, 06 Dec 2017 01:34:13 GMT' [ffmpeg] http: header='Content-Type: audio/ogg' [ffmpeg] http: header='Content-Length: 65307' [ffmpeg] http: header='Connection: close' [ffmpeg] http: header='Accept-Ranges: bytes' [ffmpeg] http: header='Content-Range: bytes 3654693-3719999/3720000' [ffmpeg] http: header='X-Content-Duration: 155.0'

• Well...no. The server lies. There is no content.

  [ffmpeg] http: Stream ends prematurely at 3654693, should be 3720000

• At this point, mpv/ffmpeg just endlessly tries to fetch the remaining bytes without ever succeeding.

Be advised that while this log shows the nginx reverse proxy, I also verified that this is not the source of the error (by repeating the request locally on the Libresonic server against the internal port with a specified range, which forces it to send the Content-Range header).

So in short, the Subsonic server is broken in the sense that it returns wrong Content-Length/Content-Range headers and then doesn't deliver the data. Note that the estimateContentLength parameter for stream.view is not set to true in my request (you just can't see that in the log above because I redacted the parameters).

I haven't debugged the issue enough to know whether this is a shortcoming of Subsonic or Tomcat itself, though I'd guess it's the former (since transcoding is specific to Subsonic).