All Activity

That doesn't prove that the fallbacks are working properly. What if they're being changed on purpose?

Hi, following your suggestion, I enabled debug logging and captured another occurrence of the repeated item-detail request loop. I have attached the sanitized Emby server debug log: embyserver-anonymized.txt How to locate the relevant requests Please search the attached log for either: /Items/446364 or: /emby/Users/[USER_ID]/Items/ The relevant continuous burst occurred on 23 July 2026 between approximately 14:05:00 and 14:08:53 CEST (12:05:00–12:08:53 UTC). Scope of this example The attached debug log documents one specific occurrence involving: - Emby Server: 4.9.5.0 - Client in this example: Emby for Android 3.5.34 - Platform: Amazon Fire TV / AFTSS, Android 9 - Endpoint: GET /emby/Users/[USER_ID]/Items/446364 However, this behavior is not limited to Emby for Android or Amazon Fire TV. I have observed the same repeated item-detail request pattern with multiple independent users and several different client platforms, including: - iPad / Emby for iOS - Samsung TV / Tizen - LG TV / webOS - Amazon Fire TV - embedded Apple WebKit-based clients The attached Android log is therefore only one clearly documented example of a broader cross-client pattern. Observed behavior The client repeatedly requested exactly the same item-detail endpoint: - 231 GET requests during the continuous burst - Duration: approximately 233 seconds - Average interval: approximately 1.015 seconds - Approximately 59–60 requests per minute - All 231 requests received successful HTTP 200 responses - Responses normally completed in approximately 1–2 ms The per-minute request counts during the burst were: - 14:05: 59 requests - 14:06: 60 requests - 14:07: 59 requests - 14:08: 53 requests before the protective block took effect The first request of the continuous burst appears at: 14:05:00.193 The last request that reached Emby appears at: 14:08:53.609 Its successful HTTP 200 response appears at: 14:08:53.611 There are also three earlier requests for the same item at approximately 14:01, so the attached log contains 234 GET requests for item 446364 in total. Please note that every request and its corresponding response are separate lines in the debug log. They should not be counted as two requests. Protective block After the number of identical requests became too high, my upstream security/rate-limit rule began rejecting further matching requests before they reached Emby. This explains why no further requests matching: /emby/Users/[USER_ID]/Items/ from this client appear in the Emby log after approximately 14:08:53. The absence of later requests in the server log should therefore not be interpreted as evidence that the client recovered or stopped the loop by itself. The security block was a protective consequence of the repeated requests, not the cause of the behavior. Conclusion This debug log confirms one instance in which an Emby client repeatedly requested the same item-detail endpoint approximately once per second, even though every request received a fast and successful HTTP 200 response. Although the client in this attached example is Emby for Android, the same general behavior has been observed across several unrelated Emby client platforms. It should therefore not be treated as an Android-only issue. The cross-client occurrence suggests that the cause may be shared Live TV/EPG polling, request scheduling, state management or current-program refresh logic. Could the Emby team please investigate which component schedules repeated refreshes of the currently selected Live TV channel item, whether this logic is shared across clients, and why the polling timer is not cancelled or reduced after successful responses? embyserver-anonymized.7z

Not sure what you mean? it would behave currently as what emby does, does it override already existing data?

What if some other people have that node filled in with the correct ID?

hi this is the file embyserver.txt

Let's see if 4.10 solves it soon. 4.10.0.20-beta came out recently. Release notes don't mention changes on transcoding, but 99% of times the release notes don't contain all changes, so who knows (shrug)

Emby needs an ad campaign around this. "Is your Plex down again and you can't get in? Then Emby is the pill for you!"

For those wanting a good laugh.

New version up (v1.0.6.0) in the catalog. Added support for TheIntroDB.

> I think we should probably change it, but then we'll have to deal with those that might be impacted by the change. Honestly, the only impact of this change is that instead of filling incorrect id in imdb, it will instead fill the tmdb GUID i really dont see any downside, nobody want incorrect information, as this also breaks the index imdb link in emby itself

Basically, he's wanting you to provide the server and transcode logs for the period you noticed the error. The media info for the video may help also.

@phoeskyI think what's happening is that it's not an issue of outdated cover images, but rather you have content still in your database that should have been deleted some time ago. Unfortunately this might be caused by defects in older Emby Server versions and would require a fresh database to resolve. @sa2000can help you confirm that and give you some next steps. Thanks.

HI, we'll have the new ffmpeg build on the server beta channel very soon, so stay tuned for that. Thanks.

is it clear?

ok can you please attach the emby server log from when that happened? Thanks.

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

Hi everyone, I'm having an issue with my Emby setup and my Samsung Smart TV, and I hope someone here can point me in the right direction. The Problem: The official Emby app on my Samsung TV loads perfectly. I can browse my entire library, see all the movie posters, metadata, and menus without any lag. However, when I hit "Play" on a movie, the video simply doesn't start. It just hangs on a black screen with an infinite loading spinner. My Setup: Emby Server OS: Cloud VPS Hetzner Client: Samsung Smart TV (Tizen) - Official Emby App 2.2.8 (because want to mountain the official one) Media Type: Movies (mostly MKV/MP4 files) What I've noticed: The network connection is definitely fine since the UI and all images load instantly. I suspect this might be an issue with the Samsung internal video player struggling with certain codecs, or a Direct Play vs. Transcoding failure. If I play the same movie on my PC or smartphone via Emby, it works perfectly. Has anyone experienced this specific issue with Tizen OS? Are there any specific playback settings in the TV app (like forcing/disabling Direct Play) or server-side tweaks I should try to bypass the Samsung player limitations? I can provide the server logs if needed. Thanks in advance for any help!

Hi, I'm seeing exactly the same behaviour described in this thread on my Synology DS918+ (Intel J3455), but I spent some time trying to isolate the problem and I may have some additional information that could help. Environment Emby Server 4.9.5.0 Synology DS918+ Intel J3455 (Apollo Lake) DSM 7.2.x Hardware acceleration enabled (Quick Sync + VAAPI) Tested with: Emby Web (Chrome on Windows) Emby Windows app The problem Whenever an HDR video is transcoded using hardware acceleration, the image becomes washed out, as if HDR is being displayed as SDR without proper tone mapping. If I disable hardware acceleration and let FFmpeg perform software transcoding, the colours are correct. Tests performed I tried several different files and configurations to narrow it down. HDR10 4K Hardware transcoding → washed out colours. Software transcoding → colours are correct. Dolby Vision Profile 8.1 (HDR10 compatible) Hardware transcoding → washed out colours. Software transcoding → colours are correct. HDR10 1080p Hardware transcoding → washed out colours. I also tested: Quick Sync only (VAAPI disabled) Quick Sync + VAAPI Different remote streaming bitrates Different transcoding resolutions Emby Web and Emby Windows The behaviour is always the same. What I found in the logs The interesting part is that Emby reports: Tone Mapping would be desired, but hardware tone mapping is disabled but immediately afterwards the processing plan says: ToneMapping (when possible) CanDoInHW = True WillDoInHW = True When I inspect the generated FFmpeg command, I only see: HEVC_QSV → vpp_qsv (resize) → vpp_qsv (P010 → NV12) → H264_QSV I cannot find any actual tone mapping filter being inserted (tonemap, tonemap_opencl, zscale, or any explicit BT.2020 → BT.709 colour conversion). So it looks as if the processing plan expects hardware tone mapping to happen, but the generated FFmpeg command never actually performs it. Question Is this expected behaviour on Apollo Lake hardware, or could this be a bug or regression in the current hardware transcoding pipeline? I've attached three different ffmpeg-transcode logs showing the same behaviour: HDR10 4K HDR10 1080p Dolby Vision Profile 8.1 (I also attach a software transconding log for this one) If needed, I can also provide the corresponding embyserver logs. Thanks! 4KHDR-ffmpeg-transcode-ce9e3357-e5fe-4e89-8083-135e1897db1b_1.txt 1080pHDR-ffmpeg-transcode-265e6ece-46b8-4317-bfd4-953bd2d6a758_1.txt 4KDV-Software_deco-ffmpeg-transcode-c8af9373-a1a5-40c3-a4ee-3037e5dd825d_1.txt 4KDV-Hardware_deco-ffmpeg-transcode-d506bd22-4ef2-4fc2-b0d1-0fc352bc8d04_1.txt

Next (possible) improvement: While testing the "Lock this item" workaround for markers getting wiped on library maintenance, found something worth knowing regardless of which plugin you use: locking an item does stop a Library Scan from wiping IntroStart/IntroEnd/CreditsStart, but it does NOT stop a Refresh Metadata from wiping them - confirmed directly, markers gone every time even with the item locked. So "lock everything and forget about it" isn't actually a complete fix, just a partial one. Planned for the next version: making the plugin event-driven instead of relying on manual/scheduled restore runs. The idea is to subscribe to Emby's item-updated event, so that whenever an episode's chapters change - whether that's from a Library Scan or a Refresh Metadata - the plugin notices immediately and restores that episode's markers right away, automatically. No more remembering to run Restore after every scan, no more locking items as a workaround. Biggest change to the plugin's architecture so far, so it'll get more testing than usual before a release. If anyone's got thoughts on this approach (or has run into other situations where markers get wiped that this wouldn't cover), now's a good time to mention them.

@LukeAre we stuck with this? If so, might need to revisit the premiere subscription

v1.4.0 is out - two more pieces of feedback from this thread addressed. JSON filenames now match the video's own filename, in both the central backup folder and media-folder modes - same convention the NFO insert feature already used. This was basically finishing what @crusher11 originally pointed out a few versions back: keeping the backup tied to its episode through renames, rather than sitting under a differently-named file that's easy to lose track of. Restore matching reworked to answer the "what if there's no TVDB ID" question from earlier in this thread. It no longer relies on filename at all for the primary match - it scans backup files by their actual content and tries, in order: TVDB ID, then IMDB ID, then filename as a last resort. Episodes with no TVDB ID aren't skipped outright anymore, they just fall through to the next method. Tested this on a full 587-episode library after the change: 587/587 restored, all matched by TVDB ID, zero needed to fall back to IMDB or filename. Also fixed a small bug where Backup and Restore were showing under two separate headings in Scheduled Tasks instead of sharing one group, and added a note to the README about a permissions gotcha - if you get an access-denied error, check whether you (or a zip extract) created the backup folder yourself before the plugin did; that's the #1 cause. Release (with prebuilt DLL) and full notes: https://github.com/guilty57/credits-intros-backup-restore/releases/tag/v1.4.0

Thanks hatharry! It plays the next song but sometimes after one or two songs of telling it next song, it will jump to a different playlist which is alphabetically the last one in my playlist order. Saying next song after it jumps to that playlist will only continue playing songs in that playlist and will not jump to different playlist. Appreciate all you and your team's hard work in getting this fixed!

Great article! The evolution of software and digital entertainment shows how innovation, creativity, and technology continue to shape user experiences. Learning from the history of software development helps businesses understand the importance of building reliable, engaging, and future-ready digital solutions. If you're looking for a top IT company in Karachi, choose a team that provides custom software development, web solutions, and innovative technology services to help your business succeed. Thanks for sharing this interesting article!

The error occurs during playback; the installation went smoothly except for the version that wouldn't start. The others installed fine, but when I select a video file with external subtitles, I get that error. If I remove the subtitles, it works correctly.

You can't go back . But you can install fresh an older version and reinstall the libraries