Files with DTS Audio are transcoded via Bubble UPnP when the target is the local device

Hi,

I’m at a point where I can’t seem to find out what exactly the problem is. Imagine the following:

I have a Kodi Mediacenter set up, I open Yatse and select to play a movie on my local device (in this case a Pixel 4XL). What I also have is a Bubble UPnP Server in my Homenetwork to make use of the transcoding for Chromecast Devices like Smart Displays.
However I only want to have the transcoding on the Bubble UPnP Server for Chromecast targets since you cannot switch Tracks/Fast Forward etc.
Now as said, I select a movie having DTS Audio to play on the local device. Now the Bubble UPnP Server is used to transcode and then play on my phone despite that this is not the behaviour I want since its limiting.

I understand that there are several settings to influence this behavior so I’ll try to write down what I have:

  • using only a Bubble UPnP Server in the Transcoding Settings (no Bubble UPnP for Android installed)
  • MX Player as local Player with additional codec pack from XDA for DTS Support and settings to use HW+ Decoder
  • in Yatse Settings DTS is selected under the setting which format the local player supports

In my opinion the setting where I select DTS as available format on my local media player is never used. When I play a file with AC-3 the Bubble UPnP server is skipped and it plays directly as it should. Also if I disable the Server in Yatse Settings it is also played directly without a problem. What could be happening here? Or is it a matter of settings or something?

You can also find a debug log pasted here when I try to play a movie with DTS:
https://pastebin.com/FPLau8Dk

Thanks and a nice evening :slight_smile:

Yes this is an edge case that bubble does not support :frowning:

To ensure proper handling of everything in most cases, Yatse delegate the choice to transcode or not to Bubble and pass the supported things, but Bubble have no option to keep DTS even if I asked him to support a few more edge case he politely declined :slight_smile:

One possible solution would be to add an option in Bubble settings in Yatse to never use Bubble for local device if that covers all your cases, but it sometimes you want transcoding it won’t be possible.

1 Like

Btw seeking in Chromecast with Bubble should work unfortunatley not in Mx as I have no control.

And track selection is still on Todo lost

1 Like

Ah, I see, and I thought I was going crazy and did something wrong. I thought Yatse made the choice on what to transcode or not, but now I understand it’s Bubble. To bad Bubble won’t support this, bit thanks for asking (in the past).

Yes, good idea, I think there wouldn’t be any other solution possible than this. It depends if that is something you want in Yatse. I’d understand if these are edge cases you won’t support, bit otherwise such an option would be a good compromise I guess. Most times I do not think transcoding would be needed on the local device, at least I would think so.

Thanks also for the explanation about the seeking. It’s hard to find any documentation about this at all, so I’m happy to learn. Otherwise it’s learning by doing. I’m a little surprised that MX Player doesn’t support this, that’s quite unfortunate. Might try VLC at any point but I guess other problems will arise with that option.
I think you can’t have everything, something will be missing either way, apart from what you select/use.

It would be the same with VLC, Yatse knows that the stream is not seekable but emulate seeking by restarting the stream at the new point seamlessly.
Bubble have decided to do in memory transcoding with parameters that does not allow seeking there’s nothing that can be done on client side for that.

1 Like

Ah, I see, I misunderstood your post yesterday. I understand now, seeking works on Chromecast when transcoded by Bubble, but not on the local player when transcoded by Bubble.
I guess this would then be one reason more to have some kind of option like you suggested to skip transcoding via Bubble on the local device altogether. Then this problem would be void.

Seeking never works :slight_smile: It’s just Yatse that restart the stream at the new position.

Option will be present in next version.

Yeah you are right, I should differentiate between seeking and jumping. Seeking doesn’t work but jumping like you said with a clever trick :slight_smile:

Thanks! I will try it when it becomes available and report back here if you like. In the meantime I set the explanation you made as solution.