All Activity

Why don't you want them all running? They spin down when not in use, but you need them all running so you can build redundancy into your setup. You want to duplicate files and spread the files evenly across drives, so if 1 goes down you can remove it without losing any files.

Your emby converting tool is a god send and works a treat but the file size gets bigger when I convert a recording it doubles the recording size. If it made the file size smaller would the quality suffer?

@Trufa2011?

have you setup emby connect for your users? Emby Connect

HI, yes this is an area that we need to look at improving on. Thanks.

HI there, can you please provide a specific example? How to Report a Problem Thanks !

Just following up on this. If Emby already knows the M3U simultaneous stream limit, I'd even settle for a simple warning instead of preventing the schedule from being saved. Something like: "Warning: This recording schedule exceeds your M3U simultaneous stream limit. Some recordings may be missed due to conflicts." That alone would make users aware of the issue before they discover missed recordings later.

Same problem here

I have someone coming over in a bit to buy 2 of these 26tb hard drives then I will make some money back and order a 5 bay nas. There is 1 thing though and it has me on the fence about connecting drives together as 1 and that is all the drives will be running not giving a breather for the drives. I'm just not sure what to do because I don't really want all the hard drives running all the time. I'm even thinking if I buy a 5 bay nas I could put in 1 drive and wait until it fills before adding more I don't know. The good news is I will be getting almost all the money back for 2 drives that I paid for 7.

Regarding the Dispatcharr architecture being discussed, I think this comes down to different design tradeoffs rather than one approach being inherently right or wrong. In my own implementation (which is a separate upstream proxy and not related to either Emby or Dispatcharr), I took a different approach to stream orchestration. Rather than relying on a centralized dispatcher model, each tuner session manages its own lifecycle, state, and recovery logic. If an upstream stream stalls or an FFmpeg process becomes unhealthy, the impact is isolated to that individual session instead of affecting unrelated tuners. Some of the design choices that have worked well for me include: Tuner-isolated session management — each stream operates independently, allowing failures to be contained rather than propagated. Fine-grained locking — synchronization is scoped only to the resources that require it, reducing contention and allowing unrelated sessions to continue operating. Asynchronous stream startup — stream initialization does not block the main control path. A watchdog monitors startup and recovery, allowing individual sessions to restart without impacting the rest of the system. Independent FFmpeg lifecycle management — each pipeline is monitored separately, allowing stalled or orphaned processes to be cleaned up and restarted without disrupting other active streams. I also support stream sharing because it is an efficient use of resources when multiple clients are watching the same channel. The tradeoff is that shared pipelines and buffers need to be managed carefully. In my setup, I limit retained live stream buffer duration (with Emby's Live TV buffer capped at 1 hour) to balance the benefits of sharing against the cost of maintaining long-lived shared state. Another point that often comes up is startup time. In my case, a new stream typically takes around 5–6 seconds to become available, and that is intentional. The proxy does not immediately expose an unvalidated stream; it first establishes the upstream connection, verifies the FFmpeg pipeline, confirms that data is flowing correctly, and builds enough buffer to provide a stable output. Could that startup time be reduced? Probably. However, for a backend proxy, I consider a few extra seconds of initialization a reasonable tradeoff if it results in fewer playback interruptions, better recovery behavior, and a more reliable stream once playback begins. I also think it is important to compare systems with similar goals. Applications like VLC or TiviMate are optimized for fast channel changes and direct playback. A backend proxy has different responsibilities: it needs to provide a stable, recoverable stream that can support media servers, recordings, multiple clients, and long-running sessions. None of this is meant as criticism of Dispatcharr. Different projects make different architectural choices based on their goals and constraints. I simply chose a model focused on tuner isolation, independent recovery, and stable stream delivery, and it has worked well for my use case.

Hi Paul, yes the Windows network is and was set to private. It's weird because the domain entry is working perfectly so I know it's possible to get into the server, it's just Emby Connect that won't work. Either through any app or app.emby.media on a browser.

StableBit Drive Pool won't replace a NAS, BUT you can connect the drives any way you want and Drive Pool will put them together under 1 drive letter. Instead of a NAS you could get a USB enclosure like this: https://a.co/d/09uKqZcH. I believe this one is setup and JBOD so each diak would be viewed independently by Drive Pool.

Luke Thankyou so much that was it. Sometimes I dont think out a process. I assumed it wasn't there just by Name.LOL I found it and yep its what i needed. Just an execellent sorce of data well put together. thanks again.

No, its not the same. Here is an Example: As you can see, after the credits there is still an important scene playing, but i am already getting the next episode button displayed. Now if we had the ability to set CreditsEnd, emby could then tell that there is still some time left after the credits and display a Skip Credits button instead. This is also not an uncommon thing. Is this explanation sufficient? If not let me know and i try to eloborate more detailed.

Yes that is a bit odd, hopefully it will get sorted in an emby server update.

Hi, please try the latest update to Emby for iOS. Thanks.

So this could replace a nas server running? I have no hardware for my hard drives it's just 3.5 hard drives from ebay so I would need to buy some extra hardware if not a nas.

Right.

OK please keep us posted. Thanks !

I am having the same experience with Android TV app 2.1.48g on Nvidia Shield Pro. Files that played without issue on 7/9 and 7/10 now require triggering playback correction three times before audio comes through. Standard Android app 3.5.36 stops playback after second playback correction. Audio output to stereo USB DAC. Server version 4.9.5.0 on Windows Server 2019 and Ethernet, recent server logs attached. ffmpeg-transcode-371cc02f-f4fc-402e-ae07-4036cbd62763_1.txt ffmpeg-remux-69641276-adf6-44df-9ad7-3589d378e9a2_1.txt ffmpeg-transcode-008b2e5f-7be7-4430-9d21-afc937f0e6f5_1.txt ffmpeg-transcode-3417c941-ca8f-41bd-a084-f1ad3c420bc4_1.txt

So if you set a recording and it is labelled part 1 and part 2 it only records part 1 and ignores part 2? What about if you set the recording to record all new for that show will it still not record part 2? Myself I have not recorded anything with 2 parts per 1 season. I set it to record everything new and then it auto converts everything for me to 8 so all my tv's can play it without any problems. It works really good and I like it so we never miss the news anymore thanks to emby working as good as it does, just set it and forget it.

Hi, isn't credits end the same as the end of the video file?

They are typically in the three week timeframe, but there have been some occasions when they take much longer. And that is also assuming we get through on the first try. Unfortunately they also have a tendency to reject updates for silly reasons because they don't take the time to learn how features work and end up thinking something isn't working.

The Emby app is running on a Roku Ultra connected to the TV. THX