All Activity

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.

In addition to the startup checks both of you might want to consider a monitoring component because if the mounts disappear while Emby is running a scheduled scan could also wipe the library. The devs could resolve this problem and I don't think it would take a lot of effort or be a major overhaul. Some solutions could introduce other useful library management features that Emby users already struggle with. The big question is what are the numbers? How many are affected by this and other problems that could be solved in one go?

Checking in on if this has been addressed yet.

Cause rather you're on the phone app, TV app, or the PC app they ALL look the same. No real difference based on the type of device. Looks like you guys took a page from Microsoft who got it wrong and ignored Apple who got it right.

Thanks @ebr. I understand the reasoning, but just giving you my user feedback.. Other users who aren't actively managing the system my have better experience.

Can I get the Host and Port

Please add a supported, user-scoped API to place an item in Emby's native Resume/Next Up rail without starting a playback session or changing play history. Use case: Plembfin (https://plembfin.com/) is an open-source, cross-service watch-history and queue manager (source: https://github.com/Lasikiewicz/plembfin). It calculates an Up Next queue and wants the next movie or episode to appear in Emby's native Resume/Next Up rows before the user has played it. Emby exposes the read side (for example /Users/{UserId}/Items/Resume) and clients can remove items, but there is no clean write operation for explicit queue membership. The current workaround is to report a synthetic client session through /Sessions/Playing, /Sessions/Playing/Progress and /Sessions/Playing/Stopped. This makes the item appear, but it also creates a real-looking playback session and can increment PlayCount. The integration then has to restore UserData and suppress the synthetic session. A small resume position alone is stored but filtered out of the native rail. Please add an idempotent endpoint or explicit QueueOnly/ResumeMembership flag that can add, remove and list an item for a user while: - leaving PlaybackPositionTicks/Played/PlayCount/watch history unchanged unless explicitly requested; - creating no playback session, now-playing event or scrobble; - supporting both movies in Resume and episodes in Next Up; - allowing normal playback to replace the synthetic queue membership with a real checkpoint. This would let Plembfin and similar trusted integrations manage queues safely across clients, removing the need for a fake 6% resume marker while preserving normal playback behavior.

For sue and thanks @skidmarks

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.

It easier than all that.... Use MP3TAG. Add album artist and artist tag to your music videos, nothing else (title should obviously already be there). Scan the library in emby and they will show up in the Music library. You would have to make some decisions on how to tag Movie sound tracks.

You might have to provide more details because in my case the new stable release did resolve the HW tone mapping.