Jellyfin->DLNA woes on B&O devices

Issue description:

I use Bang & Olufsen devices and they seem to be a bit troublesome with DLNA streaming.
The “Too many errors” toast appears.
My server is Jellyfin.

Playback to the B&O devices work as intended with Chromecast but that sadly disables the multiroom functionality.

So problem is not retrieving the data from Jellyfin, it is with sending it over DLNA to the speakers/devices.

I have tried playback through BubbleUPnP and that works over DLNA, albeit DLNA → DLNA and not Jellyfin → DLNA.

I think we can safely ignore the 192.168.1.1 log spam in the Symfonium log.
That is the router shouting on the DLNA network which has since been disabled.
Still same behavior.

Before I disabled the transcoding on the BubbleUPnP-app it struggled a bit as well.
It can be seen in the logs, after that smooth sailing.

I can spot a difference in the flags though.

BubbleUPNP
DLNA.ORG_FLAGS=03700000000000000000000000000000
Symfonium
DLNA.ORG_FLAGS=01500000000000000000000000000000

I hope the above helps.

BTW:
Great app other than this issue.
I don’t want to go back to BubbleUPnP so I hope this can be addressed.

Logs:

BubbleUPNP playback:

Symfonium playback:

Please try to join the beta on Play Store version 1.4.5 have a fix for this kind of devices that does not support flac but requires x-flac as mime types.
From the error they return it should fix this else I’ll need new logs with the new error.

OK, I’m getting spam takedowns because of the paste URL:s, lol.
I’ll give it a new try then.

This is the final attempt with Beta app and transcoding turned off in Jellyfin (still no luck with FLAC):
https://zerobin.net/?8d9cef738d704652#j6JtDPa/q32TEB6kYIhT/vY37rAUwFs4hYsAiz2PaLM=

You can directly upload the logs here it’s even better.

Anyway from the logs the mime is correct but it still don’t like it, pretty sure it’s because of the headers on the Jellyfin server. Transcoding to something else would fix I guess or proxy the data with header rewrite but that would kill the battery :frowning:

You can still try to uncheck the alternative dlna flags in the settings just in case.

As a test you can also download the FLAC to the device and use Symfonium local library to play the media and see the result.

Yeah, not too keen on transcoding since I know it can direct play…
As stated earlier BubbleUPnP manage to do this just fine (i tried again after disabling transcoding in Jellyfin).

BubbleUPnP seems to use the same headers (x-flac etc) as Symfonium except the FLAGS #.
You don’t think this can have anything to do with it?

I’ll try send some FLAC from local when I have a chance.

[EDIT]
Ah I see, you mean there is additional data included from the Jellyfin server that trips it up?
Could those be stripped out when using DLNA?
I’m not sure what I’m asking really.

As said in last post you can toggle the flags in the settings to check but I doubt it works.

Bubble use the DLNA server part of Jellyfin that returns different headers, the http part should work the same via the dlnaheaders param passed but it’s not always the case. (For example via dlna there’s profiles to force the mimes jellyfin/Samsung Smart TV.xml at master · jellyfin/jellyfin · GitHub). And it get the protocol info so can adapt. The http api does not support that without transcoding AFAIK.

Reading Jellyfin code it seems that for http it use the default profile so you can probably edit the default profile to add

    <ResponseProfile container="flac" type="Audio" mimeType="audio/x-flac">
      <Conditions />
    </ResponseProfile>

And it may work.

Neat, I’ll try editing the default profile later and see if it helps.

Good find!

It also seems that you can create profiles based on the http headers you get from the device.

Those headers are probably in the Jellyfin logs and you can make a profile for just that device, that should work at 100%.

There’s some kind of explanation at https://www.reddit.com/r/jellyfin/comments/f0arar/webos_app_should_i_wait_for_an_official_release/fh23yne/

Lovely.

I guess this would be my Phone ID since I don’t think Symfonium is passing through the end device name to Jellyfin?
At least not when it played the MP3’s that worked.

In the "Friendly Name" field, type in your TV's name (you can find this on WebOS by going to All Settings > General > About This TV > TV Information > Device Name (this is what you want)

From the source code the headers are get from the actual request on the media.

The actual request is made by the B&O device so you’ll see on the Jellyfin logs what it sends.

Coolio.
I’ll rummage through the Jellyfin logs and have a look.

Thanks for the excellent help so far!

So I’ve been struggling with this now for a while.
No matter what I did with custom profiles it did not take.
Then I found this topic:

I guess this means the profiles are strictly for DLNA use and we access it through http…

Is this the end of the road?
In that case I have to use 2 apps, Symfonium when away & BubbleUPnP when home, which would be a bummer.

Have you tested to cast a flac from local to those from Symfonium?

The only workaround after is to proxy and rewrite the headers.

Seems caddy is decent and allows easy header rewrite

Yea, sorry I did and it was the same I’m afraid.

For the heck of it I took a look at the debug log from Jellyfin using the B&O app.

This is the response from the server I think:

I just noticed that Jellyfin only returned http-get:*:audio/flac as usual.
And still it works on the device.
Can this string be reverse engineered with Symfonium to the device?
I might be asking something stupid again but I just wanted to bring it up before giving up.

protocolInfo=\"http-get:*:audio/flac:DLNA.ORG_PN=FLAC;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01D00000000000000000000000000000\"&gt;http://192.168.1.2:8097/audio/b3c951bb-15e0-f92b-3a98-eca4a01ba331/stream.flac?DeviceProfileId=1bf3d58386de4861ae15fc12a1253871&amp;amp;DeviceId=test&amp;amp;MediaSourceId=b3c951bb15e0f92b3a98eca4a01ba331&amp;amp;Static=true&amp;amp;Tag=1380246717a218aca41ba396ac250656&amp;amp;dlnaheaders=true

I see that there is yet another Flag at work also:

DLNA.ORG_FLAGS=01D00000000000000000000000000000

I have a NGINX reverse proxy already but had to remove Jellyfin from it because it is breaking playback on large files from WAN.

You need to understand that there’s 2 different things here.

The value sent as the upnp query and the headers that the webserver returns when accessing the file.

From the logs and history it seems the issue is more about the last one. Since I do not have access to your setup and can’t check all the logs in real time it’s hard to debug all.

Open http://192.168.1.2:8097/audio/b3c951bb-15e0-f92b-3a98-eca4a01ba331/stream.flac?DeviceProfileId=1bf3d58386de4861ae15fc12a1253871&amp;amp;DeviceId=test&amp;amp;MediaSourceId=b3c951bb15e0f92b3a98eca4a01ba331&amp;amp;Static=true&amp;amp;Tag=1380246717a218aca41ba396ac250656&amp;amp;dlnaheaders=true in a browser and check the returned headers with a debug tool.

And the thing here is the DeviceProfileID that is generated when browsing from upnp I don’t know how to have one working without transcoding.

Yes, I am trying to understand.
Please don’t take my questions as criticism on your part!
This app is so close to be perfect for me…

I tried the URL and Response Headers were:

HTTP/1.1 200 OK
Content-Type: audio/flac
Date: Tue, 21 Jun 2022 18:06:03 GMT
Server: Kestrel
Accept-Ranges: none
Transfer-Encoding: chunked
X-Response-Time-ms: 214

I tried the same URL without DeviceProfileID data and it loaded fine as well.

http://192.168.1.2:8097/audio/b3c951bb-15e0-f92b-3a98-eca4a01ba331/stream.flac?DeviceProfileId=&amp;amp;DeviceId=test&amp;amp;MediaSourceId=b3c951bb15e0f92b3a98eca4a01ba331&amp;amp;Static=true&amp;amp;Tag=1380246717a218aca41ba396ac250656&amp;amp;dlnaheaders=true 

Response Headers:

HTTP/1.1 200 OK
Content-Type: audio/flac
Date: Tue, 21 Jun 2022 18:15:27 GMT
Server: Kestrel
Accept-Ranges: none
Transfer-Encoding: chunked
X-Response-Time-ms: 9

[EDIT]
I will add that both URLs downloaded and played the flac in the browser window, sound and everything.

Don’t worry I don’t take it personally it’s just that I hate debugging such issues as it’s endless time lost for stupid things.

You need to replace the &amp sorry it’s not working on your test

http://192.168.1.2:8097/audio/b3c951bb-15e0-f92b-3a98-eca4a01ba331/stream.flac?DeviceProfileId=1bf3d58386de4861ae15fc12a1253871&DeviceId=test&MediaSourceId=b3c951bb15e0f92b3a98eca4a01ba331&Static=true&Tag=1380246717a218aca41ba396ac250656&dlnaheaders=true

What you tested ignored all the params so it would not work on your B&O