All Activity

@LukeI’m a bit confused. Was this intended for a different thread?

Are you sure it's not related to the server hosting the content? Also look through your log at all of the entries starting with Debug LibraryMonitor: Change detected Quite a bit of your files are being updated outside of emby, and the server's realtime monitor is kicking off lots of scanning activity in the background in response to those changes.

great, thanks!

It can be sporadic; but right now I can duplicate it on a particular show/episode - but how best to send you what you need? The STRM file has my credentials; is there another part of the log/or other type that might show something useful? I appreciate the effort very much.

I'm also having issues with background fanart. I initially thought something broke on my end, so I did a completely fresh install by downgrading Kodi from 22 beta 2 to 21.3 and reinstalling the latest version of the add-on, but the problem persists. I'm using the Arctic Zephyr Martian skin, and my background fanart is completely black. The only exception is if I use a view mode that specifically features the fanart front and center, then they load fine for some reason. Otherwise, backgrounds stay black. If I switch to Estuary, open a specific movie, and let its fanart load there, that fanart will suddenly start working as a background back in Arctic. However, it only works for the specific movies I’ve manually loaded this way, while everything else remains black. Even in Estuary, things aren't fully working. On the main home screen, items under "In Progress", "Newly added" etc won't show fanart initially. I have to go into the Movies library, navigate to that specific movie so its fanart triggers, and then go back to the main page. Only then does it display properly. It started in the recent days and I would assume it was with an update. Never had this issue before and I'm not sure where the issue is

That is a lot but for just one series I wouldn’t worry about it.

To say that “it doesn't [handle locked items]” indicates, to me, that it skips those items.

Thanks, great info. I'm just debating if it's worthwhile to manually edit the show itself and remove all the people that got added, and then lock the people section. It's a reality show so they are people that are never going to show up in any other content and it feels wasteful. If it's mostly harmless, I can keep it. But 750 felt like a big number and the impact to the server at the time definitely made me concerned.

It's not something you should have to worry about. No because on initial import we get the actor name and image from the movie or series metadata. We don't do an individual person lookup until you click on them. So that's an on-demand process, not an up front one. Your database probably has more rows of person objects than any other type, so yes, in extreme cases they can impact overall browsing performance, search performance, etc. But that is extreme cases only. What we'd like to do at some point is give them a little more separation in the database so that don't have any impact on these things.

OK this sounds like an older installation where we used to swallow the movie folder layer so that you wouldn't see it in folder view. This was removed a while back. Your existing libraries are left as is, but when you create a new one, it follows the newer convention where the folder layer is represented now.

Every movie, TV show, and actor is an item to lookup. So 750 actors is like 750 movies when it comes to lookup. They are each a separate item for which Emby needs data and a picture, and for some no data exists. Plus there are limits for the number of lookup's in a day from some providers. Once they are in the database they are in the database. Emby can use one instance of the actor data for many shows. When you dump that many on it it may slowdown for a while.

If you don't want to open a port on your router, then you should look at "tailscale" or "NordVPN Meshnet," but your users(clients) will have to install and configure this also. Otherwise: https://emby.media/community/topic/134638-how-to-guide-emby-connect-remote-access-and-basic-port-forwarding/ But it would be better and more secure to use a reverse proxy (Cady, Nginx, etc)

Before I go into full troubleshooting mode again, I'd like to understand which is the best config to aim for, in my case, if you don't mind, guys. I use Emby almost exclusively and even when I do remotely over other wifi or 5g, it's always from my phone with the Emby app for android, occasionally from my laptop. Generally the pointer is quickconnect though, not a public exposed port. Since occasionally I would like to be able to just invite a friend or two to watch a specific content that I normally put in a dedicated sub-library and for which I create separate logins, I can't count for them to use any quick connect of course, it would have to be - at best my knowledge - an exposed service, ideally over SSL, going though the router and straight into the Emby instance installed on the NAS. What would be the best config to achieve it?If I could avoid messing too much with the router it'd be best, as in the event I change provider I'd have to factor that in. Cheers

The default should already be to only record on the channel you started from. What other option do you need to change as well?

That looks like the exit menu, right? Are you pressing back?

Well I only saw this recently when a drive got low and added a new path to a new drive.. Only after that I saw these Gray folders.. When I make a new library and add a path from a old library, the new one shows only the parent folder gray and the movie folders as the original. When I reproduce the same directory paths and movies copied to a new drive every folder shows gray. Very weird so using the copied version I removed the individual movie folders and renamed the poster, clear, logo etc to movie-poster etc and this works with only the parent being gray and leaving the movies with the original posters. Not sure if this is how it's supposed to work but the only way I could get it to work.

@softworkzThe Linux client also behaves the same way. It says IsPaused: False but it's still reported as a Pause. vs Android: And also web app:

@LukeHere's the log from the most recent example. It happened in the web player again. Streaming gets to a detected commercial break and then stops. Scrubbing forward shows the correct preview image in the thumbnail for the new timestamp, but continues playing from the point of the freeze without skipping the commercials. ffmpeg-transcode-0a6cbfea-d828-4343-86fc-c2e26c074ea5_1.txt

I was trying to set up automation in Home Assistant to dim my lights when I play media by using the Webhooks plugin. I logged webhook requests coming in to Home Assistant to figure out why the unpause automation was not firing. That's when I realized, Emby is never sending a playback.unpause event to the webhook. As mentioned, the Emby Server log files also reflect this, I can see (Unpause) events firing when using other clients, but when using Emby Windows I never see an (Unpause) event in the logs. And unpausing actually fires another pause event instead of an unpause event as expected, which is easy to spot in the log file by the many consecutive (Pause) events logged with similar position timestamps within 100ms. If you look for (Unpause) in the log file you will only see a few from when I tested on Android TV and Web, which seem to be OK, but none from Emby Windows. It appears this issue is specific to Emby Windows. And it doesn't appear to be unique to the webhooks plugin, because you would expect to still see "SessionManager: Playback progress (Unpause)" events in the server log file if the issue was in the webhooks plugin, so it must be deeper down. Log file is attached. embyserver.txt

hi, can you please describe the issue that you're having?

HI, yes it is.

I'm not running 4.10 yet and only just realized it's no longer listed as beta. I didn't find any posts listing known issues or client limitations, so is server 4.10 fully supported and recommended with Roku 4.1 b70 ?

No problem, appreciate your help anyway, thank you

@StevenThank you for sharing I will go take a look and follow that post.

Not for everyone, though. If you can stop ranting for long enough to send the requested logs, maybe they can find out why it's happening to you. Paul