All Activity

Thats a shame, I like the home screen.

I looked at the using restore page, and I am just curious if there is an easier way? I have copied the programdata and system folders. I have all my media on external harddrives. They will have the same drive letter on the new system. Is there an easier way to setup Emby on a new machine? I figured there would be a way to copy/paste the programdata & system folders after installing Emby new, and that would just overwrite all existing info. Just making sure I make this as easy as possible.

No, Universal Android and Web apps have somewhat different implementation (server version 4.10+ is mandatory for Spotlight feature in any case).

I thought it was the APK emby universal version & emby web Version 4.10.0.40

Like what? If you're referring to this: that's Emby for AndroidTV client app, you can download it from the store or sideload apk from here:

The portable downloads are there but the windows download is named "setup.exe" if the naming convention is like it is on the download page. download link from this page https://emby.media/windows-server.html https://embydata.com/downloads/server/release14/setup.exe Portable versions from that same page https://github.com/MediaBrowser/Emby.Releases/releases/download/4.10.0.40/embyserver-win-x64-4.10.0.40.7z https://github.com/MediaBrowser/Emby.Releases/releases/download/4.10.0.40/embyserver-win-x86-4.10.0.40.7z So given that the windows not portable version is "setup.exe" Where is the windows non portable version on the github page? Thanks,

How can I get my homescreen to look like this?

I have moved this to the Web App forum. This is not an app-specific issue and the legacy Windows app is no longer supported. Yet the legacy Windows app was displaying the hosted web app which of course supported and this is the right place for it.

Has Trakt changed the way they handle APIs? I had a trakt list that used to work, and no longer does.

...why?

Version: 26.0.23 During movie playback, bring up the video OSD. The tabbed items text (Info, Chapters and Cast & Crew) is being clipped when selected by the background. This version also leaves a dimmed background on the last selected tab. Last selected is defined by selecting one of the tabs (Info, Chapters and Cast & Crew) and than using the up arrow to bring up the playback display. Example - version 26.0.23 Not selected: Selected: For comparison, example of not selected and selected from previous version 26.0.22. The last selected tab does not have a dimmed background and the text is not clipped by the background when selected. Not selected: Selected:

Trakt Air Dates 8.11.0.0 Nothing you have saved changes — every setting keeps its name and default. New Air dates are now refreshed before they expire. A separate background pass runs hourly and rebuilds an answer an hour ahead of its cache running out, so there is never a window where an answer has gone stale and nothing has replaced it yet. Server-side, so it applies on every client Fixed The Upcoming list no longer stalls while air dates are fetched. Warming used to ride the same three-hour cycle as the shortest cache lifetime, so an answer could expire moments after a pass and then sit expired for nearly three hours — and whoever opened Upcoming in that window waited on Trakt while shows were fetched one at a time. That work now happens on the background thread rather than inside your request. Server-side, so it applies on every client No cache was lengthened to achieve this. The three-hour lifetime is still there so a newly announced episode isn't hidden for half a day, and Trakt traffic is essentially unchanged — the same answers were being fetched either way, just at a better moment Known limitation For the first hour after Emby restarts, nothing has been warmed yet, so opening Upcoming in that window can still wait on Trakt. Finished answers are kept on disk, so a restart is not a full rebuild and most shows will answer straight away — but a show whose answer has expired while the server was down is fetched on demand until the first warm pass runs A newly announced episode can take up to three hours to appear. That is the shortest cache lifetime, kept deliberately so the list is never half a day out of date; this release does not shorten it If Trakt itself is unavailable, the refusal is remembered for six hours rather than retried on every request. That keeps a real outage from turning into a retry storm, but it also means the list does not recover the instant Trakt comes back TraktAirDates.dll Trakt-Air-Dates-settings-8_11_0_0_1.pdf Trakt-Air-Dates-guide-8_11_0_0.pdf

Right, but what i'm saying is that as a beta tester i will have to wait for 4.10.0.40. And i never said that the features that he is showcasing are the features im looking forward to. Also, I liked the fact that he was happy about his newfound excitement about Emby as a media solution. Im rooting for Uncle Frank and his Mag555 4K Player! But hey, you do you my dude..

Did you try to trigger an artwork cache, but if it's already cached, Kodi is responsible to load artwork. I also recommend an update to plugin 12.X.

Hi quickmic, pls assist, I noticed that the posters takes a lot of time refresh, this only happen for movies, not for TVshow, when it finally refreshed, once I navigate away from movies then it return to blank again I have to wait for a while before it refreshed https://paste.kodi.tv/rifelepiyu

Oh so that would allow me to remove suggestions, trailers & folders tabs for a library then? I noticed with my elderly family members, for example, when they open the movies media folder, if it puts them in the Suggestions tab, they CONSTANTLY assume that is ALL the movies there are, then they contact me asking where all the movies went... And if they accidentally moved over to the Folders tab and then had that opening every time without realizing the tab needs to be changed to something else, I can see that REALLY confusing them . I also don't have trailers setup so that tab has always been empty wasted space for us. I will be interested in seeing how this plays out in the end if that is the case. Thanks edit: Just thinking, if thats the case, maybe something I would do with my more "technology-challenged" family is create a mirrored library for movies just for them that would have limited tabs on top, and leave the main library tabs alone for everyone else then just control which of the two libraries each person would get using the user access settings.

Hi, i've pushed an update to the dlna plugin to resolve this. Thanks.

Could you please inform about the status oof this request (option to display the title of the photo, within the photo of the diashow ....)/ Thnx, Peter

Hi. Best you start here: Quick Start

Right but what I'm saying is whatever Uncle_Frank is showcasing is already available to beta users (and has been for a while), no need to wait.

Just confirmed the IP shown in Emby Server is the same as my actual IP.

Agreed I hope they fix the shuffle / random to truly sample the entire library

Hols. No tengo respuesta sobre el problema No he podido usar Emby

Por el momento he encontrado en los dispositivos smart tv LG C5 (2025), de vez en cuando falla el Firestick 4k max de segunda generación.

I think I may have isolated this further, and despite the title of this thread, I don't believe AC-4 itself is necessarily the cause of the playback failure. I am seeing essentially the same problem described here with KTXL/FOX40 in Sacramento. This is an unencrypted ATSC 3.0 channel received through an HDHomeRun at v140.1. The channel previously worked in Emby. It currently works normally, with video and audio, using the HDHomeRun application. VLC also plays the HEVC video perfectly, but has no audio because my VLC installation does not decode AC-4. Emby, however, fails completely with: Playback Error No compatible streams are currently available. Playback failure: network I initially suspected AC-4, but the Emby FFmpeg log appears to point somewhere else. I am currently running Emby Server 4.10.0.40. The included FFmpeg identifies itself as: ffmpeg version 5.1-emby_2023_06_25_p6 Emby successfully probes the ATSC 3.0 transport stream and identifies: HEVC Main 10 video, 1920x1080, 59.94 fps, yuv420p10le English AC-4 5.1 audio Spanish AC-4 audio STPP/data/caption streams It then sets up a transcode of HEVC → H.264/libx264 and AC-4 → MP3/libmp3lame. In other words, the Emby FFmpeg build appears to recognize the AC-4 stream and has an AC-4 decoder available. However, before any frames are produced, the HEVC decoder repeatedly reports: [hevc] PPS id out of range: 0 Error parsing NAL unit #4. This repeats continuously, and ultimately zero video is produced. I then tested the HDHomeRun stream directly with a current FFmpeg installation, explicitly disabling audio so that AC-4 support was irrelevant: ffmpeg -hide_banner -loglevel info -i 'http://hd1.direct.webbnet.org:5004/auto/v140.1' -map 0:v:0 -an -t 15 -f null - The current FFmpeg/libavcodec successfully decoded the stream: Stream #0:0 -> #0:0 (hevc (native) -> wrapped_avframe (native)) and completed the 15-second test with: frame= 900 ... time=00:00:14.89 ... speed=6.59x There were no HEVC PPS/NAL parsing errors. The current FFmpeg could not determine the AC-4 audio parameters and reported the AC-4 streams as 0 channels/unspecified sample rate, which is expected since upstream FFmpeg does not provide the AC-4 support that Emby's customized build does. But that was deliberately excluded from this test with -an. So at this point I seem to have the following: HDHomeRun application: HEVC works, AC-4 works VLC: HEVC works, AC-4 does not Current upstream FFmpeg/libavcodec: HEVC works; AC-4 unavailable Emby's FFmpeg 5.1 build: AC-4 is recognized/supported, but HEVC decoding fails with repeated PPS id out of range: 0 This makes me wonder whether the actual regression is not AC-4 at all, but rather that Emby's custom AC-4-capable FFmpeg is still based on FFmpeg 5.1/2023 and its HEVC decoder is no longer handling something present in current ATSC 3.0 broadcasts. For comparison, before upgrading I was running Emby 4.9.5.0, whose included FFmpeg identified itself as: 5.1-emby_2023_06_25_p4 After upgrading to Emby 4.10.0.40, it is: 5.1-emby_2023_06_25_p6 The exact same HEVC PPS id out of range failure occurs with both versions. It therefore looks possible that Emby's AC-4 patches themselves are still doing what they are supposed to do, but the FFmpeg 5.1 codebase underneath them has become the compatibility problem. One additional test I can perform is to invoke /opt/emby-server/bin/ffmpeg directly against the HDHomeRun URL. That should distinguish between two possibilities: If Emby's bundled FFmpeg produces the same PPS errors when reading the HDHomeRun URL directly, this would strongly suggest the problem is the older HEVC/libavcodec implementation in the Emby FFmpeg build. If Emby's bundled FFmpeg successfully decodes the direct HDHomeRun stream, but fails when Emby feeds it the internal /LiveTv/LiveStreamFiles/.../stream.ts, then the problem would instead appear to be somewhere in Emby's Live TV ingest/repackaging/stream initialization path. Given that this ATSC 3.0 channel previously worked in Emby, VLC still decodes its video, and a current FFmpeg decodes all 900 frames of the 15-second test without error, I think the repeated HEVC PPS errors in the Emby FFmpeg log may be the most useful clue. I would be happy to provide the complete Emby FFmpeg log and perform additional A/B tests if that would help isolate it. --- Follow-up: I found that I needed to go into the Emby "Transcoding" settings and for "H.265 (HEVC)" settings, changing it from "Main Profile" to "Main 10 Profile" solved my issues. I also found that I needed to set my player to play highest quality with preferred DirectPlay. Using the stand-alone Windows app, I had to disable de-interlacing, as it was attempting to de-interlace a progressive picture.