Fix to support flac playback with foobar2000 for Android/Windows

[tesshucom]

Problem description

Flac playback is not possible on foobar2000 for Android/Windows.

The cause is incorrect ContentType. Unlike BubbleUPnP, which is a relatively strict specification, foobar2000 relies on http headers for codec branching in both Windows and Android versions. If the stream's binary is FLAC, but the content type is not audio / flac, foobar2000 will treat it as file corruption.

Steps to reproduce

Play a flac stream without mp3 transcoding on foobar2000 (Android/Windows).

System information

• Jpsonic version: This bug is derived from Airsonic. Complex bug

[tesshucom]

In previous implementations, audio/mpeg was returned for anonymous connections that requested FLAC without transcoding(On jpsonic, In the case of annoymous user, application / octet-stream may be returned depending on the data). This issue is common to Rest / UPnP. But client applications that do not reference content types will not fail and may mask the issue. Also, in the Subsonic app, which basically always includes the preferred format in the request parameter, the problematic case is obscured, so you do not notice the problem.

This fix will fix audio/flac to be returned.

There are related two causes. The former is a Jpsonic specification. The latter is an Airsonic problem.

• "Jpsonic ignores the player requested by the anoymous connections that have the same segment as the server." This logic is encapsulated in a transcoding service now.
• According to the traditional implementation, the stream content type is calculated by referring to" the transcoder assigned to the player requested" at the time of the request and the file suffix. This is a latent bug. The transcoder used to generate the stream is It has already been determined in the before block this process is executed. The content type may not match the actual format unless it is also calculated using the determined transcoder.

We can get the expected behavior by fix the latter correctly, regardless of anonymous connection specifications.

[tesshucom]

Test cases will be added to clarify the cases covered by bug fixes. It's complicated, so I'm reviewing it.

[tesshucom]

The modified case is the case where the format is not specified by the request, and Unlimited bitrate. In this case, the Transcoding Service should determine that no formatting is required. (TranscodingService#isNeedTranscoding)

At this time, StreamController needs to return the binary as a response in the original format. For FLAC, it remains FLAC. The Content-Type must be determined using the file Suffix. (The extension determination is subtle here, but it probably doesn't matter because the extension determination is done in advance by JaudiotaggerParser # isApplicable.).

Therefore, there should be no problem with the correction contents.

By the way, the cases fixed in this test(StreamControllerTest#c5, c5a) are virtually non-reproducible in the Subsonic App. By design, the parameter format is nullable, but existing Subsonic Apps usually will specify mp3 by default, or can be selected.

On the other hand, for protocols other than Subsonic Apps, you may need to be careful because the format is not specified at all by the request. Whether or not it is judged as an error like foobar2000 depends on the design of the client.