MinimServer Forum

Full Version: Cannot browse FLAC files on Android Hiby Music app
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
when using Android Hiby Music app as a dlna renderer, I cannot see any of my flac files.

From what I gathered so far, it seems to be related to the mime type passed by minimserver (audio/x-flac).
When browsing for flac files, Hiby Music app reports:
Quote:2019-07-28 02:11:52,184 [ERROR][ 1674 (Active: 5)] - Audio name: Aus tiefer Noth schrei ich zu dir, Cantate BWV 38 is not support MimeType audio/x-flac

And looking at Minim Server logs it indeed shows that flac files are advertised with audio/x-flac mime type:
Quote:[...] <res duration="0:05:01.520" size="6756678" bitsPerSample="16" bitrate="176400" sampleFrequency="44100" nrAudioChannels="2" protocolInfo="http-get:*:audio/x-flac:DLNA.ORG_OP=01;DLNA.ORG_FLAGS=01700000000000000000000000000000"> [...]

Don't get me wrong: I am not suggesting Minim Server is not using the appropriate type (as you previously stated in this post) but rather that Hiby music player does not recognize audio/x-flac mime type.

I have already reported this to Hiby support, but in the meantime I was wondering if it is possible to force a different mime type for flac files. Using for instance the Custom MIME types feature in Server options.

Again to clarify: the issue arises when browsing the library and using another dlna player (such as Usb Android Player Pro) the flac files display correctly.

As it says in the description of custom MIME types, you can change the MIME type only for DSF and DFF files. This capability is needed for these specific types because there has been significant divergence between audio products over what MIME types should be used for these files. Fortunately, this divergence is now being resolved to an accepted industry standard (the default MinimServer values).

For other MIME types where established industry standards exist, MinimServer does not allow the MIME type to be changed. This is consistent with MinimServer's strict conformance to industry standards and specifications.
Thanks Simon,
guess I'll have to push for changes on Hiby's size.
In cases like this, it is better for a control point or renderer to support aliases than it is for the server to provide a way to change the value. If the server sends an incorrect value to compensate for a bug in one control point or renderer, this doesn't work if you also want to use other control points and renderers that implement the standard correctly. DSF/DFF is a special case because of some specific history around these types.
Reference URL's