Jellyfin->DLNA woes on B&O devices

kalle · June 19, 2022, 5:10pm

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:

Tolriq · June 19, 2022, 6:09pm

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.

kalle · June 19, 2022, 9:10pm

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=

Tolriq · June 20, 2022, 5:50am

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

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

Tolriq · June 20, 2022, 6:13am

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.

kalle · June 20, 2022, 6:31am

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.

Tolriq · June 20, 2022, 6:54am

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/Emby.Dlna/Profiles/Xml/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.

kalle · June 20, 2022, 7:04am

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

Good find!

Tolriq · June 20, 2022, 7:12am

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 Reddit - Dive into anything

kalle · June 20, 2022, 7:20am

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)

Tolriq · June 20, 2022, 7:22am

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.

kalle · June 20, 2022, 7:23am

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

Thanks for the excellent help so far!

kalle · June 21, 2022, 4:56pm

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:

github.com/jellyfin/jellyfin

Jellyfin not honoring custom device profiles

opened 11:37AM - 27 May 21 UTC

closed 08:07PM - 19 Oct 23 UTC

supersebbo

bug stale

**Describe the bug** Jellyfin is not honoring custom device profiles. I ha…ve an Jellyfin Media Player client that I want to force the remuxing of MKV files to, so I create a custom profile that excludes the MKV container for Jellyfin Media Player clients, thereby forcing JF to remux MKV containers. However this does not work, JF still allows the client to DirectPlay MKV containers. The client reports itself as 'Jellyfin Media Player' this is confirmed in the logs: ![image](https://user-images.githubusercontent.com/29370445/119818408-0d9c4500-bee7-11eb-876e-a0cfa0e6a252.png) I then create a custom Profile under DNLA->Profiles with the name 'Jellyfin Media Player': ![image](https://user-images.githubusercontent.com/29370445/119818498-315f8b00-bee7-11eb-9436-6a6ddd623d3b.png) I create a DirectPlay profile for this device profile that specifically excludes the MKV containers (indicating the device does not support the MKV container and JF would need to Remux/transcode the content. ![image](https://user-images.githubusercontent.com/29370445/119818659-5fdd6600-bee7-11eb-9aa9-c8faccc77ee1.png) I find a file to test it with and confirm the file is MKV container: ![image](https://user-images.githubusercontent.com/29370445/119818722-74216300-bee7-11eb-83a0-ce6249cc7de5.png) I play the test file from the Jellyfin Media Player client, the media should be remuxed or transcoded due to the profile, but it is not, the client is told to DirectPlay the media: ![image](https://user-images.githubusercontent.com/29370445/119818826-974c1280-bee7-11eb-95c6-eb2fd7d46506.png) Checking the logs, I can see the DirectPlay profile information is not correctly being matched with the custom profile created and appears to be using a default profile. ![image](https://user-images.githubusercontent.com/29370445/119819009-ce222880-bee7-11eb-8a10-fd9340e88755.png) **System (please complete the following information):** - OS: Debian - Virtualization: KVM - Clients: Jellyfin Media Player - Jellyfin Version: 10.7.5 **To Reproduce** 1. Create a custom profile for a device based on the device's 'Name' (there are no further match criteria possible as Jellyfin Media Player reports 'null' for all other match criteria) 2. Create an explicit directplay profile for the device profile that excludes a specific container type 3. Play a test file matching the excluded container type 4. Jellyfin client will DirectPlay the media despite the profile indicating the container in invalid. **Expected behavior** Jellyfin Server should remux or transcode the media as the profile indicated the container is not supported.

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.

Tolriq · June 21, 2022, 5:17pm

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

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

Tolriq · June 21, 2022, 5:54pm

Seems caddy is decent and allows easy header rewrite

kalle · June 21, 2022, 5:58pm

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

kalle · June 21, 2022, 6:01pm

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

Tolriq · June 21, 2022, 6:05pm

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;DeviceId=test&amp;MediaSourceId=b3c951bb15e0f92b3a98eca4a01ba331&amp;Static=true&amp;Tag=1380246717a218aca41ba396ac250656&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.

kalle · June 21, 2022, 6:20pm

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.

Tolriq · June 21, 2022, 6:25pm

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