All Activity

Please forgive me. Next time I will try to be a better mind reader to determine what everyone means/meant and purchase Ms Chloes old 800# and charge a small fortune.

Did you just get the update prompt like me? it may be a fix for your recordings of part 1 and part 2.

So that's why we need to look at a specific example. Thanks.

It really depends on the input formats vs the output formats. For example hevc can have a smaller file size with the same quality as h264.

Yes but after I restart my server it will update again to a newer one.

4.9.5.0 has been available since May.

Emby server just showed a new update, cross your fingers.

Your going to have to help me with a solar panel install next just to power this and save money

HI, please try Emby for Android 3.5.38: Thanks.

HI, please try Emby for Android 3.5.38: Thanks.

HI, please try Emby for Android 3.5.38: Thanks.

It just feels like driving 5 cars at once to get to work in the morning what about copy everything to another drive then unplug the drive would make it last longer?

Yes, most users have been exclusively using Emby Connect successfully up until this point (a few years now). The only thing that changed was that I set up the reverse proxy. Emby Connect was still working fine for a few hours after I switched to the reverse proxy but then randomly stopped connecting from anywhere while the domain still works. It will "log in" from Connect but not actually go into the server, just allow you to choose the icon for it and then say that the server is unable to be reached.

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.