All Activity

Since it appears not to affect everyone on the older server versions, here's a log. I watched Bus Stop successfully on 3.5.63, then updated to 3.5.65 and attempted to play The Glass Key, getting the error. embyserver.txt

I simply tried to play a movie.

Android 3.5.65 seems to work fine for me and I'm on a previous beta server version 4.10.0.31. Tried playing something with and without subs. Was there a specific function that resulted in the above?

@AnsellAlso i have a version here i would like you to try if possible. It doesn't have some of the changed made to the 5.61.0.0 stable so if that works it helps narrow down the problem a lot! EmbyIcons.dll

Looking into it right now and i need some information if possible. You say the latest stable version 5.61.0.0 also has problems? That version doesn't have the new pre-draw function so that limits the search a little.

PM sent (as encoding groups from private trackers do not enjoy seeing their stuff open in the world). No special characters other than a "+" here and there, but that character is not present in other movies where theme.mp3 works without issues; and the other way around, the other files where themes are not working there are no "+" around. It's just that they were the movies that "broke" last year.

Greeting all, First let me start out as i'm not sure that this is the correct place, or even forum to be discussed but anyway, here goes. For all for the media that I own, I wanted some way to have recommendations based on what I watch and what I Like/ in my Emby library, so this is where this stems from. I initially build it to run in Unraid, but as a Docker it can run anywhere, so unraid, Docker etc. I built using AI a Dashboard that reads your viewing content from Emby API and is able to do so quite nicely & then bases recommendations based on this taste profile. This runs as a light weight FastAPI Backend with a React SPA front using SQLite for the Data Component. See the attachedREADME.md It can if you want send items to your backend Sonarr/Radarr for Meta Collection if you do that sort of thing. There are five main tabs/pages to review, working backwards: Settings: Two Main sub settings: Sync Settings: Hour based Auto-Approve: Match Percent: This will automatically approve items to Sonarr/Radarr for meta data. You can also change the threshold to balance the returned results. Max Items per week: Value = Number Status: API Connection status overview: (Not much to explain here) Library: Will show your current Library, so Series & Movies: Taste Profile: This needs to be ran first once the docker container is running to read the Emby API Data. Once it runs it gives you such an overview. Dashboard: Approval Queue: Status overview of what is waiting/approved/rejected/total. To start, first Generate by clicking the Generate Recommendations button. This will give a list back based on Series/Movies that you have watched/liked. The Service Connections show the API Connection status: I did think to add a download client status, but I think in the final version this will be removed as it is not relavent to the project over all. The main dashboard overview you can Approve, Reject or Skip Forever, the options speak for themselves. Her is a zoomed in view of one recommendation. The IMDb are clickable links, as are the TMDB as they will take you to the site/info. There are also classifications for the genres. There is also a 'Why' to show it recommenced this. Some items on the back log are such like Favourite Shows to add extra 'taste' to the recommendations. Anyway, to sum it up, would anyone find this useful, is it worth asking you guys for your opinion & would anyone like to try it if I posted it to Github? Comments welcome! Best, all0gIc. (All-Logic)

I can only assume the above means the newest version of the app is incompatible with any version of the server prior to the latest beta which added the subs-on-skipback thing. I'd have thought making sure the stable app was compatible with the stable server was the most obvious step, but then I'm not a software developer or anything.

I will also contact you promptly if there are any new findings.

Very useful plugin, thank you for your work. Is it possible to add the option to set the "Sort title" of a collection created by the plugin in the "Create Collection" tab, maybe just after the Collection Name? I would like to manage where the collections should appear under collections to sort of create "sections" of different kinds of collections. Kometa also does something like that by default by adding something like "!_42_" in front of the sorting title.

As it is now it works just like when opening a library in a browser. I will look into if there might be a problem some where.

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

Hi, yes we can look at that. Thanks

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

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!