All Activity

At the time of my post it was 2.2.54, although today I got the update for version 2.2.55, which sadly did not change anything for me either.

Hi you do not need to compile the plugin, just drop the file attached from one of the other posts into your Emby plugins folder, restart Emby and it should be in you plugins section I think for the current version of the plugin you need to host the file online or use a link as I do not think it can use a local file, just uploaded it OneDrive/google drive and then add the link to the plugin it should work

And I need help with add lisI also need help adding a channel list locally from a Windows PC.

We need all the development energy we can get on this, I don't think anybody has exactly cracked it yet. Do you imagine this working alongside something like Dispatcharr or as an alternative? Dispatcharr is great overall around bundling together streams into channels and switching over automatically when things stall, but it's still not as robust as I want/as it needs to be to play nice with Emby consistently (mainly because Emby itself is coded to give up on streams and recordings way too easily).

OK, attaching the server logs to cover use of both the stock Android app and the Android TV app. Times are the approx. times I played the various media. Stock Android app - this is the one I have problems with SD playback 7:22 Live TV channel 2 (BBC2 SD) - completely frozen 7:25 Live TV channel 102 (BBC2 HD) - plays ok 7:28 SD recording (Lord of the Flies) - completely frozen 7:31 HD recording (Back to Black) - plays ok Android TV app 7:34 Live TV channel 2 (BBC2 SD) - plays ok 7:37 Live TV channel 102 (BBC2 HD) - played ok but then froze after a few seconds 7:39 SD recording (Lord of the Flies) - plays ok 7:42 HD recording (Back to Black) - plays ok embyserver.txt ffmpeg-remux-64a14e30-9e3d-487e-8711-9c035a3a136a_1.txt ffmpeg-directstream-55a87328-1f51-4fa0-a2f8-17445f43aaab_1.txt ffmpeg-remux-905b9347-ca77-416c-9f78-0e0bd910a850_1.txt ffmpeg-remux-bef7499b-de3c-4533-af83-e35ff4d76fb9_1.txt ffmpeg-remux-ec8722e6-15a2-4eda-a4ff-546783f2734f_1.txt ffmpeg-remux-4cb5e546-2b5f-4d7a-8506-3e053a9cc06d_1.txt

Have video media in folders like tv, movies, .... When I select the movie library I want see all the movies that are in the movie folder. It seems like thats how it was before, but now I am just be seeing a specific genre.ie all action etc

Figured it out - solution was a mismatch in the Emby Network settings for public HTTPS port - corrected it to match the Caddy port and now Emby Connect works. I'm assuming I could still access the server remotely through the domain directly because it would default to the right port, but Emby Connect was trying to use the port I had specified in the Network settings which was wrong.

Really interested. The upcomng section for non US users was always bothering me. There was a project almost a decade ago that replaced US airdates with european ones, but it unfortunately died.

Only use Emby for basic library scanning and only in the server settings using scheduled task so third party software can see it. This also applies to identifying shows/movies when it comes to correct IMDB/TMDB info but never let Emby download new pictures/thumbs etc and only let third party software do the scraping Set emby metadata for all librarys to 0 in downloading picture/backrop etc. So basically use Emby features as little as possible. N/

After collecting several days of logs and monitoring Emby's RSS memory usage with Splunk, I think I've narrowed the problem down considerably. Hopefully this helps identify the root cause. It seems my problem might be different from the one originally described in this post, but the consequence is the same. Environment Emby Server 4.9.5.0 Synology DS1819+ (32 GB RAM) DSM 7.3.2 Debug logging enabled I have attached graphs showing Emby's RSS memory usage together with total system memory usage. What I observed Initially I thought the problem started around midnight because that was when I first noticed the memory growth. However, after collecting more data, that doesn't appear to be the case. Emby performs a "Scan media library" task every 30 minutes throughout the day. The logs show this is completely normal: IntervalTrigger fired for task: Scan media library Queueing task RefreshMediaLibraryTask Executing Scan media library The task validates the libraries and runs the usual post-scan tasks: ValidatePhysicalRoots ValidateTopLibraryFolders CleanDatabaseScheduledTask CollectionLibraryPostScanTask RefreshIntrosScanTask The important observation is that these scans occur all day long, even while memory usage is completely stable. What changes At some point (the exact time varies it seems. I thought it was midnight but today it started out of nowhere around 7:25 PM after a whole day of stability), something changes internally. From that point forward, every subsequent scheduled library scan causes Emby's RSS memory to increase by approximately 3 GB. The scan itself only takes about one minute to complete, but the allocated memory is never released after the task finishes. The memory graph looks like a staircase. Here's a comparisson of yesterday's incident at midnight and today's incident at 7:25. They behave the same. Today hasn't failed yet but I'm letting it allocate memory until it crashes, so I have more data to keep debugging: Eventually Emby reaches approximately 25-28 GB RSS and the Linux kernel OOM killer terminates the process. Important observations The process is usually sleeping after the scan completes while still holding all of the allocated memory. the scan itself takes less than a minute but the memory is never freed. This doesn't look like continuous allocation during the scan itself. Instead, it looks as though something allocated during the scan remains referenced after the task has completed. Things I have already ruled out I tried removing the Statistics plugin as per @Lukesuggestion. No effect. Truth is: I don't use many plugins. The ones I use are: Addic7ed, Backup & Restore, Bluray Folder Support, DLNA, DVD Folder Support, Emby Guide Data, Fanart.tv, Kodi companion, M3U TV Tuner, MusicBrainz, Nfo Metadata, OMDb, OpenSubtitles, Port Mapper, Studio Images, TheAudioDb, TheMovieDb, TheTVDB, Webhooks and XmlTV If any of these plugins is bad let me know, I can remove it and see what happens. Current hypothesis At this point I don't think the 30-minute scheduler itself is the problem. The scheduler appears to be acting as the trigger for a code path that begins behaving differently after the server has been running for some time. Earlier scheduled scans complete normally and memory returns to the baseline. Later scheduled scans appear to retain several gigabytes of memory after each execution, eventually exhausting all available RAM. So the question may not be: "Why does the scheduler run every 30 minutes?" but rather: "What changes internally so that a previously healthy Scan media library task begins retaining memory after completion?" If it helps, I have: debug logs covering both the healthy period and the leaking period, graphs showing the RSS increase after each scan, kernel OOM logs, and can provide additional information if there's anything specific you'd like me to capture. I have plenty of evidence but at this point I still haven't found what damn rogue process is eating up my memory. Any suggestions would be immensely appreciated.

Hi Emby im running a 2.2.8 Samsung TV app on a 4.9.5.0 Windows server and recently my tv shows have skipped to the next show randomly during play. I’ve never had this issue before in the 15+ years of running Emby and wonders if this has been seen before or if it might be my HDD developing issues? It’s pretty random and skips at different locations on video playback. any clues please?

I've been quietly experimenting with something over the past several months that I think may interest a lot of Emby Premiere users. The goal is simple: make IPTV behave more like a reliable tuner. Many of us have run into the same challenges: Random stream drops. Channels that work perfectly one day and fail the next. Shared upstream streams causing conflicts between multiple viewers or recordings. Long recovery times when something silently breaks. Having to manually restart, refresh, or intervene when live TV should just work. Most IPTV tools do an excellent job organizing the pieces — playlists, guides, channel mapping, and metadata. The challenge starts after playback begins. What happens when the live stream itself becomes unreliable? I've been exploring a concept that adds a reliability layer between the IPTV source and the client. The idea is not to replace existing IPTV management workflows, but to make the delivery pipeline more resilient. A few things I've been testing: Detecting stalled streams automatically. Recovering failed sessions without affecting other channels. Keeping individual streams isolated so one failure doesn't cascade. Improving channel startup behavior. Handling unstable upstream behavior without requiring constant babysitting. Using available hardware acceleration where it makes sense. One area I've been particularly interested in is the "silent failure" problem. A stream can look connected, but no longer actually be delivering usable data. The client doesn't always know whether the provider failed, the encoder stalled, or the connection simply stopped moving. The concept I'm testing looks more like this: Live stream active ↓ Upstream stops delivering data ↓ Pipeline detects the stall ↓ Failed session is isolated ↓ Stream is rebuilt automatically ↓ Service returns A real-world example from testing: 15:17:47 Sports channel — upstream paused 15:18:33 No data detected — recovery initiated 15:18:37 Rebuilding stream pipeline 15:18:46 Upstream stream restored 15:18:48 Playback pipeline healthy again During 3 days of continuous uptime across 42 recording sessions, here is exactly how the code managed upstream turbulence: 11 Drops: The system intercepted and recovered from 11 hard disconnects (outages lasting over 50 seconds). To prevent Emby from throwing an error and failing a recording during the rebuild, the code keeps the pipeline alive—seamlessly transitioning from the live feed to an FFmpeg-generated "Service Outage" slate to guarantee a continuous, healthy stream. 1 Stall: The source went dead (zero bytes for over 50 seconds) but bounced back moments later. Rather than prematurely dropping the axe on the FFmpeg session, the pipeline simply held the pipe open. Because this pipe never closes—whether delivering the active broadcast or the recovery slate—Emby receives a flawless, unbroken stream, completely blind to the upstream chaos. This is exactly the real-world scenario this solution was built for. The interesting challenge isn't detecting that something failed — it's recovering quickly enough that the viewer experience remains uninterrupted. I’m keeping the code private for now to focus on final stress testing and refinements, but the performance data has been incredibly promising. My ultimate goal is to bridge the gap between fragile, high-maintenance internet streams and the rock-solid reliability of a traditional hardware tuner. I look forward to sharing more with you all as soon as it's ready for public release.

Guys sorry to nag @FrostByteand @Lukebut here in New Zealand we still only have version 2.2.8 of the Samsung app yet I think you’re well past that in other locations? I get Samsung is not your problem but how come the very long delays in updates please as I’m still reluctant to keep sideloading to get stuff fixed? anynideas please?

It does work now. So. of I understood correctly I note need to delete the beta to install the stable from scratch? Right?

Hi, can you give it another try? Thanks.

I have this EXACT same issue. Everything streams fine on the lan, streams fine externally using router NAT port assignments. However, with Tailscale the movies stream fine, BUT the music / audio files streams with no sound. Really weird. Mark

Hi, yes we recognize that we need to add a solution for this. Thanks.

maximum pleasure guaranteed

Hi, we will disable this for firefox until such time when we are able to carve out settings space for this .Thanks.

Right now we are still engaging in some back and forth with them.

OK we are looking into it. Thanks.

I been watching this show & it's really good What's are you guys watching ?

Was before and after and activity logs shows nothing either is why I thought it was odd.

Hi, we’ll have to see what we can do with the guide data. For now I think you’re doing the right thing.