All Activity

Ive seen a couple of threads for DV Profile 5.0 for clients without the necessary hardware. I was just wondering what the status is? If the delay is due to performance issues, I understand that realtime streaming may not be possible yet while its figured out. However, as a holdover solution, would it make sense to add this ability to the conversion system? This way if a client was having the issue, they could kick off a conversion? TIA Scott

Okay, thank you very much.

We are starting proper numbering for the core UI code, which is included in apps, in the server and the hosted web app on https://app.emby.media/ This will allow us to better diagnose and user to better understand when and why there might be differences regarding to bugs and behavior.

One thing that's easy to overlook is that the software itself usually isn't the legal issue—it's whether the content owner allows that type of public use. Business owners often assume that if something works at home, it automatically works in a commercial setting, but licensing can be very different. Reading the usage terms carefully before making a decision can save a lot of problems later.

What is the timeline for the transcoding of tone mapping for DV5?

One possibility, could the plugins themselves be put on the store? Meaning, it would be up to the plugin developer to get it through the store requirements? I know I have seen plugins on the android store, but they were "android apps" in themselves, not DLLs to be place in another apps directory. Just a thought.

The Emby server is set to port 8098, but the plugin I created ("Air Date Fixer") listens to port 8096. When I add port 8096 and exit the Android app, it reverts back to 8098. For my plugin to work, I need it to use port 8096

The universal standard app is the way forward. The TV app has fallen behind on these kinds of updates. Thanks.

Not sure if you've tried submitting anything to one of the app stores yet but if you knew what we have to deal with to get validated with them you would understand. For instance. The TV app has been rejected for "inappropriate content" multiple times. Our app has no content and no matter how many times we try to explain that it only shows the content it is pointed at (like a browser) they still don't get it. So, that is just to say there is no logical set of rules we could put in place that would guarantee that we wouldn't run into approval issues and we waste way too much time already trying to move through their validation maze. Anything that looks like sharing of information or even downloading stuff in some cases gets rejected routinely. We simply cannot take the chance. Hope you understand.

file is not working

Hi. What are you calling the "auto discovered" address? If your server reports the proper address, then the app will always use that.

Hi @Lukeany update on this ?

@LukeI might have spoke too soon. DV remuxing needs a small fix. On iPhone, MKV + DV P5 plays as pink/green. Same file in MP4 (manually remuxed using ffmpeg), plays with correct colours. Looking at Emby log, it's missing the ffmpeg flag needed to copy the DV metadata from the mkv to the fMP4 segments. -strict -2 DV 8.1 plays the HDR10 base layer so this problem doesn't surface. DV P5 has no HDR10 base layer so it exposed the problem in the current remux pipeline. All the server needs to do is add -strict -2 to the ffmpeg commands to fix this. Thanks again and sorry for tagging! I'll be away for the next few days but happy to provide any info that doesn't require access to the server. I've worked on creating a custom player engine for a tvOS app so I have some experience dealing with this.

Manually added address reverts to the auto-discovered one every time the app restarts. Please add an option to pin a manually added address. Thanks

AFAIK that is not possible as the user must physically log in. This is like asking if you can log into multiple PC's at the same time while not physically accessing them. But I'm not a dev. It might be possible to script something like this through home assistant, but it could potentially open you up to security issues.

@Luke I've done some testing and I must say you guys have REALLY stepped up your HLS game! Very well done. Emby couldn't even play SDR HEVC via HLS on Apple devices a few years ago, now HEVC DV direct stream beautifully. Anyway, I've isolated the problem: The client is not reporting EAC3 compatibility to the server. The iPhone client is only reporting ac3 & aac. The macOS client is only reporting mp3 & aac. They should both report the full list supported by Apple's HLS engine: AAC, AC3, EAC3, ALAC, FLAC. (mp3 is not allowed inside fMP4 on Apple devices) Also: A few other thoughts for consideration: - Only use fmp4 with Apple devices as per Apple's guidelines. You already know that hevc only works in fMP4, Emby currently uses TS for h264. Maybe unify approach? - Have you updated/patched FFmpeg yet so it's able to correctly copy the JOC data into the fMP4 segments? I've been waiting a long time for this one. - For unsupported codecs like DTS/TrueHD, offer transcoding to FLAC to avoid unnecessary degradation going to lossy AAC/AC3. FLAC is free and has no licensing restrictions. Thanks for reading! Log Attached ffmpeg-remux-4272caa2-191b-4eb4-8aed-2d07d53dddba_1.txt

Many will have trouble reading that.

Are you using the hosted web app or the web app built into your server? This has already been added to the hosted web app. It will be in your built in web app starting with the upcoming 4.10 server release.

Hi, any news about this?

This seems fine?

I have an NVIDIA Shield running the universal Android app, a UGOOS AM6B+ running EmbyCon, and Home Assistant. Is there a way I can set it up so that whenever a user logs in on the Shield, that same user is logged in on the UGOOS? I only need it to work for accounts that already have their passwords saved on both devices.

Yes, all the meta data scrapers under mixed content are geared for movies tv shows etc. None for music or multichannnel discs. Although some of the blu ray audio discs actually scrape the right meta data

But you are requesting we replace the current text in the line under the title. Putting that icon in that place would end up quite small (look at the RT icon for example). The text is much more clear IMO.

I'm using Emby for Android 3.5.42 and I'm still having the issue

Can you elaborate? What should I look for? This happened in different series from different sources and for the first time, so, at least to me, this is something new. Can I fix files that have this issue?