All Activity

I apologize for the delay in response. I suffer from a few heart problems that put me down from time to time. My biggest things here: #1. How do you move your collection to another drive and retain your collections? #2. Can you add a feature where you can mass select movies and TV shows and change the images In one shot. #3. Can you make it so that every movie and TV show you can use IMDB, ThemovieDB, TheTVDB etc for metadata? Some of the services link the wrong info and it’s pretty bad and in some situations you cannot use another site for Metadata.

re-welp... I was on the road for a week, just got back, and now it's happening again. Server log attached. The file I'm attempting to play is not an AV1, it's an MKV container, with a 4k Dolby Vision HEVC, dolby profile 8.1, profile main 10, 24mbps. Audio EAC3 5.1 atmos 768 kbps. I've watched tons of files like this in the past, they've always worked in the past. embyserver.txt

I was playing 4k DV HDR content in DV mode and caught a recurrence. Please see attached app log and logcat around the same time stamp. Seems to me like there's a player timeout when the display device changes due to the screensaver, I think it's switching to SDR because it says modeId 21 with defeaultModeId 21 since it should be SDR by default, and then I see modeId 10 which is probably HDR from the app trying to recover by transcoding (remux) which ends up triggering HDR instead of DV, and the video plays with the screensaver running in front of it. emby_android_1786045139632.txtlogcat_emby_android_1786045139632.txt

https://github.com/MediaBrowser/Emby.Releases/releases

Yes, where is taht located? My download page (windows selected) shows

You mean this release?

Currently the beta channel forces an install. Would it be possible to allow for Portable Installations of the beta version?

I still haven't gotten a prompt to update, so I don't know but... is this really it? 8 months later and still no fix for the horizontal layout?

@jan_axhell - don't worry, the issue is 100% on our side. Transcoding must be enforced in case when creating segmented webvtt subtitles. I have very recently explained how it works. And we actually had apps/server doing that, so this problem prroblem hadn't surfaced. It looks to me like this enforcement has been removed recently without knowing why it's needed.

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.

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.