All Activity

Understood. Thanks for replying

What makes you think Emby is doing that?

That ID and PW are managed by this forum software, not us or your server but changing the local password should do what you want. We're working on new, better login methods that should make this moot.

Hi. The player is not able to play the content even when transcoded for some reason. Can you try searching for our standard android app (Just "Emby" on Amazon and "Emby for Android on Google) on the same device's app store and see how that compares? Thanks.

So by using emby connect login user cannot disable device access, That’s why I’m requesting this feature so it would be logged off and request the new password

No. If using Connect, he would still use his normal Connect credentials.

Go to the AppStore and update it

I am not sure I understand what you mean? Kevin Smith was a cornerback for the Cowboys in the 90s and he is not the same actor/director Kevin Smith seen in the image. My NFO file has him as an "actor" (seen below) And Emby is matching/identifying him as the actor/director, not me or my NFO file. It has to be Emby doing name based lookups, what else could be doing it? I suppose it could be a plugin I have, but I am unable to identify which one it might be. Might you be able to point it out? Plugins installed:

Here logs ffmpeg-transcode-cb39b20b-cb51-4d05-90a8-509ab6896a08_1.txt ffmpeg-directstream-794bdaec-49a7-4001-9736-4133b29f5188_1.txt ffmpeg-transcode-6f075e4e-ea1c-4748-994f-cb8c22be3930_1.txt ffmpeg-transcode-05751670-b63f-40a4-b586-ae4593b46c6f_1.txt embyserver (1).txt

No for all movie look. With Netflix and Amazon ...no problem !

Im not doing it for anyone he’s doing it for his account and reported that he can’t git red of device that has access after having a local password if he signs in through emby connect portal it would ask for his local password as well ?

Are you running with `-it` or non interactively? If running with `-it` you should omit the `t`, it was never supported by s6, and outright stopped working in v3 [0]. Running without `t` will properly catch CTRL+C and stop the container. If running non-interactively, right now `podman stop` will ultimately resort to SIGKILL indeed, just fixed that behavior and the next image should stop immediately. [0] https://github.com/just-containers/s6-overlay#terminal-support

Okay, so how are you doing that for one of your users? You know their Emby Connect credentials? Those credentials are intended to be managed by the end user, not the server admin. They should be able to change their password without consequence. If you wish to invalidate their connection to your server, simply change the password on the local user account on your server. That should invalidate all access tokens.

Actually, before even providing that info, please go into the settings in our app on the remote Roku and turn on "Debug Options". Then exit and re-start the app, wait about 2 minutes doing nothing and then go up to the user menu and select "Send Logs..." Finally, come back here and tell me what time you did that. Thanks.

No. That is undoubtedly the culprit. With the new upcoming server the home screen is much more complicated than "a menu". You have the ability to create some very complex queries for individual rows and a lot of rows. How many libraries do you have and can you show me exactly what home screen rows are defined?

Hi. We are still maintaining this for now and have no plans to release source code for it. Thanks.

From here: https://emby.media/community/index.php?/lostpassword

The upload bandwidth on the server is 300Mb/s. And there is no sluggishness on the Android Emby app, IOS Emby App, or the web, in the testing I've done. It's not, as far as I can tell, a server side response time issue. The remote Rokus in question are all on what might be considered slow connections on today's standards -- cellular and DSL. But not so slow that there should be issue simply loading a menu. This is only an issue when remote Rokus connect -- the local Rokus never have any issue -- so this next question seems unlikely to help lead to the cause... But, in my case, there is mildly restrictive firewall that has some limits on what anything on the server side of the firewall can access on the internet. Is there anything the server may be trying to reach out to when a Roku connects, that it doesn't try to reach out to when any of the other Emby apps connect?

Hi. Did they log into your server using Connect? Emby Connect

It is in active development but will be after this current release cycle.

Hi. Exactly what password are you changing? For Emby Connect, the password would be on the Connect/Forum account and you may not (probably don't) even know that.

Sorry, not sure why I missed this all those months ago! I had given up on TVHeadend as I had issues with an old USB tuner which I only recently replaced. My issue with having Emby do the recording is that Emby is running in an Unraid docker and the Unraid server is not 24/7. It sleeps overnight and then is on and off during the day depending on usage. So was looking to get Emby to create the DVR schedule in TVHeadend. Still would be a nice to have but I don't think that is currently possible.

We had power outage and now emby updated and now the horrendous view is here can it be please restored it back. Or at least tell us how can it be done to get rid of this useless view.

Okay, so I believe we've solved the crashing and a new release of the app will go out tonight. However, the real problem here is that, at least one of, your home screen row queries is timing out and the timeout is 60 seconds so this is a VERY slow query. We should try and determine exactly which one it is. What is the upload bandwidth on your server?