[Support] binhex - Emby

[Emneth Design]

I'm on version 4.8.1.0 and unraid 6.12.6 and since the update getting ffmeg errors when transcoding with my RTX 3060 "Too many packets buffered for output stream 1:1" any ideas? Can the settings be changed does anyone know and if so.. how?

[Leinad86]

I have exactly the same problem. If anyone here knows the solution that would be great.

[jtownmassacre]

I have a similar issue where ANY transcode causes a solid pink screen.

 

From what I've been able to piece together, the issue is having to do with ffmpeg and the fact that Binhex's Emby container is written in Arch. The latest ffmpeg is v 5.1 and the Arch repos are still using 4.8 or something similar. This is causing the transoding errors and until the Arch repo is updated with the latest ffmpeg, the problem will persist. I THINK there is a way to manually update the ffmpeg version but that's above my pay grade.

 

I have also heard that this isn't the first time this container has had this issue. Do to the container being built with Arch it seems to me this issue will happen again.

 

All this info is what I've managed to gather from the few sources I've been able to find regarding this issue. If any of my information is wrong, please correct me.

[binhex]

9 hours ago, jtownmassacre said:

the issue is having to do with ffmpeg and the fact that Binhex's Emby container is written in Arch. The latest ffmpeg is v 5.1 and the Arch repos are still using 4.8 or something similar.

Not true, Arch tend to include bleeding edge stable releases and this image is no different, it includes ffmpeg 6.1.1, from the container:-
 

ffmpeg version n6.1.1 Copyright (c) 2000-2023 the FFmpeg developers

What is causing your issue i'm not sure, but its definitely not due to out of date ffmpeg.

[binhex]

On 2/14/2024 at 3:33 PM, Emneth Design said:

I'm on version 4.8.1.0 and unraid 6.12.6 and since the update getting ffmeg errors when transcoding with my RTX 3060 "Too many packets buffered for output stream 1:1" any ideas? Can the settings be changed does anyone know and if so.. how?

A quick google search reveals that this sort of error is most common due to bad source file, does this happen with ALL files or just the odd one?.

[jtownmassacre]

8 hours ago, binhex said:

Not true, Arch tend to include bleeding edge stable releases and this image is no different, it includes ffmpeg 6.1.1, from the container

I stand corrected. That info came from the Emby forums with a few people pointing the finger at the ffmpeg version being the issue. Someone even stated they manually updated to the latest ffmpeg and it started working again, so I'm at a loss as to what exactly the issue is. A google search does reveal others having the same/similar issue as me but the info is limited and wanting.

 

If anyone has any advice for me as to how to get H.W. transcoding back it would be greatly appreciated. If I can't figure it out in the next couple of weeks, it's going to force me to switch to a different container and I want to avoid that if I can.

[binhex]

2 hours ago, jtownmassacre said:

I stand corrected. That info came from the Emby forums with a few people pointing the finger at the ffmpeg version being the issue. Someone even stated they manually updated to the latest ffmpeg and it started working again, so I'm at a loss as to what exactly the issue is. A google search does reveal others having the same/similar issue as me but the info is limited and wanting.

 

If anyone has any advice for me as to how to get H.W. transcoding back it would be greatly appreciated. If I can't figure it out in the next couple of weeks, it's going to force me to switch to a different container and I want to avoid that if I can.

Ah had time to do some more digging, so looks like there are two versions of ffmpeg included, emby-ffmpeg and ffmpeg, and its the former that needs to be updated, so i have contacted the upstream dev about the issue, hopefully he should pick up my message and if he agrees then should bump the package version and i can then rebuild and we should be good.

[jtownmassacre]

Quote

Devs will have to confirm but @Lukeis this the correct ffmpeg for 4.8.1.0 on this platform?  Shouldn't it be 5.1?

12:01:11.196 ffmpeg version 5.0.0-emby_2022_05_07-spc Copyright (c) 2000-2022 the FFmpeg developers and softworkz for Emby LLC

 

Now that you mention the two versions of ffmpeg, It was indeed the "emby" version people were referring to. I'm sorry I didn't clarify that in my previous post.

25 minutes ago, binhex said:

Ah had time to do some more digging

 

I can't thank you enough for all you do for me and the community as a whole. Also, I really appreciate your timely response to this particular issue I'm (and a few others) facing! I love you containers and if one is available, I will use it for a sort of "standardized" folder mapping scheme.

Edited March 13 by jtownmassacre
typo

[jtownmassacre]

Any updates? People are leaving your container because of this.

[Mrtj18]

On 3/13/2024 at 1:59 PM, jtownmassacre said:

 

Hello, I'm having the same issues with the pink screen no matter which video I attempt to transcode. Has there been a fix yet? I'm on the latest docker.

Edited April 2 by Mrtj18
Change

[binhex]

Any updates? People are leaving your container because of this.

I'm waiting on the upstream update, if it doesn't happen by the end of this week then I shall have to compile it myself and include in the build

Sent from my 22021211RG using Tapatalk

[mr.unnatural]

I'm trying to set up a new onn. 4k Pro Android streaming box with Emby but I can't connect to the server to complete the setup.  I'm using the latest binhex Emby docker in unRAID.  I select the server or user or try to connect manually and can never get it to connect.  I'm sure I've managed to hose up the password but every time I try to do a password reset I can't connect to the URL that I'm given in the password reset text document that gets downloaded to my cache drive in the binhex-emby folder.  I've tried four different web browsers with the same result.  I ran a Windows diagnostic in Microsoft Edge and it's telling me the device I'm trying to connect to is not responding so I'm kinda stuck.  I've posted in the Emby forums but even the developers don't know what to tell me.  I figure since this is happening with the docker that you would have a better idea of what's going on.

 

FWIW, I use Emby an several Shields and a Roku box with no problems.  I just can't get it to connect to the Emby docker on the new box without a password.

 

I just need a way to reset my password that actually works.

Edited May 20 by mr.unnatural

[vfast]

On 5/20/2024 at 5:28 AM, mr.unnatural said:

I'm trying to set up a new onn. 4k Pro Android streaming box with Emby but I can't connect to the server to complete the setup.  I'm using the latest binhex Emby docker in unRAID. 

It's a little unclear what you are describing as the issue and your environment.

 

When you say can't connect. Do you mean can't log into?

Have you checked the docker log to see if there are any hints to issue?

Have you checked for common things like port conflicts etc?

You say you use Emby on other devices. Are these connecting to a server or stand alone?

[mr.unnatural]

When you first set up a new device with Emby it asks for the user name and the password which I believe was used when you first set up and registered Emby.  You can access Emby from a PC using the same login credentials, but I inadvertently replaced the password saved in my browser with one that I entered by accident and I am unable to reset it.  When you try logging into the Emby docker in unRAID from a PC you get an option that says "Forgot Password?"  If I select that option it downloads a text file to the cache drive as /appdata/binhex-emby/passwordreset.txt (see the attached text file).  The text file has a URL that you connect to and enter a 4-digit PIN provided in the file that expires after about ten minutes.  I cut and paste the URL in my browser and it just times out and never connects.  I have tried it in several different web browsers both with and without my VPN turned on and it never connects.  Without the password I can't connect to the Emby server in unRAID to set up my new streaming box.  Is the password stored somewhere on the cache drive with the Emby docker file that would allow me to recover it?

 

Here's a screenshot of the screen that pops up on my PC when I attempt to connect to the Emby server:

 

 

 

Here's the screenshot when I select the user "Dave" from the first screen.  The password it's asking for is the one that I no longer have access to and I am trying to reset.

 

 

passwordreset.txt

Edited May 21 by mr.unnatural

[mr.unnatural]

Problem solved!  I was finally able to login to the Emby server in unRAID.  One of the Admins at the Emby forum suggested that I substitute the actual IP address of the server with the one posted in the password reset text file that gets downloaded to my server.  I did that and it connected immediately and allowed me to enter the PIN number from the text file.  I now have access to Emby on my new Android box so I'm up and running.  I had resorted to installing Kodi on the box so I could access all of the media from my server, but it literally took several days to scan everything and get it all set up.  All of that is already done in Emby so that turned out to be completely unnecessary.

[vfast]

Thats good. Enjoy!

[mr.unnatural]

If you look at the image below you will see where the conflict lies.  The In-Home (LAN) access IP address shown on the Emby Dashboard page is the one that shows up in the resetpassword.txt file.  Looking at the actual IP address in the address field at the top of the web page clearly shows that is not the IP address for my server so I don't know how it comes up with the address listed on the Dashboard page.  Prior to resetting the password, neither IP address would allow me to connect to the server.  The actual IP address would prompt me for my password whereas the one shown on the web page would simply time out and never connect.

[Emneth Design]

14 hours ago, mr.unnatural said:

If you look at the image below you will see where the conflict lies.  The In-Home (LAN) access IP address shown on the Emby Dashboard page is the one that shows up in the resetpassword.txt file.  Looking at the actual IP address in the address field at the top of the web page clearly shows that is not the IP address for my server so I don't know how it comes up with the address listed on the Dashboard page.  Prior to resetting the password, neither IP address would allow me to connect to the server.  The actual IP address would prompt me for my password whereas the one shown on the web page would simply time out and never connect.

You possibly have the network set as a custom proxy which would indeed change the in-home (lan) ip address to something like that? You could change the NETWORK TYPE back to HOST which would change Emby back to the 192.168 range for the time being.

Hope that helps.

Andy

[elcapitano]

Where do I find the new version?

[JonathanM]

9 minutes ago, elcapitano said:

Where do I find the new version?

Wait for the update to be built into this container, or move to a different container.

 

[ctny]

I am new to unraid. Setting up binhex-emby has been quite straight forward. However, can someone explain what is "Path: /shared:" for?

 

I can see the explanation is "Container Path: /shared... This is a special Docker Volume used to store shared information between containers, such as incoming port number."

• First, I don't see this path in other docker images, so I don't understand how other docker images will be able to share information with binhex-emby? 
• Second, how does this technically work? Different containers will look into this directory on what ports are already claimed then pick new ports accordingly?
• Third, if this is for all docker images to share info, I am assuming there is a default directory on unraid to facilitate this sharing already, so what is the default path?

The reason this is bothering me is that the "Appdata Backup" plugin keeps complaining the default value for the path does exist, but I don't want to set a wrong value.

 

 

 

[binhex]

On 7/29/2024 at 12:35 AM, ctny said:

First, I don't see this path in other docker images, so I don't understand how other docker images will be able to share information with binhex-emby? 

That's because i am still in the process of updating all the templates to include it, and do note that template changes are not pushed out to users, you would need to refresh your template by deleting the container and reinstalling from CA.

 

On 7/29/2024 at 12:35 AM, ctny said:

Second, how does this technically work? Different containers will look into this directory on what ports are already claimed then pick new ports accordingly?

Its a docker volume that includes a simple file that contains the assigned incoming port, the end user would then need to work out how to use that port number to configure the application, some apps are harder than others to configure.

On 7/29/2024 at 12:35 AM, ctny said:

Third, if this is for all docker images to share info, I am assuming there is a default directory on unraid to facilitate this sharing already, so what is the default path?

It is not a host path, its a docker volume so you will not be able to see it or browse it from your host, its only visible from containers that have the docker volume mounted, if you want to see the contents of the docker volume then drop to the 'console' of a container and do 'ls -al /shared'

On 7/29/2024 at 12:35 AM, ctny said:

The reason this is bothering me is that the "Appdata Backup" plugin keeps complaining the default value for the path does exist, but I don't want to set a wrong value.

That is a bug in that plugin, it looks like it does not support docker volumes and is assuming (incorrectly) that its a docker bind mount and thus is trying to find the host path 'binhex-shared' which does not exist - ignore it.