All Activity

Hi, I would try using the identify feature on these and see if that helps.

I would have to assume that the IP addresses for all of the tuners changed when I installed the new router. I disconnected everything from my network and powered them back up one at a time after the initial setup on the router. I just checked the tuner IP addresses in Channels DVR and it shows the following: HDHR Prime: 192.168.0.51 HDHR Quatro: 192.168.0.17 HDHR5-4K: 192.168.0.10 HDHR Prime: 192.168.0.23 I'm guessing that Emby isn't tracking the changes in the IP addresses even though the web UI lists all for tuner devices.

1. It's not showing as a top entry in the library when sorted by Date Added 2. It does not turn up in search results 3. It is not listed in the Metadata Manager 4. It is not alphabetically where it should be in the library when sorted by Title

Thanks for following up !

OK we’ll take a look at this. Thanks.

The non Android TV version will you what folder paths will be deleted. This helps serve as a safeguard because you then cancel the delete if it doesn’t look right.

Hi, there isn’t really a built in way. You could use webhooks but you’d have to setup a server to receive the web hook and then write some code to read the data and then act on it.

So it worked after turning off the vpn?

Hi, what makes you think it’s not added to the library?

Hi. Is the IP address for the tuner correct? The log says 192.168.0.22. Could it have changed?

I have the latest binhex-Emby docker installed on an unRAID server. The Emby app is installed on multiple nVidia Shields. I have four HDHomerun tuners - two HDHR Prime with cablecards on Verizon FIOS, one HDHR Connect Quatro, and one HDHR Connect 4K for OTA TV. I replaced my aging Linksys EA8500 wireless router with a TP-Link AXE5400 wireless router earlier today. All devices use hardwired connections via CAT6 ethernet on a home network. In addition to Emby, I have the Channels app installed on the Shields with the Channels DVR recording engine on a separate Windows 10 HTPC. I also have two Windows 7 HTPCs with Windows Media Center installed using EPG123 and guide data from Schedules Direct.. Both of the Windows 7 HTPCs with WMC as well as the Channels apps on the Shields have no problems tuning to live TV. When I try tuning to a TV channel in the Emby guide on any of the Shields I get a message indicating that it is unable to tune to the channel at this time. I have reset each of the tuners as well as the Shields and the unRAID server but still cannot access live TV via Emby. The HDHR tuners show up when I access the Emby server via the Web UI so I'm stumped as to why I can no longer tune to live TV. It worked perfectly fine before I replaced the router and I tried to maintain the same settings as the old router for a smooth transition. I have the router configured for DHCP to automatically assign an IP address to each device on the network with the exception of the unRAID server which has a static IP address. I set the range of DHCP address to range from 10 to 189 with the unRAID server static address set above that range. Log files attached. The exact error message displayed is "Unable to tune to channel at this time." This occurs with both local OTA channels and FIOS channels. This was around 4:45-4:55 P.M. EST on 2/21/2026. User name is Dave. embyserver.txt hardware_detection-63907289148.txt

I just discovered that any file with a particular filename will not be added to the library (of a movie type library). The filename originally was "Ex Machina (2015) 1080p x265", and after experiments I found that "Ex Machina" and even "Ex" were not being added. Perhaps there is some string sanitation in the code that rejects "Ex"? After scans, the file is also not present in the Metadata Manager. I have around 5000 movies in this library and this is the only file that has this problem. This file used to be in the library, but I'm not sure how long ago the problem started. I can say with certainty that 4.9.3.0 and 4.9.1.90 are affected. I think I was last aware of the file being present in the library around 2 years ago, unfortunately between then and now I don't have any further data. I'm happy to supply logs of a library scan or anything else if someone can please let me know how to get such a log.

This doesn't equalize out any of the relevant differences, unfortunately. Desktop environments, Window managers, Display server: x11, Wayland - none of this goes away. It's rather that flatpak and snap have their own specifics, so for each it's like developing for an additional platform - not to speak of supporting. We have those AppImage packages, but as said, it requires implementing an update mechanism. Package building for Snap is done by 70% btw, but there always comes a point where you need to draw a line and think about what you (we) will be able to support reasonably - especially for the initial release of an all-new application. The effort for development has been substantial already, and when the outcome would be that I'd have to respond to user issues on a daily basis - because I'm the only one who can answer certain questions, then that would be a self-built trap. I think we have achieved a decent amount of platform coverage - which is more difficult than on any other OS (in case of desktop GUI apps) - something like 80%, and a good level in terms of quality - which is important - and much better than trying to go for 100% while ending up with a software having quirks and bugs everywhere and then running behind, trying to get everything fixed, yet failing to do so. On Linux, those 80% are served by a few players only (both, distros and DEs), for the remaining 20%, the variety is increasing exponentially, with hundreds of distros where you can only fail when trying to support everything. Right to the point. There are other tasks that are really pressing and which people are waiting for. The overarching achievement with this app is that it marks a milestone on a roadmap for the unification of client apps upon a common platform. After Window and Xbox, the Linux app is the third app on this new platform, which allows us to move faster in development, delivering innovations and also ensures continuity across platforms where apps for smaller platforms will directly benefit from work on other apps and features. In other words: it won't happen again that the Emby Linux app will become orphaned and outdated like it happened to the legacy ER app for Linux. That's the outlook and the bright side, even when we cannot satisfy everybody's desire immediately.

What server version are you on now?

no news about the update ? Downgrade the version to a working version while waiting for a functional update? It's very difficult to look show with this subtitle if you look VOSTR.

probably not enough recources or maybe even nobody to support it today.

I mean, of course. Windows, XBOX or apple are way bigger audience. Android and Android TV are HUGE as well. but we are in Linux thread. I am comparing only linux vs linux here and HUGE thank you for supporting linux Desktop at all!

Maybe the transcoding setting should be a device setting vs user setting. Then you could have it transcode on a mobile device, but not a home theater/TV device, etc.

So using MKVToolnix I removed ALL the subtitles that came with the MKV, then ONLY added my foreign subtitles. So that's the only subtitle track in there.

Oh so that's the name I gave the subtitles when I added it into the MKV with MKVToolnix. They are only for the foreign language, they are not showing up when they are speaking the Yautja language as they should (Subtitles show up when played in the web Emby player though).

Oh so that's the name I gave the subtitles when I added it into the MKV with MKVToolnix. They are only for the foreign language, they are not showing up when they are speaking the Yautja language as they should (Subtitles show up when played in the web Emby player though).

Wasn't sure if it was definitely established CableCard was dead, so thought maybe try again with different software. FYI NextPVR would be different software to try. The separate NextPVR plugin would let NextPVR talk to Emby.

I don't get the issue here. If Emby doesn't want to deal with the differences in different distros then why is emby against flatpak?

Sorry but again not reading my rant. Card blew up and don't think Comcast will replace it. Willing to try though if they do. Is this the next PVR plugin? I noticed it's from 2024 so wasn't sure.

Would it help to try with other software - I think NextPVR works with CableCards (whatever they are...)