All Activity

Seems to be working well for me so far. A lot of missing shows, but I imagine it will get better over time. If the API limit is 500/day, why is the default API lookup per run 10000? Surely this should be way lower?

Thanks!

Hi, it doesn't matter.

Sorry, late to the party! It is Dolby Vision. I have some DV movies and Emby will not tonemap unless I force a transcode of the video. You can verify this with the "Stats for Nerds" option while playing the video. The only way I can get it to tonemap is to do playback correction twice: once for transcoding audio and a second time to transcode the video. Once it starts transcoding the video, it will tonemap properly. You can verify that it is working by bringing up Stats for Nerds. It will say tonemapping.

OK yes we are continuing to work on improving it. Thanks.

The audio mapping is in the stable build — thank you. Same table as before, now on 4.10.0.40 and against my real library instead of the synthetic file: requested CODECS attribute aac "hvc1.1.4.L126.B0,mp4a.40.2" mp3 "hvc1.1.4.L126.B0,mp4a.40.34" ac3 "hvc1.1.4.L126.B0,ac-3" eac3 "hvc1.1.4.L126.B0,ec-3" flac "hvc1.1.4.L126.B0,fLaC" opus "hvc1.1.4.L126.B0,opus" dts "hvc1.1.4.L126.B0,ac-3" alac attribute absent truehd attribute absent aac,ac3,alac,eac3,flac "hvc1.1.4.L126.B0,ac-3" <- my app's actual profile alac and truehd still drop the whole attribute, video half included, but the row that mattered to me is the last one and it now works for anyone who updates. The reason I'm posting, though, is two things I ran into while measuring that — and both are worth more to you than to me. 1) YOUR SERVER ALREADY SERVES DOLBY VISION TO AN APPLE TV WITHOUT TRANSCODING IT What stopped it here was what my client was asking for. My app declared only SDR ranges to Emby, on purpose, because the manifest carried no VIDEO-RANGE and a player that doesn't know the range won't switch the TV into HDR. The reason it carried none is the "HDR 10" space round-trip I reported earlier in this thread — but "DolbyVision" has no space, so it survives it. Declaring it changes the answer on the same file: hevc VideoRange=SDR|DOVIWithSDR CODECS="hvc1.1.4.L126.B0,ac-3" (Main, 8-bit, tone-mapped) hevc VideoRange=SDR|DOVIWithSDR|DolbyVision VIDEO-RANGE=PQ, CODECS="hvc1.2.4.L150.B0,ac-3" There is a second half, and it cost me longer than the first: with the range accepted but a TS/h264 transcoding profile listed first, the server still re-encoded. Your StreamBuilder ranks a profile that can copy above one that can't, so the fMP4/HEVC profile has to be allowed to win — on my side that meant no longer excluding HDR sources from the "prefer copy" decision I make before asking. With both halves in place, here is what the server does with a 3840x1606 DV Profile 8.1 file and an E-AC-3 5.1 track, straight from your own ffmpeg log: -c:v:0 copy -c:a:0 copy -hls_segment_type fmp4 -vtag hvc1 Stream #0:0 -> #0:0 (copy) hevc (Main 10) (hvc1), yuv420p10le, bt2020nc/bt2020/smpte2084, 3840x1606 Stream #0:1 -> #0:1 (copy) eac3 5.1, 640 kb/s DOVI configuration record: version: 1.0, profile: 8, level: 6, rpu flag: 1, el flag: 0, bl flag: 1, compatibility id: 1 No encoder, no tone-map, audio passed through, the DOVI RPU intact inside the fMP4 segments, and the TV lights up in HDR. Before the change, the same file on the same server went through tonemap_opencl=reinhard into h264_qsv at 1920x770. The only real work left is the subtitle tracks going to WebVTT. I'm spelling out both halves rather than just saying "it works now" because this is a client-side decision, not a server one, and I know other Apple TV client developers read this thread. On my server I still see the official tvOS app transcode this same file, and from the server's side the entire difference is those two things: a range name in the device profile, and letting the copy-capable transcoding profile win the tie. Whoever finds it useful, it's yours — it took me a day to find the second half and there's no reason for anyone else to spend it. 2) AND WHILE I'M AT IT: ON AN APPLE TV, MP4 IS BETTER SERVED AS HLS THAN AS DIRECT PLAY This one has nothing to do with HDR and I've never posted it here. Direct play works with MP4 — the native player will happily take an MP4 with HEVC Main 10 and AC-3 straight off the server. What it won't do is keep the buffer fed. Measured on an Apple TV 4K, same box, same LAN, same files, with an on-screen buffer readout: 67 Mbps remux, direct play starts ~10 s, drains to 1-2 s, never recovers: it stalls for good 15 Mbps file, direct play 5 s after a minute, 1 s after two, but it claws its way back either of them over HLS 50-60 s of buffer, steady for the whole film The interesting part is that the bleed is proportional, not a threshold: the progressive path delivers about 92% of what playback consumes, so you lose roughly 5 s of buffer for every minute played. The bitrate only decides how long you have before you hit zero — there is no safe "max direct play bitrate", just a slower death. It isn't decoding (an Apple TV 4K does HEVC Main 10 to L5.1 without breaking a sweat) and it isn't the network: a Mac direct-plays the same files over the same LAN with 32-52 s of buffer and no stalls. It's AVFoundation's progressive HTTP path on tvOS. Two things that look like fixes and aren't: preferredForwardBufferDuration (ignored on progressive assets unless you also set automaticallyWaitsToMinimizeStalling = false, and even then it only delays the drain) and seeking to force a re-fill (it drains again from scratch). What fixes it is serving the same file over HLS, and it costs the server nothing: -c:v copy, same bits, segmented with a manifest in front. That's the path the player is tuned for, and it's what Apple's authoring spec for long-form content is written around. It's also why players that bundle their own engine never hit any of this — they are not on that path to begin with. My own client does exactly that: it declines direct play for video entirely and asks for HLS, MP4 sources included. That is a device-profile decision, so it may be one worth revisiting in yours. Two things still on your side, and neither is urgent: - The "HDR 10" space round-trip is unchanged in 4.10.0.40, so HDR10 sources still tone-map. Dolby Vision only gets through because its name happens to have no space in it. - For the player to switch into Dolby Vision proper rather than HDR10, the variant would also need SUPPLEMENTAL-CODECS="dvh1.08.06/db1p" alongside VIDEO-RANGE=PQ, which is what Apple's HLS authoring spec asks for. With Profile 8.1 the base layer is HDR10-compatible and the picture is right either way, so this is the smaller of the two. Happy to keep running the table against future builds.

Well done, both of those bugs have been squashed. However, not sure how the badges are being scaled, as episode images now (with the new setting) get huge badge on Extra Large (while Poster badges retained their size as previously with the same setting); maybe thumb-type image badges should get their own size picker? vs. previously: Poster:

I have deleted the second emby source. It is now set to Local Over the Air Broadcast (which is what is was set to at first) currently recording. Server log will be sent via DM. I will record Radio 1 Dance Party with Danny Howard and let it finish normally and see what happens to the filename. Tuner Channel 700 Channel Number.

yes thanks. that was what i needed.

Sigh...

Hi. "Spotlight" is one of the view styles you can choose for any of those section types. See just below that field.

I have just update to 4.10.0.40 on my Synology DSM 218J using the file named below. emby-server-synology7_4.10.0.40_armv7 Now I am unable to restart Emby it gives an error failed to start and when I attempt it overwhelms my NAS and I have to do a hard reset. Help!!

Exactamente. No lee los archivos MKV la app de Emby y no sólo en los tv LG sino que también en todos los demás dispositivos. Es muy pesado ese codec

"Older" LG TVs might have problems with Dolby Vision in MKV, should work fine in MP4. That's the only thing i know of could be a problem with LG TVs and MKV.

I tried and it takes about 45 seconds to resume into a recording about 1.5 hours. It may have improved a little bit but I am not sure (still seems pretty long). It does display a spinning wait icon the whole time I am waiting. I'm not sure it did before which would be an improvement.

It's hard to describe. There are duplicate songs in the playlist, and clicking on some plays a completely different song.

Alguno sabe cómo se usa esta función implementada en la ultima versión? los clientes necesitan una versión mas actualizada también? spotlight aparece en algún menú? no encuentro nada. Si es en añadir nueva sección en pagina de inicio no me aparece, solo medios dinámicos (que no son muy dinámicos ya que siempre me aparece el mismo contenido en el mismo orden) Muchas gracias

Latest release are you still watching works flawlessly. It does just stop but still - far far better!!!! (Does happy dance!!!)

He leído que el reproductor propio de LG está teniendo mucho problemas con contenido .MKV que son archivos bien pesados y Emby en los tv LG no los ejecuta bien, los transcodifica( no hace el direct play ) haciendo que se pause la imagen por consiguiente. Ahí está el meollo del problema porque ya quité la opción del sonido TrueHD, DTS y nada de eso funcionó. Las películas que quiero ver casualidad están en formato .MKV

Blame this question as a remnant of my C++ work. Does it matter what version of C# a plugin uses? Ie, can I use the latest and greatest release? or must I use a range of versions?

You could try disabling the direct stream live TV option in the app.

Hi, yes this is on our list for review. Thanks.

Wow. That is unexpected actually. Only thing I can think of is possibly the display mode of the device. Looks like a PAL video but, with the standard app, the TV is in 60Hz. It being an interlaced signal, this could be what's behind the degradation. Do you have the match frame rate/resolution options set the same way in both apps?

@DaninFuchs has this helped?

Hi there, what makes you think it’s not smooth?