All Activity

This release is taking a bit longer, but there are over 70 different year/model groups currently supported by this app, extending back to 2015 models. Samsung need to review, test and launch for each group. They don't exhaustively test every model group, but it still takes times. For newer, and current models, they do more exhaustive testing as new year models bring more challeges.

Sorry I thought you meant the Dashboard where it shows the version number and Home/remote addresses, which are still correct and haven't changed. The problem was in the public port numbers in Network, I had two digits swapped that didn't match the Caddy ports I had set up.

ok, i'll try it later

No more problem but how to delete all incorrect data in Trakt ? @Luke

@SamESI have a 2022 Samsung Artframe (75”) 4k TV and I’m not about to give Samsung more money for a newer screen because they cant be bothered supporting it. It seems patently stupid for (1) Samsung to be so slow (2) not support anything older than a pint of milk and (3) timebomb apps so we need to keep sideloading this stuff. surely I’m not the only person with this view? simple question - when will anything later than 2.2.8 be available in the Samsung store and can @Lukeor anyone apply some pressure here? (Please)

Hi everyone, DSM 7.4 is availlable for most SYNOLOGY device. Did someone tested this DSM with emby ? is there a risk if I upgrade ? thanks for reading.

See above re port forward. Rule says incoming WAN traffic on port 9096 should go to Nimbustor4 on port 9096. My NAS is called Nimbustor4. The old one is Nimbustor2. When I try to access my WAN address Emby says "Nimbustor2" at the top of thecscreen when asking for username and password although Emby is turned off on that NAS and the port forward is to Nimbustor 4

Yes, it's time to complain about the quality setting again. Users on my server consists mostly of elderly family members who have no idea how to work things. I've tried to explain to them how to quality setting work but now a couple of them (feels like a way to spite me) have set it at the very lowest quality and are complaining about it looking very bad. There is absolutely no way i can explain to them (they are 80+) and visiting them is out of the question as i don't own any transportation. So a way to remotely set their quality would be absolutely awesome and.. NEEDED!

This would work, but unfortunately I don't have sufficient storage for that.

Don't use your torrent folder for your library folder?

I would not recommend 2.4 GHz wireless. In my experience, that's what causes many of these issues. If the signal strength is not adequate at 5GHz then the signal strength needs to be improved. But 5GHz channel can make a difference, so worth testing this.

Follow up issue on this topic I'm noticing after running for a bit. Some of the media I have is monitored by a torrent client. If it includes the .nfo files then the client is getting upset about the nfo file being to big ((emby adding data)). Is there a way to get emby to use a custom nfo file name?

Bueno la tv funciona con licencia y creo que despues de un tiempo igual te pide embypremiere por los dispositivos

Hi, I don't know if I'm having the same issue or not, but it seems related. I just migrated from Truenas Core 13, to Truenas Scale 25... And things are working, but video has been stuttering a few times per episode watched. It's getting more and more annoying. The video is direct play without transcoding. Same hardware as before. File plays super fine over Samba share. But in Emby, stutters and repeats shorts sections.

La parte que me está rompiendo ls cabeza es que al final si puedes utilizar emby sin licencia para que reproduzca la persona al otro lado si el paga la aplicación. entonces que ventajas tiene ????

Si puedes usar ambos servidores con 1 sola licencia

We can absolutely bring back the classic 1980s color bars. That said, keep in mind I also have a software fallback (libx264), so I'd prefer to keep it lightweight and just render the text, with the optional TranscodeProfile of your choice. At launch, the goal is to support nearly every GPU and platform, so I'll definitely need your help testing across all of them.

e.g.

Before I do a broader release, I plan to roll this out to a small, selected group. But there's no community I'd rather introduce it to first than this one. The project originally started as an Emby-specific watchdog, but I quickly realized I didn't need to depend on any media server API—or even HDHomeRun emulation—if I controlled the upstream stream itself. That insight completely changed the architecture and made the project platform-agnostic. (That said, it doesn't support Plex, since Plex relies on HDHomeRun integration, which I intentionally moved away from.)

Okay, so it'll be like old-school TV. It just always broadcasting something even if its just "color bars". Thx. It might be fun to have a set of configurable slates like the old color bars or old-time "We're experiencing a problem, your program will resume shortly..." kind of things.

If you have the ability to side-load, you can test the new beta that just went up.

The core design is simple: the proxy guarantees Emby a continuous, valid MPEG-TS stream regardless of upstream state. When the upstream stalls, the proxy does not propagate EOF or collapse the socket. Instead, it monitors configurable heartbeat and stall thresholds (check_interval, stall_detect_ticks, drop_forgive_secs, etc.). Once starvation is confirmed, it immediately replaces the missing input with a hardware-encoded SERVICE OUTAGE slate, keeping the transport stream valid and uninterrupted. The session remains alive until the scheduled program actually ends (including padding). If the upstream recovers at any point—whether after 5, 20, or 45 minutes—the proxy flushes the slate, resynchronizes, and seamlessly rejoins the live broadcast. From Emby's perspective, playback is a single continuous .ts stream with an outage slate inserted during signal loss. A graceful socket shutdown only occurs when the scheduled program ends, although configurable timeouts (such as drop_forgive_secs) allow deployments that prefer early session termination.

Ah. Missunderstood. Great!

is it still horrible in 2026? i cant find a way to hide a channel from all users when the plugin functionality is disabled without the method above?