All Activity

Indeed I agree. So maybe an interface bug?

I would assume it's just a visual glitch, as your log shows nothing odd with the pipeline/HWA. @Luke

...and still need to obtain/configure a custom domain if you are going to use a proxy.

Do all the problem items have 40+ subtitles?

Even on the big poster it is very hard to read that tiny badge. The text is just way more clear.

I use Emby to get IPTV and NextPVR for DVB-S to feed Emby, Yesterday I dumped all the DVB-S channels and retuned for all of them as some weren't up to date. The 16 new channels appear and work fine in NextPVR apps. In Emby it only seems to show the first 5 of them. Any ideas ? I've tried restarting Emby and updating the guide in Emby but no joy.

First off, sorry for late answers. There's a lot of things going on i life right now so I have put this project on hold for a while. I will still prioritize trying to fix critical bugs! At the moment no, its not possible. You have to first set up a collection and then use the options to display selected collections. This might be something for the future to implement an "automatic studio" row where the user can type in what studios to show. It still has to create the collection i believe, so to manually set it up one time for each studio might be worth the hassle. I wont promise anything but I will keep it in mind Thanks for the report! I will look into this as soon as a get the time. I'm currently in the process of moving to a house so i already have my hands full.. But this is a major thing that i will try to fix asap! I know I have tested this when I built the function, must have got broken somewhere along the way. As a workaround for now (if using tags), you could set up two different entries but use the same tag-name. Emby wont know the difference and see them as the same. If also using the home screen section function , only set up for one of them and it should still show all of them. Yeah I see the issue and I agree with you. Those movies should not be included in the last played. Really appreciate your way to solve this, I'll look into this when I have more time to dig into this. Will take some time though since I have a lot going on i life right now. It's going on the to-do list!

@LukeWait am I going crazy or did you guys add back some of the clickable headers in TV Mode!!!!!!!!!!!!!!

Thanks for looking into this Attached. Screenshot from the interface: ffmpeg-transcode-7d4f5fd1-191c-4df6-b2d8-f5848e6137f8_1.txt

Ffmpeg log created would show what you're using, post the one written for that session. how to report a media playback issue

digging around. i realized the issue im experiencing are files with the classification of just EAC3 5.1, i have another show Maximum Pleasure Guaranteed and the audio codec on them are specified as English EAC3 5.1 and they play fine. wonder if there's something there.

As the title say. I'm currently running version4.9.5.0 inside a CT container in proxmox (previledged) - I've used Proxmox VE Scripts for the installation. It was showing the icon before. I'm not sure when it broke. I can see the Preferred Hardware Decoders in the settings, however when I'm reproducing something, in the Emby Server dashboard I don't see the hardware icon: However when I run: pgrep -a ffmpeg | grep -oE -- '-init_hw_device[^ ]*|child_device=[^ ]*|-hwaccel[^ ]* [^ ]*|vpp_qsv[^ ]*|-c:v:[0-9]+ [^ ]+' I can see: -init_hw_device child_device=/dev/dri/renderD128 -c:v:0 h264_qsv -hwaccel:v:0 qsv -hwaccel_output_format:v:0 qsv vpp_qsv@f1=deinterlace=advanced[f1_out0] -c:v:0 h264_qsv Additionally, if I disable the hardware encoding I see the CPU utilization going up when reproducing. So I'm sure that I'm using hardware. Is this a bug? Thanks!

I've been having this too on cachyos. Strangely a system reboot fixes it and I'm able to open and close the app having it log straight in. I think it usually occurs after putting the system to sleep. 2.319.0

That doesn’t make any sense Luke because currently actor images are downloaded in advance, so a few kb of extra txt for bio’s wouldnt impact. If it’s an agreement with providers then I understand, and if that’s the case can Emby be made not to freeze when offline and trying to fetch bio’s on demand? I reported the issue at Xmas, often we click on an actor to see what other movies they are in and with no internet it can freeze for up to a minute before proceeding.

Ive set it to what you set it to and nothing plays at all still the same thing, no compatible streams here's the logs from me doing this a moment ago embyserver.txt ffmpeg-transcode-5cb5ed43-f1ed-4d64-8108-21fef5d92cea_1.txt ffmpeg-transcode-75d8a96d-1470-40a0-8804-d9244a93bcb2_1.txt ffmpeg-transcode-640ffffa-12e2-45fe-8360-1e1b66fe50b0_1.txt ffmpeg-transcode-2087898b-b4f3-4bef-af7b-22afb9d7e276_1.txt ffmpeg-transcode-a3760825-ca8d-43a0-a70e-dda225835343_1.txt ffmpeg-transcode-d6f80c02-a6e7-4fe9-b7b1-d7647634120f_1.txt

The best function for me in the Android for TV app over the Android app is the channel number navigation for live TV.

Howdy, Since 4.10.0.x, clicking a search result takes about a minute before the detail page appears. Searching itself is instant. I traced it to a single query and I think I have the exact cause, with measurements. Still present on 4.10.0.21. I saw that 4.10.0.21 lists "improve search performance" in its changelog. I updated and re-measured: the request below was still running when I cut it off at 180 seconds. So whatever that improvement covered, it does not cover this. ENVIRONMENT Emby Server 4.10.0.20, then 4.10.0.21 (native .deb) Debian 13, 8 cores, 32 GB RAM, no swapping, library.db on SSD library.db 295 MB Reproduced in Emby Web (Firefox) and in Emby for Android Library contents, which turn out to matter: MediaItems total ........... 168,514 of which Person ............ 132,785 (79% of the table) ItemPeople2 rows ........... 310,687 Movies ....................... 4,109 Series ......................... 677 Episodes .................... 17,356 UserDatas rows .............. 21,552 of those with a search date ..... 23 WHAT IS ACTUALLY SLOW Not the search. SearchTerm=batman returns in 20 ms. The slow request is the "recently searched" list that the client loads on the search screen: GET /emby/Users/{uid}/Items ?SortBy=DateLastSearched,SortName &SortOrder=Descending &Limit=20 &Recursive=true &ImageTypeLimit=1 &EnableTotalRecordCount=false &WasSearched=true I let it run to completion instead of letting the client time out: 200, 458.6 seconds Emby logged it itself: Debug SqliteItemRepository: ItemsService.GetItems.GetItemList query time (slow 6x): 458608ms WHY THAT TURNS INTO A ONE MINUTE DETAIL PAGE Opening an item fires POST /SearchedItems and this refresh at the same time. The refresh holds a DB connection for minutes, so the POST queues behind it. From my log: Time: 30006ms GET .../Items?SortBy=DateLastSearched...WasSearched=true Time: 27512ms GET .../Items?SortBy=DateLastSearched...WasSearched=true Time: 25879ms POST .../SearchedItems The client gives up around 30 seconds and retries, but the server keeps burning a full core for another 7 minutes per abandoned request, so repeated attempts stack up and it gets worse the more you poke it. THE QUERY Captured with debug logging enabled on 4.10.0.20. Abbreviated where it repeats, happy to post the full text. select A.type, A.Id, ... , (select ShareLevel from UserItemShares join AncestorIds2 on AncestorIds2.AncestorId = UserItemShares.ItemId where UserItemShares.UserId = 3 and UserItemShares.ShareLevel not null and AncestorIds2.ItemId = A.Id order by Distance limit 1) as ShareLevel from mediaitems A left join UserDatas on A.UserDataKeyId = UserDatas.UserDataKeyId and UserDatas.UserId = 3 where A.Type in (1,2,5,6,8,9,10,11,12,13,14,15,16,18,19,20,21,22,23,24,25,26,27,28,29,34) AND Coalesce(UserDatas.DateLastSearchedInt, 0) > 0 AND (Coalesce(ShareLevel, 0) > 0 OR A.Type in (...) OR A.IsPublic = 1) AND A.ExtraType is null AND ( EXISTS (SELECT 1 FROM AncestorIds2 WHERE AncestorIds2.itemid = A.Id AND AncestorIds2.AncestorId in (8 library ids)) OR exists (select 1 from ListItems join ancestorids2 ...) OR EXISTS (SELECT 1 FROM itemPeople2 JOIN AncestorIds2 ...) OR Exists (select 1 From ItemLinks2 join ancestorids2 ...) OR Exists (select 1 from ItemLinks2 ItemLinks2TwoLevel where exists (select 1 From ItemLinks2 join ancestorids2 ...) and ItemLinks2TwoLevel.LinkedId = A.Id) OR A.Type in (27,28)) Group by A.PresentationUniqueKey ORDER BY MAX(UserDatas.DateLastSearchedInt) DESC, A.SortName collate NATURALSORT DESC LIMIT 20 ROOT CAUSE This line: AND Coalesce(UserDatas.DateLastSearchedInt, 0) > 0 Wrapping the column in a function makes SQLite unable to use the index that exists for exactly this purpose: CREATE INDEX idx_UserDatas_DateLastSearched ON UserDatas (DateLastSearchedInt DESC) WHERE DateLastSearchedInt IS NOT NULL In my database exactly 23 rows have a non-null DateLastSearchedInt. Instead of touching 23 rows, the query scans all 168,514 rows of MediaItems, running the correlated ShareLevel subquery and the five branch EXISTS chain on every one. Group by A.PresentationUniqueKey then forces the whole result set to be materialised before LIMIT 20 can apply. I tested this on a copy of library.db, changing only that one expression to AND UserDatas.DateLastSearchedInt > 0 and leaving everything else identical: original ................. 763 seconds without the Coalesce() ..... 0.003 seconds Run in the sqlite3 CLI with the Emby internal NATURALSORT collation replaced by a plain sort, since that collation is not available outside the server. WHY THIS MAY NOT SHOW UP IN TESTING I think the deciding factor is cast and crew depth, not library size. My video count is unremarkable: 4,109 movies, 677 series, 17,356 episodes. But MediaItems also holds 132,785 Person rows. Person rows are the worst case for that EXISTS OR chain. I checked: zero of my 132,785 Person rows have an AncestorIds2 row pointing at any of the 8 library folders named in the query. Normal library items match the very first EXISTS branch and short circuit immediately, which is cheap. Person rows cannot, so every one of them falls through to later branches before anything can match. That shows up cleanly when timing the same request per item type: Movie ......................... 6 ms Series ........................ 3 ms Episode ...................... 14 ms Audio ......................... 2 ms Book .......................... 1 ms MusicArtist .................. 65 ms BoxSet ...................... 174 ms Person ...................... 117 s no filter, what the client sends ... 458 s That is roughly 0.9 ms per Person row, scaling linearly. A test library with a few hundred fully scraped titles has maybe 3,000 to 10,000 people, so the same query lands somewhere between 3 and 9 seconds, which is easy to write off as a cold cache or a first load. At 132,785 people it becomes minutes. To be clear about what I am claiming: the bug is the unusable index. The people count is only what turns it from invisible into a hang. THINGS THAT ARE NOT THE CAUSE I checked these so nobody has to ask: I have zero orphaned Person rows, so a People cleanup does not help. ExcludeItemTypes=Person has no effect, the server still emits type 23 in the SQL Type IN list. Clearing search history does not help, the scan happens regardless of how many rows match. Not disk bound. One thread sits at 99.9% CPU for the whole duration. SUGGESTED FIX Drop the Coalesce() and compare the column directly, so idx_UserDatas_DateLastSearched becomes usable. Coalesce(x, 0) > 0 and x > 0 are equivalent here, since NULL fails both. That change alone took it from 763 seconds to 3 milliseconds for me. CLIENT SIDE CONTEXT dashboard-ui/search/searchfields.js gates this request on the server version: function supportsRecentlySearched(instance){ return apiClient.isMinServerVersion("4.10.0.5") } If the gate is false the function returns an empty result without issuing a request, so this only fires against 4.10.0.5 and newer. TV layouts skip it as well, and it only fires when the search box is empty. When it does fire, IncludeItemTypes is unconditionally null, which is what pulls all 132,785 Person rows into the query. Emby for Android sends the same unfiltered request, so this is not specific to the web client. For reference, the same request against the same database returns in 27 ms with IncludeItemTypes=Movie,Series,Episode,Audio,Book. WORKAROUND FOR ANYONE ELSE HITTING THIS Until it is fixed, injecting IncludeItemTypes=Movie,Series,Episode,Audio,Book,BoxSet into any request carrying WasSearched=true, either through a reverse proxy or by patching that line in searchfields.js, takes the request from 458 seconds to about 200 milliseconds. Happy to run further tests or post the full unredacted query and logs.

Might be worth letting users choose whether to restore from NFO or JSON. Auto-detect has completely screwed up all the Alfred Hitchcock Presents intros, and they're all the first 30 seconds of each episode. A simple bulk find-and-replace in the NFOs will fix that, whereas using ChapterAPI or the like would take ages.

One thing I noticed missing from the Android client versus the AndroidTV one is that there's no direct channel number navigation. I guess that's to be expected since Android devices wouldn't have a remote control or keyboard capable of numeric entry but it's a feature that I like in the AndroidTV client.

Those aren't even the logos anymore. The current ones are far more readable at a small size, I would imagine. The same is true of the Australian ratings logos.

@softworkznot sure if I should take this post as positive or negative...

Yes - the one in the server dashboard where things are set up.

im not at a computer right now, but i believe if you seek to near the end of the file and wait for playback to fully complete, q will not cause it to exit. i believe once the cpu pegging occurs the and there is nothing further to transcode at all the non-responsive state of the issue is exposed. i think i wrongly described it as a livelock at the point the cpu pegging occurs, i think there must also be no streams left to transcode. will reconfirm when i get to a computer in a few hours.

I’m at work right now but will give it a try when I get home in an hour or so. so far I’ve had trouble with lucky s01 e1-4 Elle s01 e1-8 Walking dead dead city s03 e1 the boys s05e8 as far as my Roku model I believe it’s this one https://www.target.com/p/roku-streaming-stick-2025-hd-roku-streaming-device-with-voice-remote-free-and-live-tv-access/-/A-94570936

Perhaps its a portmanteau?