UPnP 2025 - Continuation of the original UPnP/DLNA plugin

[jorgemg1984]

We can test if it's a network issue with foobar.

Download 32 bit - Foobar
download this - upnp plugin

Create  foobar folder somewhere.
Run the foobar installer and select portable install and set it to the foobar folder you created.
Run foobar
Goto File->Preferences
Components should be selected by default. Click install in the bottom right corner and selected the Upnp file you downloaded earlier and click apply.
Probably worth restarting foobar at this point.

Open musicbee and set foobar as the output device. Play a few tracks and see if it's gapless, if it isn't that points to an issue with the network more than the plugin, if it is gapless we are probably back to square one but at least it rules one possible problem out.

When you're done with foobar you can just delete the foobar folder.

OK, thanks!

[simbun]

We can test if it's a network issue with foobar.

Try your setup with the following tracks. I generated a tone in Audacity and split the resulting file into 3 tracks of 15 seconds (so it'll work with the MXN10).

Once you've tested MusicBee try with Hi-Fi Cast or mconnect using MusicBee as the source.

I think it's just that the foo_upnp plugin does a good job of making it sound gapless, even though it's not.

SHA1: bee74d247e6f8f8922ef5605dfc51e3973fb0335

[Casual Tea]

If you haven't already I would try the following
1. Make sure your firewall is not blocking anything.
2. check "Do not use raw PCM" and see how that goes, you should see L16 or L24 as the extension in the log instead of .WAV
3. If option 2 doesn't work, try and get it to play a native stream. Remove DSP/replaygain settings and adjust the profile to make sure it won't encode the file and see if that will stream ok.

1. isn't an issue.
2. led to a single song almost playing through (though the initialisation did throw a few errors:
Upmpdcli:

Code

Mär 03 14:00:57 pi3B upmpdcli[6282]: :2:../libupnpp/control/cdircontent.cxx:253::UPnPDirContent::parse: parser failed: duplicate attribute at line 1 column 1474 for:
Mär 03 14:00:57 pi3B upmpdcli[6282]: <DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:pv="http://www.pv.com/pvns/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/">>
Mär 03 14:00:57 pi3B upmpdcli[6282]: :2:../src/upmpd.cxx:300::checkContentFormat: didl parse failed
Mär 03 14:00:57 pi3B upmpdcli[6282]: :2:../src/mpdcli.cxx:336::mpd_run_clear(m_conn) failed: Connection closed by the server
Mär 03 14:00:57 pi3B upmpdcli[6282]: :3:../src/mpdcli.cxx:148::MPDCli::startEventLoop: already started
Mär 03 14:01:01 pi3B upmpdcli[6282]: :3:../src/upmpd.cxx:312::checkContentFormat: format check disabled

However shortly before the first song ended, the audio output stopped and by checking the logs, MPD is stuck (constantly repeating) with:
MPD:

Code

Mär 03 14:04:08 pi3B mpd[6518]: alsa_output: Decoder is too slow; playing silence to avoid xrun

Restarting mpd with

Code

sudo systemctl restart mpd

takes almost a minute but then the pi starts playing the second song (after I had already switched the output in MusicBee from the pi to a local sound device and stopped playback).

This is the plugin log:

Code

82988; 11 Profile - Generic Device, useragent=|Linux/6.1.21-v8+ UPnP/1.1 Portable SDK for UPnP devices/6.2.0
82994; 12 Profile - Generic Device, useragent=|Linux/6.1.21-v8+ UPnP/1.1 Portable SDK for UPnP devices/6.2.0
83012; 13 Activate - MaltePi3B-UPnP/AV:http-get:*:audio/L16:DLNA.ORG_PN=LPCM,http-get:*:application/flac:*,http-get:*:application/x-flac:*,http-get:*:application/ogg:*,http-get:*:application/vnd.apple.mpegurl:*,http-get:*:application/x-mpegurl:*,http-get:*:audio/flac:*,http-get:*:audio/x-flac:*,http-get:*:audio/aac:*,http-get:*:audio/x-aiff:*,http-get:*:audio/aif:*,http-get:*:audio/aiff:*,http-get:*:audio/dff:*,http-get:*:audio/x-dff:*,http-get:*:audio/dsd:*,http-get:*:audio/x-dsd:*,http-get:*:audio/dsf:*,http-get:*:audio/x-dsf:*,http-get:*:audio/m4a:*,http-get:*:audio/x-m4a:*,http-get:*:audio/matroska:*,http-get:*:audio/x-matroska:*,http-get:*:audio/mp1:*,http-get:*:audio/mp3:*,http-get:*:audio/mp4:*,http-get:*:audio/mpeg:*,http-get:*:audio/x-mpeg:*,http-get:*:audio/ogg:*,http-get:*:audio/vorbis:*,http-get:*:audio/x-ape:*,http-get:*:audio/ape:*,http-get:*:audio/x-monkeys-audio:*,http-get:*:audio/wav:*,http-get:*:audio/x-wav:*,http-get:*:audio/wave:*,http-get:*:audio/x-ms-wma:*,http-get:*:audio/x-ogg:*,http-get:*:audio/x-scpls:*,http-get:*:audio/x-vorbis+ogg:*,http-get:*:audio/x-vorbis:*,http-get:*:audio/x-wavpack:*,http-get:*:video/mp4:*
98037; 14 ForcedEncode - Stream is being encoded to apply Replaygain/DSP settings.
98052; 15 Play - Z:\M4\Laswell, Greg\Take a Bow\01 Take Everything.flac (http://192.168.1.5:49382/encode/DE3ED7364A42F6B8-2147483638.L16)
98110; 16 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
98113; 17 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
98190; 18 StateTimer - Playing,old=Stopped
102183; 19 ForcedEncode - Stream is being encoded to apply Replaygain/DSP settings.
102186; 20 GetEncodedFile[1] 192.168.1.5 - GET Z:\M4\Laswell, Greg\Take a Bow\01 Take Everything.flac to 192.168.1.13; mime=audio/L16;rate=44100;channels=2,rate=44100,channels=2
102230; 21 SetNextAVTransportURI - Success - http://192.168.1.5:49382/encode/05EF0936D53A40780.L16
105183; 22 GetEncodedFile[1] - exit=0, playtime=2991
168796; 23 StateTimer - Playing,old=Paused
287282; 24 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
287287; 25 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
287584; 26 GetEncodedFile[2] 192.168.1.5 - GET Z:\M4\Laswell, Greg\Take a Bow\02 My Fight (For You).flac to 192.168.1.13; mime=audio/L16;rate=44100;channels=2,rate=44100,channels=2
287656; 27 GetEncodedFile[2] - exit=0, playtime=67
349408; 28 PostSoapRequest - 500,send=POST /uuid-677a63db-6686-01d7-34a0-b827eb0b7fae/ctl-urn-schemas-upnp-org-service-AVTransport-1 HTTP/1.1
Host: 192.168.1.13:49152
User-Agent: MusicBee UPnP Plugin
Content-Type: text/xml; charset="utf-8"
SOAPAction: "urn:schemas-upnp-org:service:AVTransport:1#Pause"
Content-Length: 290

<?xml version="1.0" encoding="UTF-8"?><s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><u:Pause xmlns:u="urn:schemas-upnp-org:service:AVTransport:1"><InstanceID>0</InstanceID></u:Pause></s:Body></s:Envelope>
349413; 29 SoapRequest:Pause:urn:schemas-upnp-org:service:AVTransport:1:InstanceID=0 - <?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<s:Fault>
<faultcode>s:Client</faultcode>
<faultstring>UPnPError</faultstring>
<detail>
<UPnPError xmlns="urn:schemas-upnp-org:control-1-0">
<errorCode>501</errorCode>
<errorDescription>Action Failed</errorDescription>
</UPnPError>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>

349416; 30 Pause - status=500

3. works. I've tested it with 16/44.1 and 24/192 files without playback issues.
I had tried all of these before but it was pointless because I had not realized that mpd was stuck after the first test haha.

Note:
You should add an option to clear/update the nexturi when the playback queue is changed in MusicBee tho.
I was a bit surprised when the 2nd song I had removed from the playing queue in MB started playing on the pi anyhow.

So my guess is that mpd errors out because of the transcoded wav/pcm streams. Which is odd since mpd is very robust and usually swallows anything you throw at it, format-wise.
I can also confirm that it's not a device/hardware issue since the proxmox lxc debian container gets stuck in the same manner. And there MPD simply writes the incoming audio to a FIFO PIPE which snapserver then uses as the source for the 2 snapclients on the pis.

Edit:
I just noticed that MusicBee does not switch the song alongside the pi.
While the pi is already playing the 2nd song, MusicBee still displays the first one as playing.

Code

2126746; 121 Play - Z:\M2\Coldplay\X&Y 24-192\01 Square One.flac (http://192.168.1.5:49382/files/2F7E7C0ED794A867p.x-flac)
2126772; 122 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
2126775; 123 GetFile[18] 192.168.1.5 - GET Z:\M2\Coldplay\X&Y 24-192\01 Square One.flac to 192.168.1.13
2126789; 124 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
2127048; 125 SetNextAVTransportURI - Success - http://192.168.1.5:49382/files/F5145CED5FF56764p.x-flac
2407048; 126 GetFile[18] - exit=0, playtime=280255
2411139; 127 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
2411144; 128 GetFile[19] 192.168.1.5 - GET Z:\M2\Coldplay\X&Y 24-192\02 What If.flac to 192.168.1.13
2411477; 129 Profile - Generic Device, useragent=Music Player Daemon 0.23.12

Update:
This seems to  have been a problem specific to these files (just my luck).
When other albums worked correctly, I recompressed this one with the latest encoder (it was encoded with an encoder from 2019) and now it switches songs in MB correctly. I suspect seeking was the problem since the cursor in the wavebar of MusicBee jumped instead of scrolling smoothly. Now it scrolls smoothly. And seeking was also missing from the plugin log.
Log of it working with the same songs after recompression:

Code

5803061; 249 Play - Z:\M2\Coldplay\X&Y [24-192]\01 Square One.flac (http://192.168.1.5:49382/files/71B91248D794A867p.x-flac)
5803076; 250 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
5803080; 251 GetFile[36] 192.168.1.5 - GET Z:\M2\Coldplay\X&Y [24-192]\01 Square One.flac to 192.168.1.13
5803094; 252 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
5803219; 253 StateTimer - Playing,old=Stopped
5803236; 254 SetNextAVTransportURI - Success - http://192.168.1.5:49382/files/52D30B6B5FF56764p.x-flac
6080710; 255 GetFile[36] - exit=0, playtime=277611
6087325; 256 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
6087330; 257 GetFile[37] 192.168.1.5 - GET Z:\M2\Coldplay\X&Y [24-192]\02 What If.flac to 192.168.1.13
6087346; 258 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
6090710; 259 Seek - goto=0
6090725; 260 GetFile[37] - exit=10054, playtime=3374
6090726; 261 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
6090735; 262 GetFile[38] 192.168.1.5 - GET Z:\M2\Coldplay\X&Y [24-192]\02 What If.flac to 192.168.1.13
6090748; 263 GetFile - range=bytes 5954-200303874/200303875
6090752; 264 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
6090760; 265 Seek - pos=0
6090797; 266 SetNextAVTransportURI - No track to queue
6379259; 267 GetFile[38] - exit=0, playtime=288503
6388223; 268 StateTimer - Stopped,old=Playing
6388247; 269 SyncNewPlayState - Stopped,mb=Playing

Update 2:
I think the song switching/seeking problem is bound to older encoders:

Code

8164701; 410 Play - Z:\M1\Blunt, James\Back to Bedlam-The Bedlam Sessions - Live In Ireland\10 Tears And Rain.flac (http://192.168.1.5:49382/files/BC0A6E819EF7ED0Cp.x-flac)
8164727; 411 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
8164730; 412 GetFile[60] 192.168.1.5 - GET Z:\M1\Blunt, James\Back to Bedlam-The Bedlam Sessions - Live In Ireland\10 Tears And Rain.flac to 192.168.1.13
8164746; 413 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
8165976; 414 SetNextAVTransportURI - Success - http://192.168.1.5:49382/files/162D90A631C611ABp.x-flac
8166823; 415 GetFile[60] - exit=0, playtime=2051
8400654; 416 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
8400659; 417 GetFile[61] 192.168.1.5 - GET Z:\M1\Blunt, James\Back to Bedlam-The Bedlam Sessions - Live In Ireland\11 No Bravery.flac to 192.168.1.13
8400671; 418 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
8402367; 419 GetFile[61] - exit=0, playtime=1693

No track change in MusicBee, choppy cursor in wave bar.
Encoder:
reference libFLAC 1.3.1 20141125
Casting the same songs to the same pi via Symfonium works flawlessly.

[BoringName]

New version mb_Upnp2025_1.5.1

Changes
- Changed the order of the mimetypes so if the device supports it, the non x version will be returned first. eg) audio/flac instead of audio/x-flac. Hopefully this doesn't break systems that previously worked, if need be I will make it a configurable option instead.
- Fixed the issue that caused the progress bar to become jittery after hitting next track or selecting play now while a track is already playing. This also fixes the transition issue that occurred when the next track finished playing after the progress bar had become jittery.

I haven't read through the other posts yet.

[BoringName]

Try your setup with the following tracks. I generated a tone in Audacity and split the resulting file into 3 tracks of 15 seconds (so it'll work with the MXN10).
I think it's just that the foo_upnp plugin does a good job of making it sound gapless, even though it's not.

I haven't tested on my other machine yet. But with foobar on the same machine, those 3 tracks are gapless. There's just a small static pop when it transitions but no gap. Is that what you are referring to?

Maybe I have the wrong idea of what gapless is....

[jorgemg1984]

Try your setup with the following tracks. I generated a tone in Audacity and split the resulting file into 3 tracks of 15 seconds (so it'll work with the MXN10).
I think it's just that the foo_upnp plugin does a good job of making it sound gapless, even though it's not.

I haven't tested on my other machine yet. But with foobar on the same machine, those 3 tracks are gapless. There's just a small static pop when it transitions but no gap. Is that what you are referring to?

Maybe I have the wrong idea of what gapless is....

Gapless means no interruption(zero, really) between tracks - good tests are live records, classical music records or "Dark Side of the Moon".

[BoringName]

3. works. I've tested it with 16/44.1 and 24/192 files without playback issues.
I had tried all of these before but it was pointless because I had not realized that mpd was stuck after the first test haha.
Note:
You should add an option to clear/update the nexturi when the playback queue is changed in MusicBee tho.
I was a bit surprised when the 2nd song I had removed from the playing queue in MB started playing on the pi anyhow.

Righto, thanks for all that info. It is surprising how many devices seem to have issues with PCM streams. It could be related to the duplicated attribute it mentions. Especially if a player stops reading at that point. I'll see if I can find the cause of that.

I'll sort out the NextURI issue, that's just an oversight. I have got it set to overwrite the NextURI when a different song is selected but hadn't accounted for tracks being removed from the now playing list.

And I probably sent you down a wild goose chase with the choppy progress bar and encoder versions. There was an issue with the plugin causing those problems, it's likely your files were fine. Sorry.

I'll look over the rest of the info and see what I can improve. Thanks again for the detailed log, it helps a lot.

[simbun]

Try your setup with the following tracks. I generated a tone in Audacity and split the resulting file into 3 tracks of 15 seconds (so it'll work with the MXN10).
I think it's just that the foo_upnp plugin does a good job of making it sound gapless, even though it's not.

I haven't tested on my other machine yet. But with foobar on the same machine, those 3 tracks are gapless. There's just a small static pop when it transitions but no gap. Is that what you are referring to?

Maybe I have the wrong idea of what gapless is....

When the tracks are played "gapless" you'll hear a single constant tone, as if it were a single audio stream, just as it is when you cast from BubbleUPnP/Hi-Fi Cast/mconnect to foo_upnp with MusicBee as the server.

[BoringName]

When the tracks are played "gapless" you'll hear a single constant tone, as if it were a single audio stream, just as it is when you cast from BubbleUPnP/Hi-Fi Cast/mconnect to foo_upnp with MusicBee as the server.

I tried it with bubbleUPnP on my mobile, rendering to foobar and reading from musicbee.

That was a single continuous stream with no breaks or noises.

Going back to playing to foobar from musicbee, those 3 tracks take exactly 45 seconds play so there is no gaps there. I just have to see if I can find the cause of the popping sound. It occurs whether it's a native stream or encoded to PCM. I'm not sure I'll be able to solve that one.

[BoringName]

New version mb_Upnp2025_1.5.2

Changes
- Fixed an issue that caused a metadata attribute to be duplicated.
- NextURI is now handled better when the now playing list is changed.
- Musicbee will now stop when it gets to the last track in the list instead of repeating it indefinitely.

I had issues with the playing tracks element on the Music node being set to "show upcoming tracks" and the player tracks element on the Now Playing node set to "show playing tracks". I recommend setting these both to "show playing tracks" to avoid any strange behaviour with this plugin.

If you set them differently, its possible to queue up a few tracks and play them without notifications this plugin requires to trigger. I'm not sure if that's intended or a bug but I couldn't see a way to work around it.

If Casual Tea could try option 2 again and see how that goes it would be good. Hopefully it can parse the headers this time and gets through the whole track.

[simbun]

That was a single continuous stream with no breaks or noises.

Going back to playing to foobar from musicbee, those 3 tracks take exactly 45 seconds play so there is no gaps there. I just have to see if I can find the cause of the popping sound. It occurs whether it's a native stream or encoded to PCM. I'm not sure I'll be able to solve that one.

My point wasn't really about foobar/foo_upnp it was about the current implementation. You seem to be assuming that other renderers are at fault given that foo_upnp works, which we now know it doesn't.

I tried Volumio, Sonos, WiiM and foo_upnp (I also tried Audiophile Renderer but that appears broken with all of them) and none are gapless/seamless from MusicBee but all are with Hi-Fi Cast and mconnect (I always assume BubbleUPnP will work).

I think there must be something wrong/missing, but unfortunately I have no idea what.

I used 1.5.1 for testing as 1.5.2 isn't available yet.

[simbun]

It occurs whether it's a native stream or encoded to PCM. I'm not sure I'll be able to solve that one.

Given that external control points work, could it be something to do with the way you're serving the file? As a test, can you use the URL that's served to external control points?

EDIT: I meant DIDL (obviously). Fired that message off before diving into a meeting.

[jorgemg1984]

That was a single continuous stream with no breaks or noises.

Going back to playing to foobar from musicbee, those 3 tracks take exactly 45 seconds play so there is no gaps there. I just have to see if I can find the cause of the popping sound. It occurs whether it's a native stream or encoded to PCM. I'm not sure I'll be able to solve that one.

My point wasn't really about foobar/foo_upnp it was about the current implementation. You seem to be assuming that other renderers are at fault given that foo_upnp works, which we now know it doesn't.

I tried Volumio, Sonos, WiiM and foo_upnp (I also tried Audiophile Renderer but that appears broken with all of them) and none are gapless/seamless from MusicBee but all are with Hi-Fi Cast and mconnect (I always assume BubbleUPnP will work).

I think there must be something wrong/missing, but unfortunately I have no idea what.

I used 1.5.1 for testing as 1.5.2 isn't available yet.

I just tested with 1.5.2 and it's NOT gapless from MusicBee (files on a NAS) to MXN10 - but it is from Bubble UPNP (Android) + MinimServer (NAS) and also from Symfonium (Android) + Emby (NAS).

[jorgemg1984]

New version mb_Upnp2025_1.5.2

Changes
- Fixed an issue that caused a metadata attribute to be duplicated.
- NextURI is now handled better when the now playing list is changed.
- Musicbee will now stop when it gets to the last track in the list instead of repeating it indefinitely.

I had issues with the playing tracks element on the Music node being set to "show upcoming tracks" and the player tracks element on the Now Playing node set to "show playing tracks". I recommend setting these both to "show playing tracks" to avoid any strange behaviour with this plugin.

If you set them differently, its possible to queue up a few tracks and play them without notifications this plugin requires to trigger. I'm not sure if that's intended or a bug but I couldn't see a way to work around it.

If Casual Tea could try option 2 again and see how that goes it would be good. Hopefully it can parse the headers this time and gets through the whole track.

Just as a curiosity, how did you fix the last track loop issue? I tested an Eversolo streamer recently that had this issue, it would be great if they solved it.

[Casual Tea]

If Casual Tea could try option 2 again and see how that goes it would be good. Hopefully it can parse the headers this time and gets through the whole track.

Done that (with v1.5.2.) Played for a few seconds and then once again crashed mpd.
Upmpdcli log:

Code

Mär 04 12:55:56 pi3B upmpdcli[6282]: :2:../src/mpdcli.cxx:336::mpd_run_clear(m_conn) failed: Connection closed by the server
Mär 04 12:55:56 pi3B upmpdcli[6282]: :3:../src/mpdcli.cxx:148::MPDCli::startEventLoop: already started
Mär 04 12:56:00 pi3B upmpdcli[6282]: :3:../src/upmpd.cxx:312::checkContentFormat: format check disabled
Mär 04 12:56:05 pi3B upmpdcli[6282]: :2:../src/mpdcli.cxx:113::MPDCli::openconn: mpd_connection_new failed: Timeout
Mär 04 12:56:05 pi3B upmpdcli[6282]: :2:../src/mpdcli.cxx:396::MPDCli::updStatus: connection failed
Mär 04 12:56:08 pi3B upmpdcli[6282]: :2:../src/mpdcli.cxx:113::MPDCli::openconn: mpd_connection_new failed: Timeout
Mär 04 12:56:08 pi3B upmpdcli[6282]: :2:../src/mpdcli.cxx:389::MPDCli::updStatus: no connection

Mpd log:

Code

Mär 04 12:57:32 pi3B mpd[175206]: alsa_output: Decoder is too slow; playing silence to avoid xrun

Plugin log:

Code

73096; 11 Profile - Generic Device, useragent=|Linux/6.1.21-v8+ UPnP/1.1 Portable SDK for UPnP devices/6.2.0
73099; 12 Profile - Generic Device, useragent=|Linux/6.1.21-v8+ UPnP/1.1 Portable SDK for UPnP devices/6.2.0
73117; 13 Activate - MaltePi3B-UPnP/AV:http-get:*:audio/L16:DLNA.ORG_PN=LPCM,http-get:*:application/flac:*,http-get:*:application/x-flac:*,http-get:*:application/ogg:*,http-get:*:application/vnd.apple.mpegurl:*,http-get:*:application/x-mpegurl:*,http-get:*:audio/flac:*,http-get:*:audio/x-flac:*,http-get:*:audio/aac:*,http-get:*:audio/x-aiff:*,http-get:*:audio/aif:*,http-get:*:audio/aiff:*,http-get:*:audio/dff:*,http-get:*:audio/x-dff:*,http-get:*:audio/dsd:*,http-get:*:audio/x-dsd:*,http-get:*:audio/dsf:*,http-get:*:audio/x-dsf:*,http-get:*:audio/m4a:*,http-get:*:audio/x-m4a:*,http-get:*:audio/matroska:*,http-get:*:audio/x-matroska:*,http-get:*:audio/mp1:*,http-get:*:audio/mp3:*,http-get:*:audio/mp4:*,http-get:*:audio/mpeg:*,http-get:*:audio/x-mpeg:*,http-get:*:audio/ogg:*,http-get:*:audio/vorbis:*,http-get:*:audio/x-ape:*,http-get:*:audio/ape:*,http-get:*:audio/x-monkeys-audio:*,http-get:*:audio/wav:*,http-get:*:audio/x-wav:*,http-get:*:audio/wave:*,http-get:*:audio/x-ms-wma:*,http-get:*:audio/x-ogg:*,http-get:*:audio/x-scpls:*,http-get:*:audio/x-vorbis+ogg:*,http-get:*:audio/x-vorbis:*,http-get:*:audio/x-wavpack:*,http-get:*:video/mp4:*
108964; 14 ForcedEncode - Stream is being encoded to apply Replaygain/DSP settings.
108979; 15 Play - Z:\M4\Michaelson, Ingrid\Slow the Rain\03 Charlie.flac (http://192.168.1.5:49382/encode/E31C09EDAA7E0658-2147483638.L16)
109009; 16 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
109012; 17 Profile - Generic Device, useragent=Music Player Daemon 0.23.12
109108; 18 StateTimer - Playing,old=Stopped
113056; 19 ForcedEncode - Stream is being encoded to apply Replaygain/DSP settings.
113060; 20 GetEncodedFile[1] 192.168.1.5 - GET Z:\M4\Michaelson, Ingrid\Slow the Rain\03 Charlie.flac to 192.168.1.13; mime=audio/L16;rate=44100;channels=2,rate=44100,channels=2
113090; 21 SetNextAVTransportURI - Success - http://192.168.1.5:49382/encode/0B8F7588A55378BD0.L16
113199; 22 GetEncodedFile[1] - exit=0, playtime=131
157107; 23 PostSoapRequest - 500,send=POST /uuid-677a63db-6686-01d7-34a0-b827eb0b7fae/ctl-urn-schemas-upnp-org-service-AVTransport-1 HTTP/1.1
Host: 192.168.1.13:49152
User-Agent: MusicBee UPnP Plugin
Content-Type: text/xml; charset="utf-8"
SOAPAction: "urn:schemas-upnp-org:service:AVTransport:1#Pause"
Content-Length: 290

<?xml version="1.0" encoding="UTF-8"?><s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><u:Pause xmlns:u="urn:schemas-upnp-org:service:AVTransport:1"><InstanceID>0</InstanceID></u:Pause></s:Body></s:Envelope>
157112; 24 SoapRequest:Pause:urn:schemas-upnp-org:service:AVTransport:1:InstanceID=0 - <?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<s:Fault>
<faultcode>s:Client</faultcode>
<faultstring>UPnPError</faultstring>
<detail>
<UPnPError xmlns="urn:schemas-upnp-org:control-1-0">
<errorCode>501</errorCode>
<errorDescription>Action Failed</errorDescription>
</UPnPError>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>

157115; 25 Pause - status=500

Why do you transcode to wav/pcm anyhow? Snapcast for example transcodes to flac. That's less harsh on the network throughput and also on the write speed of the upnp devices and even a Raspberry Pi 1 can decode 24/192 flac in real time. Especially with high res music, the bitrate of a wav/pcm stream could overwhelm the anemic wireless connection speed of a raspberry pi or the write speed of its microSD card while a flac stream would still be fine.

Concerning the gapless playback I've performed a little test. The track transition happens between the 2 peaks following the cursor.
1. playing in musicbee locally and capturing the soundcard output yields a perfect transition.

2. playing on the Pi via Symfonium (upnp) also yields a perfect transition (recorded with my mic and normalized).

3. playing via the plugin leads to a choppy transition. Looks like a bit of the beginning of the next track is skipped.

The two songs that I used are "Silver Streets" and "July" by "BOY" from the album "Mutual Friends".

Edit:
I did a further test. I created a sine tone in audacity, added a 1 second fade within that tone, split the tone during the fade and used the 2 resulting files as test files. To get a better recording on the pi, I created an additional fifo output in mpd and recorded that via sox.
Test files split:

Playing these 2 back in MusicBee locally yields a perfect transition:

Playing them on the pi via the plugin repeats a section:

Section zoomed in:

And zoomed in even further:

My guess is that the 2nd song starts playing and then gets its playback position reset to the start, leading to the short repeated section and the choppy transition.

Another idea for an option of the plugin:
You could add a checkbox for "never transcode/force original" so that people could leave options such as smooth fading and replay gain enabled for normal players and could still play via upnp without transcoding.