Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[AndrewFG]

I have noticed on the boards that there is some confusion over MC DLNA server modes "Original, Convert, Convert if Needed" and I would like to suggest that you add some additional granularity on that choice.

As you are aware there are a variety of Renderers around which (for example) support playing Flac files natively, but do not support (say) ALAC or OGG. Also there are Renderers which can handle up to (say) 96 kHz maximum, or (say) up to 2 channels maximum.

So my proposal is to 1) allow more granularity on the Transcoded Output media format, depending on the Source Input Media format being played, and 2) allow more control over the maximum limits of the Transcoded Output media format.

See screenshots attached..

Note that the examples refer to Audio, but basically the same logic would apply for Video.

[Hendrik]

While such UIs make sense to you and me, they quickly degrade into "Programmer UI", which 90% of the ordinary users don't understand and therefor don't use - or use wrongly and cause issues. Therefor this is more complicated than just adding some controls.
On top of all that, the possible permutations are endless, especially for video. We don't even know all video properties that may decide such things (like profiles).

[AndrewFG]

So that's a "no" then ??

[jmone]

I've pondered this as well.  We already have much of this level of control for Handhelds where we can select on a per device basis:
- Support File Types
- Conversion Options
- Even DSP settings

It's not perfect (i'd love to see the ability to create custom Video profiles for example) but the basics are already there and don't seem to cause issues with users.  It could be generalised from HH to DLNA/Zones etc?

Thanks
Nathan

[Hendrik]

Handhelds don't really offer any more flexibility than DLNA does. You can set up one set of output settings per device, which you can do with DLNA when creating multiple servers and assigning them to the devices.

[jmone]

Of course -    Misread what Andrew was suggesting.

[jmone]

So my 2nd attempt (trying to be more intelligent this time), the current approach in MC seems to make sense, if (for example on audio):
- DLNA advertises what it supports (accurately)
- MC will then serve the original if supported or transcode to a single user selectable format (MP3 / PCM) with the optional ability to
   - Downmix to Stereo
   - Vol Leveling
   - Change Sample Rate
   - Apply DSP

So if the device does not support one format, MC should then transcode to a prefered single format.  Should work for most use cases or am I missing something?

[Hendrik]

So that's a "no" then ??

Not necessarily, but I can't imagine a concise and easy to use UI that doesn't involve a list of dozens of formats with a bunch of variants for sample rate, bitdepth, channel count.
Such an UI bloats up quickly and becomes overwhelming.

[JimH]

Maybe we could have a new Conversion Presets page and do all the ugly stuff there.  Then just present both the default choice names and user preset names in the UI that you're talking about now.

[leezer3]

I'm sure I've floated this idea before, but what this really wants is a bigger database of devices, preferably user submitted.
The end goal should be that whenever a device is plugged into the network, it's just handled like magic

In other words, when MC encounters a new DLNA renderer, it 'Calls Home' to see if a profile already exists.
If a profile doesn't exist, then present with a dialog similar to the one we currently have, and play something like a set of test files. (Andrew's DLNA tester is a good starting point, although I think probably a little involved for the average user)]
Finally, allow the submission of this profile to the database.

Whilst this represents work on both the client and database side of things, I think it'd be very much worthwhile.

Ties in well with your IOT work too.

-Leezer-

[JimH]

You're correct about IoT.   That will require a database.  I hope it will be user contributed data, like cover art.

DLNA devices are supposed to negotiate but sometimes they lie.

[AndrewFG]

... but what this really wants is a bigger database of devices, preferably user submitted ...

http://www.whitebear.ch/downloads/Renderer_Database.zip

[AndrewFG]

- MC will then serve the original if supported or transcode to a single user selectable format (MP3 / PCM) with the optional ability to
   - Downmix to Stereo
   - Vol Leveling
   - Change Sample Rate
   - Apply DSP

So if the device does not support one format, MC should then transcode to a prefered single format.  Should work for most use cases or am I missing something?

Not missing anything. You got it precisely.

You've got (say) a renderer that can play CD quality FLACs natively. You've got a library containing (say) 90% CD quality FLACs and (say) 10% exotic stuff in ALAC or high bit depth or high bit rate, which your renderer cannot play natively. So you have to set up the MC server to transcode 100% of your library to L16 2ch 44.1kHz (say) all of the time. It forces you to find a lowest common denominator that the renderer can play on 100% of your tracks. Which means a) that you may be losing fidelity on some tracks, and b) wasting a lot of CPU. It is a sledgehammer approach, not subtle at all.

[AndrewFG]

DLNA devices are supposed to negotiate but sometimes they lie.

And MC sets a bad example here because it does not even bother to make the effort. It takes two to tango..

[JimH]

http://www.whitebear.ch/downloads/Renderer_Database.zip

Very nice.  Thanks!

It may be the best summary in the world of the state of renderers.

[AndrewFG]

It may be the best summary in the world of the state of renderers.

These are reports submitted mostly by users who post problems on these forums.

.. so it may even be the best summary of more "quirky" renderers in the world..

[JimH]

What per cent of renderers have problems?

[AndrewFG]

What per cent of renderers have problems?

Dunno 

Perhaps (Count Users Who Post Here) / (Count Total Registered Users) 

[mwillems]

What per cent of renderers have problems?

FWIW I have not encountered a UPNP/DLNA renderer that 100% "just worked" with MC without additional configuration (other than MC itself), but I've only tested a handful of renderers, both in hardware (three different smart TVs, an Oppo device, etc.) and software (Kodi, Volumio, mpd with upnp plugins, etc.).  I've used Andrew's testing suite to great effect, and with some of the software renderers I surely would have never independently happened upon the correct combination of flags needed for smooth playback (Volumio, I'm looking at you!)

Some of the renderers worked in a basic way, but "nice to have" features didn't work, i.e. gapless would fail, play and stop controls were laggy, seeking would fail, etc.  But in some cases the renderers just didn't play at all with MC's default settings.  In almost every case there was some combination of settings that would produce relatively solid (or at least more solid) playback for these devices, and Andrew's tester correctly identified them.  

I'd like to express my thanks to him again  

[gabeg]

Maybe we could have a new Conversion Presets page and do all the ugly stuff there.  Then just present both the default choice names and user preset names in the UI that you're talking about now.

This would be awesome.

[MikeO]

Just to clarify.

My renderer , Cambridge audio CXN, handles flac natively at sampling rates up to 384 (?)

I have 80% flac 44.1 16 , but a significant number of 96 24 flac

I have the server set for 24 bit , all the 16 bit I assume is transcoded ,is there a way around this extra processing with a mix of sample rate and bit rate

I would almost prefer to send all unprocessed ...

Mike