All Activity

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.

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

Can you please show screenshot example to demonstrate? Thanks.

Ok we’ll take a look at it. Thanks:

Thanks — that clears it up, and re-checking my log you're right: on the Apple TV the play sessions do close before the next one opens (every "Removed" precedes the next "Adding" by ~1.7–2s, and that container never holds more than 1). So that wasn't the right case to lead with, sorry. Re-running concurrency per session container, though, I do have two cases where a container genuinely holds 2 open play sessions: 1) Emby for Android 3.5.36, single tablet, same title — the old play session is re-added 21 ms after the new one opens, and both stay open for ~61 s: 14:29:33.720 Removed playSession 9e8b4d46... from session 84659c77... 14:29:33.720 Adding playSession 25977433... to session 84659c77... <- new one opens 14:29:33.741 Adding playSession 9e8b4d46... to session 84659c77... <- OLD one re-added, +21ms 14:30:34.783 Playback stopped reported by app Emby for Android 3.5.36 14:30:34.786 Removed playSession 9e8b4d46... from session 84659c77... <- 2 open for ~61s 2) A play session added that never starts playback and is never removed, sitting alongside a real one: 16:14:33.362 Adding playSession 6c643c46... to session d2d1f2d0... <- no "Playback start", ever 16:14:33.895 Adding playSession a422bee1... to session d2d1f2d0... <- Emby for LG 1.0.50, real playback -> container now holds 2; 6c643c46 is never removed for the rest of the log Server-wide it's 53 "Adding playSession" vs 49 "Removed" over the day. So: In (1), if the client is meant to wait for the first to close, what would cause it to re-add the previous play session after the new one has already opened? In (2), if the first one never closes (app killed, network drop, or a session that never starts playing), does it keep counting against the limit? Is there a server-side timeout that reaps stale sessions, and how long is it? Note this log doesn't actually contain a "limit exceeded" event — I'll enable debug logging and post one that captures the moment the user hits the error.

I don't think it is relevant. Both of the example songs have an artist of some sort per Emby's own terminology. Don't miss the point here: UI between songs has to be consistent.

Hi, thanks for sharing. We will have anew ffmpeg build on the server beta channel very soon.

Hi, did you check what user24 mentioned?

The toggle has been added for the next app update.

It’s actually intended to wait for the first one to close before attempting to open the second.

That’s afterwards though right. The activity log would say if a plugin was updated.

That's why I was asking it always shows before restarting what it's updating and after reboot it even shows but this time it never showed a thing lol.