WiiM, MinimServer & BubbleUPnP

simbun

Major Contributor
Joined
Mar 4, 2023
Messages
781
Has anybody managed to get WiiM to play files natively from MinimServer using a control point other than WiiM?
Every file (FLAC, MP3, AAC) I try and play results in 'Invalid MIME-type or resource not find (code: 714)' from both BubbleUPnP and Hi-Fi Cast.
If I transcode them (which I typically do to apply replaygain) it's fine, if I play the same files through AssetUPnP it's fine, if I use the WiiM app to browse MinimServer they're fine, it's just not using another control point!
I'll try and dig into it some more, get some logs of what's going on, but I've seen MinimServer mentioned on this board a number of times and I can't believe everyone is doing it via the WiiM app.
 
Just tried it playing flac from Minimserver using BubbleUPNP to my WiiM Pro and it’s playing as expected.

Edit: I’m on Minimserver 2.2 update 238, with the following vanilla profile:

.autoUpdate = true
contentDir = {/volume1/music/Sneaky Music}{/volume1/music/My Music}{/volume1/music/_Playlists}{/volume1/music/Radio Playlists}
indexTags = Artist, Date, Genre, All Artists, Composer, Conductor, Orchestra, #AudioData:Quality, #AudioFormat:Format, #AudioChannels:Channels, *RecentAdded, *RecentPlayed
.logLevel = verbose
serverOptions = recentAdded=1000, indexArtwork=auto
tagFormat = Artist.displayFormat={$artist$orchestra$conductor}
tagOptions = Album.sortTags={Album, Artist}
.profileVersion = 2.2

Maybe try creating a profile with those contents, edited for your content folders obviously…
 
Last edited:
I use minim-server for several years and it works flawlessly with bubble, hifi-cast, vlc, wiim-app, etc. etc.. All files including flac are played properly and the access structure is the same everywhere (this was previously configured under windows). Installed on QNAP NAS.

Attachments showing hifi-cast and bubble access structure
 

Attachments

  • Screenshot_20230304-213322.png
    Screenshot_20230304-213322.png
    39.7 KB · Views: 16
  • Screenshot_20230304-211808.png
    Screenshot_20230304-211808.png
    87.2 KB · Views: 17
Last edited:
I should have said that I'm trying it with the WiiM mini (pro still unavailable) if that makes any difference.
I have the problem with my main MinimServer instance on a RPI4 and my test instance on Windows 10, both update 238. I've actually reset the test instance to:

contentDir = D:\WiiMTest
indexTags = Artist, Date, Genre, All Artists, Composer
.profileVersion = 2.2

and I've just removed all but the most basic of tags, and added artwork as I usually store them externally just to see if it makes any difference, but exactly the same error message.

This is frustrating, MinimServer has been solid as a rock for years.
It seems to start streaming (I only know this from the MinimServer log, there's no playback at all), and then it cleanly closes the connection.

Hmmm. Struggling for things to try given the WiiM app works!
 
...no problems streaming from NAS to WiiM mini and Pro, Arylic devices. Earlier, when they were still used, it also worked flawlessly to Panasonic AllPlay devices.
 
I've just compared a MinimServer trace log from a BubbleUPnP play and one from WiiM, and other than the connection getting closed, one thing I wasn't expecting to see (maybe I'm wrong) was where the request originated.

With the BubbleUPnP trace I see:
20:48:32.718 Thread-7: HTTPService: accepted incoming connection
20:48:32.719 Thread-7: HTTPService: waiting for incoming connection
20:48:32.719 Thread-6: HTTPService: received request, Socket[addr=/[COLOR=rgb(184, 49, 47)]192.168.20.143[/COLOR],port=39836,localport=9790]
20:48:32.719 Thread-6: HTTPService: adding connection org.jminim.lib.HTTPConnection@64303eeb
20:48:32.719 Thread-221: HTTPConnection: writer thread waiting for request
20:48:32.719 Thread-222: HTTPConnection: reading HTTP request

From the WiiM app I see:
20:49:22.824 Thread-7: HTTPService: accepted incoming connection
20:49:22.824 Thread-7: HTTPService: waiting for incoming connection
20:49:22.824 Thread-6: HTTPService: received request, Socket[addr=/[COLOR=rgb(209, 72, 65)]192.168.20.139[/COLOR],port=43156,localport=9790]
20:49:22.824 Thread-6: HTTPService: adding connection org.jminim.lib.HTTPConnection@9bfbe51
20:49:22.824 Thread-231: HTTPConnection: writer thread waiting for request
20:49:22.824 Thread-232: HTTPConnection: reading HTTP request

.139 is the WiiM mini (as I expect it to be as it should be the WiiM that is requesting the file) but .143 is my phone! I've just made sure that any BubbleUPnP (app) decoding is disabled as is BubbleUPnP Mime checking, but get the same thing.

I don't suppose any of you know how to perform a trace in MinimServer do you? If you do, you just need to set it to Trace just before you start the track, then, once it's started, set the logging level back to Info and check to see if you see the phone/tablet ip there rather than the WiiM. Maybe that's normal...
 
Actually ignore that, I just traced a play to another renderer and it does originate from the phone but then connects to the renderer, something I don't see with my trace to the WiiM.

Will have to sleep on it.
Thanks for listening.
 
I’m not au fait with all the BubbleUPNP settings, I probably defaulted them all, but under renderer settings, I do have FFmpeg audio decoding set to the second option to use decoding for “audio formats not natively supported by the renderer” - do you have that turned off?
 
Unfortunately it's been years since I configured the server, here's what I had documented back then:

SERVER

contentDir: /share/01_Music

displayName: QNAP-MinimServer

indexTags: Artist, Genre

mergeFolderAlbums: false

tagOptions: Album.sortTags={artist,album}


==========================================

ADVANCED

showExtras: true

startupScan: true

tagCustom: AlbumArtist.displayRole={artist}


==========================================
SYSTEM

.autoUpdate: true

http.port: 9790

.logFile: /share/Public/minimserver.log

ohnet.debug: Default

ohnet.port: 9791

.updateReminder: 1
 
I’m not au fait with all the BubbleUPNP settings, I probably defaulted them all, but under renderer settings, I do have FFmpeg audio decoding set to the second option to use decoding for “audio formats not natively supported by the renderer” - do you have that turned off?
It was at the defaults originally, but I turned it off towards the end hoping that BubbleUPnP might give a more meaningful error message. I typically turn it off so it doesn't silently get transcoded by the phone as I'd prefer to have MinimServer do it than my phone (or BubbleUPnP server).
 
Unfortunately it's been years since I configured the server, here's what I had documented back then:
...
I'm pretty sure it's not MinimServer related.

I do make use of vlans, but the WiiM, MinimServer and the phone are all on the same one (can't get UPnP working across vlans unlike mDNS for google cast) so it shouldn't be that, but I'll try and take it to my brothers around the corner to see if it works on a flat network, and if that works I'll try and do some network captures.

I keep coming back to the fact that it works through the WiiM app; It doesn't make any sense :)
 
@WiiM Support

I think I've found the bug.
It seems to be that if there's a dot in the filename (in addition to the dot before the file extension) and there are fewer than 4 characters between it and the final dot then WiiM fails with the MIME type error, and given that my filenames are discnumber.tracknumber it was failing on all of them, but not the transcoded ones because they were suffixed with $!transcode.wav

AssetUPnP was working because it doesn't pass the actual filename, it uses some internal hash like structure.

So I guess they have different logic paths, because the WiiM app was addressing the files directly from MinimServer just fine!

Not sure why they're even processing the file extension as they'll have already been sent the MIME-type, but who knows!

I've replied with this information on a ticket I raised over 7 months ago (where I'd supplied a test album with this problem), but is there a better route?
 
Good bit of debugging - hopefully armed with this WiiM can provide a quick patch.
I agree but the idea to use . in file names except as the suffix delimiter is a bit iffy in the first place. What tagging software allowed that?

This schema may present problems elsewhere (it would in anything Windows) so perhaps the right thing to do is to correct the file names and replace with underscores or similar.
 
I agree but the idea to use . in file names except as the suffix delimiter is a bit iffy in the first place. What tagging software allowed that?
I primarily use EAC and foobar, but also Mp3Tag, dBpoweramp and Picard and they all allow it, I don't know why you'd think otherwise. Do you know of a tagging application that doesn't allow them, and removes them from filenames?

This schema may present problems elsewhere (it would in anything Windows)
I don't think I've ever encountered a Windows application that hasn't allowed them (or certainly not in the last decade or two), can you give me some examples.
 
I primarily use EAC and foobar, but also Mp3Tag, dBpoweramp and Picard and they all allow it, I don't know why you'd think otherwise. Do you know of a tagging application that doesn't allow them, and removes them from filenames?


I don't think I've ever encountered a Windows application that hasn't allowed them (or certainly not in the last decade or two), can you give me some examples.
On reflection I think you are probably right that Windows wouldn’t complain these days but I come from a long way back when 8.3 was the rule in Windows.
I use all of the same tools but I have seen any of them try to write a file name with a dot like that.
 
Back
Top