Universal Media Server | Forum

Hi, this is my first post here, i've been looking for information about my problem everywhere but i couldn't find much so i'm asking here.

Short version: i have a ton of m4a files on a directory on a Mac, i would like to play them on my TV in my living room using UMS, i can't, the TV says some error occurred, non specific.

Long version:I have a Mac Mini late 2014 running UMS 9.7.0 under MacOS Catalina 10.15.5. The TV i'm using to browse UMS is a Samsung Q70R 65", i can see UMS from the TV, i can play video, i have shared my /user/<username>/Music/iTunes/iTunes Music folder in UMS and i can see it, but i can only play mp3 files on the TV, most of my music is in m4a files, i'm using a config file i found on this site that was done for 4K video, the relevant part of the config is this

# Supported audio formats:
Supported = f:aiff m:audio/L16
Supported = f:ape m:audio/ape
Supported = f:flac m:audio/x-flac n:2
Supported = f:m4a|alac m:audio/mp4
Supported = f:mp3 m:audio/mpeg
Supported = f:oga m:audio/ogg
Supported = f:vorbis m:audio/vorbis
Supported = f:wma m:audio/x-ms-wma
Supported = f:wav m:audio/wav

As i said, mp3 files can be played, m4a files show on the TV as mp4 files, the TV says it cannot play them, the files internally are AAC encoded, they have no DRM, here is a sample ffmpeg info for the stream:

encoder : fre:ac v1.1 Beta 3
Duration: 00:05:59.97, start: 0.000000, bitrate: 328 kb/s
Stream #0.0(eng): Audio: aac, 44100 Hz, stereo, s16, 325 kb/s

The log doesn't have any error whatsoever, just says the file was played, e.g

22:04:47 INFO Started playing 01 Sunrise.m4a on your [TV] Samsung Q70 Series (65)

The TV documentation at samsung says it supports this types of file, you can see it here https://downloadcenter.samsung.com/cont ... 0731.0.pdf on page 137

This is all the info i have, if somebody has solved this an can shared the answer or can direct me towards a proper config, or even documentation where i can read and understand this "Supported = " lines, because i can't find much, for example what is the f: the m: and the n: for, i have also seen an a:

Thanks in advance for any help or pointers you can give me.

The trace log is needed to see the ProtocolInfo UMS serves the TV, which decides what the TV does with a given media. The closest thing to documentation of the "supported" lines is found in DefaultRenderer.conf.

The supported line relevant for M4A that you listed is: It doesn't quite make any sense. "f:" is the file format, which is MP4/M4A (it's the same file format, the only difference is in the naming convention). ALAC on the other hand is a codec, and should be specified with "a:" (for audio codec) together with AAC-LC and whatever other AAC variants the TV supports. There's also a question of what MIME type the TV wants for M4A files. "audio/mp4" is the "most correct" version, but that helps little if it's different than what the TV wants. If could also be for example "audio/m4a" or "audio/x-m4a" for example: https://stackoverflow.com/questions/398 ... -audio-mp4

That said, UMS has long standing issues with M4A. The reason is that the DLNA standard is very explicit for all things AAC, and places a lot of restrictions that the content has to comply with. UMS doesn't implement all the necessary checks, and will often serve a DLNA profile that is in fact incorrect for the media in question. If the TV is "picky" about the media actually matching the specs of the profile, it might reject the file for that reason.

I read the DefaultRenderer.conf, it's still ambiguous as to what goes where in the f: a: etc flags, but it's good information.

I'm attaching the trace log.

I put some of those m4a files on a USB and plugged it to the TV, played with no problem. I've been playing with the renderer config but nothing i find seems to work.

Issue solved with a huge compromise. Downgraded to 9.5.0, dumped the config and started using the default config Samsung-UHD-2019.conf changing line 86 to this
Now my files under iTunes Music appear and play, but they are not in order, the numbering is lost. Swings and roundabouts, i guess.

try adding to your config and that should fix the ordering

I don't remember all the "flags" myself, but f:, a: v: and m: are pretty clear to me. "f:" is the (file) format/container, "a:" is the audio codec, "v:" is the video codec (where relevant) and "m:" is the MIME type to send. There are others, but I don't remember them all. The expressions after ":" are regular expressions/regex, which is used for matching.

Looking in your log file, your TV disconnects after trying to start playing "Sunrise". It seems to me to be caused by UMS' lacking DLNA implementation, in particular this information sent when the TV is browsing. It is missing the most important part, the DLNA.ORG_PN value. As a consequence, your TV makes another request, asking to received "DLNA ContentFeatures" for the media, and UMS replies: This is also missing the same value, so the TV just gives up and disconnects. This is at least my interpretation of what is happening, it could be something else that makes the TV disconnect, it doesn't say why But, since the "PN" value is the most basic DLNA information (Profile Name) that's supposed to tell the TV what "rules" the media adheres to (format, codec, parameters etc), I find it very likely that this is the cause of the disconnect.

The fact that something plays from a local USB isn't very relevant, it is read as a file instead of through a "UPnP ContentDirectory" service. The two has little in common except that they're supposed to ultimately deliver the same content.

Your TV claims to support both these MIME types:

Doesn't do what you think. It matches all M4A (MP4 with only one audio track) files AND all AAC files. It accepts any codec. The problem is that there is no "AAC format", AAC is an audio codec, not a file format.

@mik_s

Thank you very much, PrependTrackNumbers worked like a charm.

@Nadahar

Thank you for reviewing my logs and the in depth explanation, i tried many combinations or mime type, format and adding audio codec using the renderer config included in the zip and the default Samsung-UHD-2019.conf and nothing worked. I don't know how to read the logs, but it it looked abrupt for me, the tv was making requests for content and then just stopped and it's asking for directory info again. It must be something different with 9.7.0 because going back to 9.5.0 worked.
The line i modified maybe doesn't do what i think... but it does what i wanted.
The original line on that config on 9.5.0 states f:acc m:audio/x-m4a (as you can see here https://github.com/UniversalMediaServer ... -2019.conf). When i used it like that none of the m4a files showed on the TV, the directories with m4a files showed empty, once i added the |m4a they started showing; m4a from what i understand isn't a format either, supposedly the format is MPEG4 but i imagine they are playing because either the mime type is what the tv expected and/or the tv says in the manual that m4a, mpa and aac files are considered as MPEG4 format and is supported using the aac codec.

..is invalid too. Luckily, since "acc" files doesn't exist, it never gets a match, which would have resulted in strange results, sending a non-existing format without transcoding using "audio/x-m4a" I've found mentioned on the net that M4A files are "sometimes" using the ".acc" extension. I guess anything is possible, since anybody can rename files, but that doesn't make it meaningful IMO. Many of the "standard" renderer configurations shipped with UMS is full of inconsistencies like this, in general the audio part has very little focus as most people use it mostly for video.

M4A is a "special" format from UMS' side, because there is code that designates MP4 files with no video tracks and only one audio track as "M4A". I know because I wrote that code. So, you're correct that in reality they are just MP4 files, but since Apple decided to "invent" "M4A", it's been made this way to lessen the confusion somewhat. It's also a useful way for UMS to decide if the file should be treated as "audio" or "video".

The problem with this line as it is now, is that it makes no requirements when it comes to codec. That means that all MP4 files with just an audio track will qualify, regardless of if the codec is AAC (any flavor), ALAC, MP3 or any of the less common audio codecs. I really doubt your TV will handle all those cases, which is why it should be more specific. All you need to do is to specify "a:aac-lc|alac|whatever" in addition, to limit the audio codec to one of those listed.

The codec you're most likely to encounter in M4A files is ALAC. If your TV only supports AAC in MP4 containers, those will fail to play. By specifying only AAC-LC (for example), ALAC files would then be transcoded instead of streamed directly.

Thankfully my files are not using alac, so i guess i'm in the clear.

For my own edification then

f:xyz should refer to format, but is in fact the file extension?
m: is the mime type, this info tells the dlna client what they are getting on the http request?
n: is the maximum supported number of channels, no question here, my tv manual states flac supports a maximum of 2 channels so i guess if the tv has limits this is how you set it.
a: the audio codec to use, this is to transcode the file so i'm guessing you are telling ums that if the file extension matches this line then use this codec to convert into what? where is the target codec for the client defined? is this the TranscodeAudio flag? that only supports mp3, wav and lpcm, so if i don't use this option i'm telling ums stream the file to the client as is and now it's my device responsibility to implement the codec? And does the m: have to match the target codec? (e.g files of type ogg should be transcoded using the vorbis codec, the device receives lpcm, should the mime be set to audio/x-lpcm?)

v,w,h,b,se and si are more related to video i suppose.