[Solved] Error when trying to play movie on Samsung SmartTV UE75KS8005

[Nadahar]

Svtplay has geolocation lockdown, so it's blocked from outside Sweden

[Nadahar]

It seems that the problem is that UMS doesn't recognize the audio codec. Since it's registered as "undetermined" UMS can't evaluate if your TV can play the file and it falls back to transcoding. The question is why. The parsing isn't in your log (the parsing is cached, so it has probably been done earlier). To log the parsing, disable "use database" and restart UMS in trace mode. That will make UMS slower, but force the parsing to take place while being logged.

What you could also do it paste the MediaInfo output for the file (Open it in MediaInfo, select "text" output, select all, copy and paste it here).

[Nadahar]

Thanks, that's what I wanted. I don't remember the different labels used in the different versions, so it seems you found the correct option. The parsing was logged at least:

Code: Select all

TRACE 2019-01-21 13:46:42.627 [HTTPv2 Request Worker 13] net.pms.dlna.LibMediaInfoParser MediaInfo parsing results for "E:\download\filmer\timmy-kickar-boll\timmy.lamm.s01e10.timmy.kickar.boll-a87a292-svtplay.mp4":
  Format: "MPEG-4"              CodecID: "isom"               Duration: 0:10:03.280         Overall Bitrate Mode: CBR
  Overall Bitrate: 2798790      Cover: No                     FPS: 25.000
  - Video track ID: 1
    Format: "AVC"                 Profile: "[email protected]"          CodecID: "avc1"               Duration: 0:10:03.280
    BitRate Mode: CBR             Bitrate: 2699968              Width: 1280                   Height: 720
    Chroma: 4:2:0                 Matrix Co: BT.709             PAR: 1.000                    DAR: 16:9
    Scan Type: Progressive        FPS: 25.000                   Framerate Mode: CFR           RefFrames: 4
    Bit Depth: 8
  - Audio track ID: 2
    Format: "AAC"                 CodecID: "mp4a-40-2"          Duration: 0:10:03.264         BitRate Mode: CBR
    Bitrate: 96000                Channel(s): 2                 Samplerate: 48000
TRACE 2019-01-21 13:46:42.627 [HTTPv2 Request Worker 13] net.pms.formats.Format Parsing results for file "timmy.lamm.s01e10.timmy.kickar.boll-a87a292-svtplay.mp4": Container: MP4, Size: 211056760, Video Bitrate: 2798790, Video Tracks: 1, Video Codec: h264, Duration: 0:10:03.280, Video Resolution: 1280 x 720, Display Aspect Ratio: 16:9, Scan Type: Progressive, Frame Rate: 25.000, Frame Rate Mode: CFR (CFR), Frame Rate Mode Raw: CFR, Matrix Coefficients: BT.709, AVC Level: 3.1, Audio Tracks: 1 [Audio Codec: und, Bitrate: 96000, Channels: 2, Sample Frequency: 48000 Hz], Mime Type: video/mp4

The problem is that "mp4a-40-2" isn't recognized, and thus the audio codec ends up being "und". This is a bug in UMS. I don't think UMS will be able to play such files on any renderer (except when you disable transcoding, which disabled the whole logic that fails) until this is addressed.

I'm sure that a sample file would be handy for anyone wanting to look at it. Can't you find some software that allows you to cut a little clip and upload somewhere? 10 seconds should be fine..

[Nadahar]

I'm no longer a part of the UMS team, so I expect one of those that are to look into the details. That said, AAC isn't really a "codec" in the traditional sense, you should rather think of it as a "family of codecs" (https://en.wikipedia.org/wiki/Advanced_Audio_Coding). AAC is a complete mess of many different actual implementations, some that are common and some that are hardly supported at all - and quite a few that's somewhere in between. To make it even worse, AAC was first partially defined in the MPEG-2 standard, but then redefined and vastly expanded in the MPEG-4 standard.

It suffices to say that merely recognizing something as AAC isn't enough to know how to handle it. That said, this is still a UMS bug, it shouldn't end up being "unknown".

[valib]

I tried to fix it in the https://github.com/UniversalMediaServer ... /pull/1755 and it will be released in the next UMS version