All Activity

That's not the purpose of this plugin. Take a look at others, such as: or

Hi, yes we can look at that. Thanks

Update: Looks as though this is an issue with 4.11.0.5 beta as I have reverted docker container to the previous release (4.11.0.4) and all is now working again. No other config has been changed so this appears to be a version specific issue.

This actually took hours of research and testing to get working. I will attach a .docx (WORD) file with this report in it for easier use. Emby Live TV Pluto Streams Breaking at Ad Breaks — Working Solution Using Threadfin + FFmpeg I wanted to document a problem I was having with Pluto TV streams in Emby and the solution that finally worked. Hopefully this saves somebody else the considerable amount of troubleshooting it took to isolate the problem. The Problem I run Emby Server on Windows and use M3U sources for Live TV. The Pluto channels themselves would initially play correctly in Emby. The problem occurred whenever Pluto transitioned into or out of an advertising break. The typical behavior was: · The channel starts normally. · The program plays normally. · Pluto reaches a commercial/ad break. · The stream freezes, stops, or otherwise becomes unusable. · Emby does not recover automatically. · The channel has to be refreshed or restarted manually. · The same problem can happen again at the next advertising transition. This was particularly noticeable on channels containing Pluto's dynamically inserted advertisements. The important distinction is that this was not simply a problem with Emby being unable to open the stream. The stream worked. The specific problem was Emby maintaining playback when the underlying HLS stream changed during Pluto's commercial transitions. Test Environment The configuration used while troubleshooting was: · Windows 11 Pro · Emby Server 4.10.1.0 · Emby Premiere · Threadfin 1.2 Build 37 · Threadfin running on the same Windows PC as Emby Server · Threadfin configured to use FFmpeg · Emby's bundled FFmpeg executable used by Threadfin · Pluto TV M3U source · Pluto TV XMLTV/EPG source The actual Pluto M3U and XMLTV source URLs have intentionally been removed from this post. Whenever one of those source URLs would normally appear, it is represented as: <your source m3u here> Download Threadfin Threadfin can be downloaded from its official GitHub releases page: https://github.com/Threadfin/Threadfin/releases Download the appropriate release for your operating system. For this setup I was using Windows, so I used the Windows AMD64 version. What We Tested Before Finding the Solution 1. Direct M3U Into Emby The original configuration was essentially: Pluto M3U ↓ Emby This worked for normal playback. The problem occurred when Pluto transitioned into or out of commercials. At one of these transitions, the stream could stop and Emby would fail to recover without manually restarting the channel. 2. Separate HLS Proxy We also tested a separate HLS proxy between the source and Emby. The path looked approximately like: Pluto ↓ HLS Proxy ↓ Emby That particular proxy did not solve the advertising-transition problem in our configuration, so it was removed. That does not necessarily mean every HLS proxy will fail. It simply did not solve this particular problem during our testing. 3. VLC Testing VLC turned out to be extremely useful for diagnosing what was happening. At one point, we opened one of the Pluto streams and saw the repeating animated Pluto screen. Initially it appeared that the stream was stuck in an endless loop. Instead of closing VLC, we left the stream running. Eventually, the actual movie resumed. That was an important discovery. The repeating Pluto animation was not necessarily evidence that the stream had permanently failed. It could instead be part of Pluto's advertising/slate period. This helped distinguish between a genuinely dead stream and a stream that was temporarily showing Pluto's advertising/slate content. That changed the direction of the troubleshooting. The Working Solution The configuration that finally solved the playback problem was: Pluto M3U ↓ Threadfin ↓ FFmpeg Buffer ↓ Emby The guide data is handled separately: Pluto XMLTV ↓ Emby This separation ended up being important. Threadfin handles the video streams, while Emby receives the EPG/guide data separately. Step 1 — Install Threadfin Download Threadfin from: https://github.com/Threadfin/Threadfin/releases Install or extract the version appropriate for your operating system and start Threadfin. In this setup, Threadfin and Emby Server are running on the same Windows computer. Because they are on the same computer, localhost/loopback addresses can be used between them. The Threadfin interface will normally be available at something similar to: http://127.0.0.1:<THREADFIN-PORT>/ Use the actual port assigned to your Threadfin installation. Step 2 — Add Your Pluto Playlist to Threadfin Open Threadfin. Go to: Playlist Create a new M3U playlist. For the Pluto M3U source, enter: <your source m3u here> Use only M3U and XMLTV sources that you are legally authorized to access and use. This guide does not provide or endorse any particular stream provider or playlist source. The actual source used during testing has intentionally been removed from this post. Step 3 — Configure FFmpeg Buffering This was one of the most important parts of the solution. Configure Threadfin to use: Buffer: FFmpeg Threadfin requires access to FFmpeg for this configuration. Configure Threadfin with an appropriate FFmpeg installation for your operating system according to Threadfin's documentation. The important part is that the working configuration was: Pluto HLS Stream ↓ Threadfin ↓ FFmpeg Buffer ↓ Emby Do not disable the FFmpeg buffer after getting the setup working. This appears to be the component that allows Emby to receive a more stable continuous stream while Pluto changes segments around advertising transitions. Step 4 — Add Your XMLTV Source to Threadfin We also added the Pluto XMLTV source to Threadfin during configuration. In Threadfin, add your XMLTV/EPG source. For purposes of this post, that source is represented as: <your source m3u here> Again, the actual source URL has intentionally been removed. Threadfin can use the XMLTV information while organizing/mapping the channels. However, as explained later, we ultimately did not use Threadfin's generated XMLTV file as the final guide source inside Emby. Step 5 — Select the Channels You Want in Threadfin Go to: Threadfin → Mapping Select the channels you want Threadfin to export. This is an area where some care is required. Threadfin's Mapping/Bulk Edit interface can be confusing. The checkboxes on the left side are used to select channels for editing. Selecting a checkbox does not necessarily mean the channel has already been properly activated and exported. After selecting your channels: 1. Make sure the channels you want are marked Active. 2. Make the required mapping changes. 3. Finish the edit window. 4. Click the main Save button on Threadfin's Mapping page. 5. Give Threadfin time to rebuild its playlist. Important Warning About Bulk XMLTV Mapping Be careful when using Threadfin's Bulk Edit function. During troubleshooting, we accidentally assigned the same XMLTV channel to a large number of unrelated channels. The result was that completely different channels could appear to have the same television programs in Emby's guide. For example, unrelated movie, television, news, and other channels could all inherit the same guide information. If this happens, check your Threadfin XMLTV mappings. Do not bulk-assign one XMLTV channel ID to hundreds of different television channels. Step 6 — Verify Threadfin's Generated M3U Once your channels have been activated, Threadfin generates its own M3U playlist. For a local installation, the address follows this format: http://127.0.0.1:<THREADFIN-PORT>/m3u/threadfin.m3u Open that URL in a browser or text editor. You should see channel entries that look approximately like: #EXTINF:0 ... tvg-name="Pluto TV Horror" ... http://127.0.0.1:<THREADFIN-PORT>/stream/<STREAM-ID> This is important. Emby will no longer be receiving the upstream Pluto stream directly. Instead, Emby receives Threadfin's local stream URL. Conceptually: Upstream Pluto URL ↓ Threadfin ↓ Local Threadfin /stream/ URL ↓ Emby Do not publicly post: · Signed provider stream URLs · Authentication information · API tokens · Session IDs · Account credentials · Private playlist URLs Step 7 — Add Threadfin to Emby Open: Emby Server Dashboard → Live TV Choose: Add TV Source → M3U For the M3U URL, enter Threadfin's generated playlist: http://127.0.0.1:<THREADFIN-PORT>/m3u/threadfin.m3u If Emby and Threadfin are installed on different computers, you will need to use the appropriate network IP address instead of 127.0.0.1. Our Final Emby M3U Settings The working M3U tuner configuration in Emby was: M3U URL http://127.0.0.1:<THREADFIN-PORT>/m3u/threadfin.m3u Other settings: · User Agent HTTP Header: blank · Referer Header Mode: Both · Referer HTTP Header: blank · Simultaneous Stream Limit: 1 · Only import channels containing these groups: blank · Import guide directly from M3U: unchecked · Preferred channel image source: Guide Data Source · Allow mapping to guide data using channel numbers: unchecked · Tags: optional During troubleshooting, we accidentally ended up with two Emby M3U TV sources pointing to the exact same Threadfin playlist. Once everything was working, the duplicate source was removed. The final configuration contains only one Threadfin M3U TV source. Step 8 — Test Playback Before Working on the Guide Before worrying about guide data, verify that the streams work. Pick a Pluto channel that is likely to encounter advertisements. We used: Pluto TV Horror Start the channel through Emby. Then leave it running. Do not manually refresh it when an advertising break begins. Our Ad-Break Test This was the test that confirmed the solution. The sequence was approximately: 1. Start Pluto TV Horror in Emby. 2. The movie begins normally. 3. Pluto reaches an advertising break. 4. We leave the stream alone. 5. Pluto displays advertising/slate material. 6. The movie resumes automatically. 7. Another advertising break occurs. 8. Emby stays connected. 9. Programming resumes again. 10. The channel later transitions into another movie without requiring a manual refresh. We also observed actual Pluto advertisements rather than only the Pluto animated slate. The important result was: Emby survived multiple Pluto advertising transitions without requiring the Live TV stream to be manually restarted. That was the exact problem we were trying to solve. Why Threadfin + FFmpeg Appears to Work I do not want to claim that we identified the exact internal cause of the failure inside Emby. What we were able to demonstrate through testing is: Direct playback: Pluto HLS ↓ Emby could fail when the stream changed around Pluto advertising transitions. Buffered playback: Pluto HLS ↓ Threadfin ↓ FFmpeg ↓ Emby continued playing. Based on those observations, Threadfin plus FFmpeg appears to provide Emby with a more stable continuous stream while the upstream HLS playlist changes during advertisements. That is an observed result from testing rather than a claim about the exact underlying Emby bug. Guide Data Was a Separate Problem Once the playback issue was solved, we still had to fix the program guide. Initially, we tried using Threadfin's generated XMLTV output in Emby. Threadfin provides a local XMLTV URL similar to: http://127.0.0.1:<THREADFIN-PORT>/xmltv/threadfin.xml During our testing, this did not give us satisfactory guide results. At one point, unrelated channels were showing the same programs. We eventually discovered that some of that was caused by incorrect XMLTV mappings created during bulk editing. We also inspected Threadfin's generated XMLTV. There were situations where a channel definition existed but corresponding <programme> data was not appearing as expected. Rather than continuing to troubleshoot Threadfin's generated EPG output, we separated the two functions. Final Guide Solution Threadfin remains responsible for video playback. Emby receives the XMLTV guide directly. So instead of using: http://127.0.0.1:<THREADFIN-PORT>/xmltv/threadfin.xml as the final Emby guide source, we added our Pluto XMLTV source directly to Emby. The actual XMLTV URL is intentionally censored. Use: <your source m3u here> Step 9 — Add the Guide Directly to Emby Go to: Emby Server Dashboard → Live TV → Guide Data Sources Choose: Add Guide Data Source Select: XML TV For the XMLTV URL, enter: <your source m3u here> Then configure it approximately as follows: · XMLTV URL: <your source m3u here> · User Agent: blank · Keep the normal Emby category settings unless you specifically need to modify them · Enable the guide source for the appropriate tuner/device · Save Then run: Refresh Guide Data Allow Emby time to download and process the EPG. Guide Results After moving the XMLTV source directly into Emby, the guide began showing sensible program information for individual channels. During testing, examples included channels such as: · Pluto TV Trending Now · Pluto TV Spotlight · Pluto TV Franchise Favorites · Pluto TV Icons · Pluto TV Action · Pluto TV Comedy · Pluto TV Romance · Pluto TV Crime Movies · Pluto TV Thrillers · Pluto TV Horror Instead of unrelated channels showing duplicated guide information, the channels now displayed their own appropriate programming. Final Working Architecture VIDEO <your source m3u here> ↓ Threadfin ↓ FFmpeg Buffer ↓ Threadfin Generated M3U ↓ Emby ↓ Live TV Client Threadfin's local M3U looks like: http://127.0.0.1:<THREADFIN-PORT>/m3u/threadfin.m3u GUIDE <your source m3u here> ↓ Emby ↓ Program Guide The guide does not need to travel through Threadfin in the final configuration. Final Emby Configuration In the end, our Emby Live TV configuration contains: One M3U TV source http://127.0.0.1:<THREADFIN-PORT>/m3u/threadfin.m3u One XMLTV guide source <your source m3u here> There are no duplicate Threadfin tuners. The direct upstream Pluto M3U is not added separately to Emby. Final Threadfin Configuration Threadfin contains: Pluto M3U source <your source m3u here> Pluto XMLTV source <your source m3u here> Buffer FFmpeg Threadfin then exports the selected channels to: http://127.0.0.1:<THREADFIN-PORT>/m3u/threadfin.m3u That generated playlist is what Emby uses for video. What Not to Do Based on our troubleshooting, I would avoid the following: · Do not feed both the direct Pluto playlist and the Threadfin playlist into Emby for the same channels. · Do not leave duplicate Threadfin M3U tuners in Emby. · Do not disable the FFmpeg buffer after getting this configuration working. · Do not automatically assume the repeating Pluto animation means the stream has permanently failed. · Do not repeatedly restart the stream during an advertising slate before giving it time to resume. · Do not bulk-assign one XMLTV channel to hundreds of unrelated channels. · Do not enable channel-number guide matching unless your configuration actually requires it. · Do not publicly post authenticated, signed, private, or tokenized stream URLs. · Do not post provider credentials. · Do not assume the video source and guide source have to take the same route into Emby. Separating video delivery from guide delivery turned out to work much better for us. Troubleshooting Method Test 1 Open your upstream stream in VLC: Source ↓ VLC See whether it survives an advertising transition. Test 2 Open the Threadfin version of the same channel in VLC: Source ↓ Threadfin ↓ FFmpeg ↓ VLC Leave the stream running through an advertising break. Test 3 Then test: Source ↓ Threadfin ↓ FFmpeg ↓ Emby This helps determine exactly which layer is causing the failure. Threadfin Logs Are Very Useful Threadfin's log helped confirm what was happening. During successful playback we could see Threadfin: · Opening the upstream stream · Starting FFmpeg · Receiving data · Buffering the stream · Providing the resulting stream to the client If the upstream stream continues but Emby fails when accessing it directly, testing Threadfin with FFmpeg buffering is worthwhile. One Important Lesson From the Pluto Holding Screen Do not automatically assume the stream is broken when you see Pluto's animated screen repeating. During our testing, we initially thought the stream was stuck. We left it running. Eventually, the scheduled programming resumed normally. In our case, that screen was occurring during Pluto's ad/slate period. This distinction became very important while diagnosing the original Emby problem. The Result After changing the video path to: Pluto ↓ Threadfin ↓ FFmpeg ↓ Emby the channel survived multiple Pluto advertising transitions. After separately providing the XMLTV data directly to Emby, the program guide also populated correctly. We now have: · Working Pluto Live TV channels in Emby · Working channel logos · Working guide information · FFmpeg buffering through Threadfin · Streams that survive Pluto advertising breaks · No need to manually refresh the channel after each ad break The final configuration has been stable through the tests we performed. Useful Link Threadfin releases: https://github.com/Threadfin/Threadfin/releases All Pluto source URLs in this post have deliberately been replaced with: <your source m3u here> Use your own authorized M3U/XMLTV sources. Hopefully this helps anyone running into the same Emby Live TV problem. Emby_Threadfin_Pluto_Solution_Report.docx

Hi all, was all working absolutely fine on Friday PM when I triggered a manual recording. Ever since then all recordings (scheduled or ad-hoc) fail. Each time an entry is logged in server log. The message is the same for ad-hoc or scheduled recordings. No config has been changed. I did clear out 200GB of junk data from /transcoding-temp yesterday, could this have done something? Server log extract; 2026-10-04 08:10:50.822 Error LiveTV: Error recording to e6669715aee9450d9b2f50c9cddd2776 /share/Media/Recordings/Live Formula 1 (2009)/Live Formula 1 2026_10_04_07_55_00 - Bahrain Grand Prix Race.ts *** Error Report *** Version: 4.11.0.5 Command line: /system/EmbyServer.dll -programdata /config -ffdetect /bin/ffdetect -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3 Operating system: Linux version 6.18.38-Unraid (root@Develop) (gcc (GCC) 15.3.0, GNU ld version 2.46.1-slack151) #1 SMP PREEMPT_DYNAMIC Mon Jul 6 15:22:03 PDT 2026 OS/Process: x64/x64 Framework: .NET 8.0.28 Runtime: system/System.Private.CoreLib.dll Processor count: 8 Data path: /config Application path: /system System.ArgumentNullException: System.ArgumentNullException: Value cannot be null. (Parameter 'consumerId') at Emby.LiveTV.TunerHosts.LiveStream.AddConsumer(String consumerId) at Emby.LiveTV.EmbyTV.GetChannelStreamWithDirectStreamProvider(BaseItem dbChannel, String providerChannelId, String streamId, String consumerId, List`1 currentLiveStreams, CancellationToken cancellationToken) at Emby.LiveTV.LiveTvManager.GetChannelStream(String id, String mediaSourceId, String consumerId, List`1 currentLiveStreams, CancellationToken cancellationToken) at Emby.Server.Implementations.Library.MediaSourceManager.OpenLiveStreamInternal2(LiveStreamRequest request, String consumerId, CancellationToken cancellationToken) at Emby.Server.Implementations.Library.MediaSourceManager.OpenLiveStreamInternal2(LiveStreamRequest request, String consumerId, CancellationToken cancellationToken) at Emby.Server.Implementations.Library.MediaSourceManager.OpenLiveStreamInternal(LiveStreamRequest request, CancellationToken cancellationToken) at Emby.LiveTV.EmbyTV.RecordStream(TimerInfo timer, DateTimeOffset recordingEndDate, InternalActiveRecordingInfo activeRecordingInfo) Source: Emby.LiveTV TargetSite: Void AddConsumer(System.String)

I surmise that once the disk-based image storage took effect, all images had to be regenerated; the resulting media library was so massive that the server became overwhelmed, causing all images to fail to load. The correct approach would have been to display the images first and then replace them one by one as a slow background process.

This is what I had explained in a recent conversation: As you had noticed yourself already, this is not properly implemented, and never been looked at it. It even turned out to be a potential security risk, that's why we have disabled it until we have safe and a fully working implementation for it. Thanks

I noticed an problem related to Music Assistant. When I set “ValidateImageTags” to “true,” Music Assistant can no longer load the images correctly. WARNING (MainThread) [music_assistant.helpers.images] Failed to fetch image from http://xxx.xxx.xxx.xxx:8096 When I set “ValidateImageTags” back to “false,” the images load correctly again. Maybe hatharry could take a look at this? I think he’s the maintainer of the Music Assistant Emby integration. @hatharry

If you continue to see issues - try the guidance provided in this thread, there have been changes to database settings:

I can't send you the logs because I've already rolled back the version; switching versions again would cause the media library to blow up.

As I said, it's controlled by Feature Access, so either disable this: Or remove this from your Home Sections:

@seanbuffhere r some screen shots. first one shows my permissions (web), 2nd are the options I have (no live tv option), 3rd same no option in drop down menu, 4th is the Home Screen on Apple TV app. Its showing live tv section but I want to remove it.

Possible for me to get you to send me a log?

Versions 5.61.0.0, 5.61.0.1-beta, and 5.61.0.2-beta all fail to load the media library home screen; reverting to version 5.60.0.1 restores normal functionality. I hope this is fixed soon. The exact cause is unclear, but in the problematic versions mentioned, the "Pre-draw posters" process remains stuck at 0% progress.

Yeah, I saw... There is a 4.10.1.0 available. I'm gonna upgrade to that first, and see what happens. This usually uses about 4-5 GB of RAM, and it has slowly increased to over 17 GB which is why I even noticed. I just wanted to capture the logs for the issue in case it's a bigger thing. TheAudioDB is kinda important to my metadata. I'll try that as a last resort... Thanks!

It looks like the plugin AudioDB is failing. I would remove that, and see if that helps you move forward. Error in TheAudioDB *** Error Report *** Version: 4.10.0.40 Command line: /system/EmbyServer.dll -programdata /config -ffdetect /bin/ffdetect -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3 Operating system: Linux version 6.18.38-Unraid (root@Develop) (gcc (GCC) 15.3.0, GNU ld version 2.46.1-slack151) #1 SMP PREEMPT_DYNAMIC Mon Jul 6 15:22:03 PDT 2026 OS/Process: x64/x64 Framework: .NET 8.0.28 Runtime: system/System.Private.CoreLib.dll Processor count: 12 Data path: /config Application path: /system MediaBrowser.Model.Net.HttpException: MediaBrowser.Model.Net.HttpException: NotFound at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.SendAsyncInternal(HttpRequestOptions options, String httpMethod) at Emby.Server.Implementations.HttpClientManager.BaseHttpClientManager.SendAsync(HttpRequestOptions options, String httpMethod) at AudioDb.AudioDbAlbumProvider.EnsureInfo(String musicBrainzReleaseGroupId, IDirectoryService directoryService, CancellationToken cancellationToken) at AudioDb.AudioDbAlbumProvider.GetMetadata(RemoteMetadataFetchOptions`1 options, CancellationToken cancellationToken) at Emby.Providers.Manager.MetadataService`2.ExecuteRemoteProviders(MetadataResult`1 temp, LibraryOptions libraryOptions, String logName, TIdType id, IRemoteMetadataProvider`2[] providers, MetadataRefreshOptions options, CancellationToken cancellationToken) Source: Emby.Server.Implementations TargetSite: Void MoveNext() And Emby can't finde the webpage at AudioDB Http response 404 from https://www.theaudiodb.com/api/v1/json/2139078587215309723505/artist-mb.php?i=4580d83b-093e-4241-91fb-2dd71f5f1f3f after 205ms Not sure if this is a AudioDB web-server issue or if they have changed paging format.

Good evening, I am about to do the update that is available to see if it fixes this, but I wanted to capture the logs in case it doesn't and report it... Two servers running in UnRAID Docker Containers have started consuming RAM. The logs show repeated errors, as if something is stuck in a loop. They both have frozen progress for "Scanning Media Library". Everything seems to be working, no signs of failure, except for the RAM usage slowly being eaten. embyserver.txt

I noticed starting with 3.5.64 there were some changes to the connection dialogue at startup, not seeing it on my phone anymore but I did see it when in airplane mode. My server connections are fast, maybe I would see it on my shield but I haven't plugged it in yet as I'm traveling so just don't have a point of comparison yet. Yes subtitles can be turned off now, working again.

I restarted that LG TV and now it seems to play SRT (SubRip) subtitles just fine. So updating Emby app on LG solved this.

Resolved in 3.5.65. Thanks guys.

3.5.65 Support automatic subtitles after skip back (requires Emby Server 4.11.0.5+) Core UI Changes from 26.0.31 to 26.0.32 Fix regression with turning off subtitles not being remembered

Emby for Android 3.5.65 Released Download Emby for Android Changes 3.5.65 Support automatic subtitles after skip back (requires Emby Server 4.11.0.5+) Fix regression with turning off subtitles not being remembered

Hardware transcodes still failing... ffmpeg-transcode-151095e3-24a1-4c4f-9b26-bcba69a67a5d_1.txt

New beta version up in the catalog (v2.9.1.5). Added: 1) Option to have the plugin wait with detections if any playback sessions are running. 2) Post-credit detection. Added a setting to enable the detection of Post-credit detections. The plugin runs past the first positive detection to check if there is any other positive detections, threats them as post-credits and adds the credit mark there instead. If the Emby team adds "CreditEnd" to the chapter type in the future this can be made to work with that. Please note: This is experimental for now as it will require a good amount of testing to be sure it's precise enough for every-day use.

Hi, no, the trakt plugin isn't built for that. it's built to map one trakt user to one emby user.