HDR10 DV Transcoding

[KevinAtlee 3]

3 minutes ago, softworkz said:

@Luke - He had provided logs already, but now it's not about a playback problem anymore, but about "How to install the official Emby Server" on Unraid.

 

Unfortunately, I cannot help with that myself...

The Unraid Community Applications EmbyServer docker template could use a little love, when compared with the third party ones.

[softworkz 5066]

8 minutes ago, KevinAtlee said:

Shoutout to Emby support, the binhex container was recommended for ease of GPU configuration, but it was in fact the problem.
The official EmbyServer docker is not having any issues with DOVI HDR10 4K content being converted to HD.

5 minutes ago, KevinAtlee said:

The Unraid Community Applications EmbyServer docker template could use a little love, when compared with the third party ones.

At the moment, our server releases have about 140 different platform packages, which is a crazy figure, so that might make individual ones appear somewhat less shiny than community-provided ones, where people are putting a lot of effort into. 

Also, we love and welcome community engagement! I really don't want to talk those efforts down or discourage people in doing so. They should just not try doing their own FFmpeg builds - that's all, and then their packages might in fact be advantageous over our own in some details. 

 

[Jdiesel 1431]

Yes agreed. I don't understand why the official Emby docker in the Community app store does not follow unRaid's best practice. If you search the forums you will find multiple examples of unRaid users with permission issues. The linuxserver and binhex templates do not have this issue.

 

Quote

The best practice for PUID and PGID in Unraid Docker containers involves setting these environment variables to map the container's internal user to a specific user on the Unraid host. This helps manage file permissions and ownership within shared volumes. 

 

Recommended PUID/PGID Values:

 

• PUID=99: This corresponds to the nobody user in Unraid.
• PGID=100: This corresponds to the users group in Unraid.
   

Why these values are recommended:

 

• Default Unraid User/Group:

  Unraid's default user for many operations is nobody (UID 99) and the default group is users (GID 100). Aligning your container's PUID and PGID with these values ensures consistent file ownership and permissions when containers interact with data on your Unraid array.
• Preventing Permission Issues:

  Using these values helps prevent permission denied errors when accessing files created by your containers from other services or devices (e.g., SMB shares from Windows).

 

[Luke 42077]

4 minutes ago, Jdiesel said:

Yes agreed. I don't understand why the official Emby docker in the Community app store does not follow unRaid's best practice. If you search the forums you will find multiple examples of unRaid users with permission issues. The linuxserver and binhex templates do not have this issue.

 

 

Hi, we'll have our build and packaging developer review this. Thanks.

[KevinAtlee 3]

I'm not trying to dismiss that either, I don't envy the amount of work to maintain Emby across so many instances.
It's just a touch odd that someone had to go to the effort to build the template, and sort of labeled it, but put in default UID/GID that simply wouldn't work.
If anything, all I want to do is help as well, maybe a quick template for the build and packaging developer, of what seems to be the most standard config amongst the community variations.

Network Type: Bridge
Console Shell Command: Shell
Port: Web Interface: 8096
Path: Config: /mnt/user/appdata/embyserver
Path: Media: /mnt/user/media
Variable: PUID: 99
Variable: PGID: 100
Variable: UMASK: 002

When adding a "configuration type" to the template, adding the type to the label, and then it's purpose really helps for those not that savvy.
It helps to understand that if you want to add additional paths for segregated libraries not in the same parent folder, that you can.
Hope I save someone a few minutes some day!

[softworkz 5066]

 I've seen that @Lukehas already added a work item for internal review of this. It might take a while, but it will be looked into and responded here.

Thanks