All Activity

Not only I'm a lifetime owner, I have been for a while (I remember MB3 and dealing with codex). I'm excited to read between the lines at the new Home Screen. That to me sounds exciting, hopefully it will give us much flexibility. Keep up the good work

Hey guys I see you love this service and everything. That's great to each his own. I was looking forward to using it as well I just found out the crazy stuff you have to do to get SSL certified so I tried to get a refund I had the service for about 3 hours and immediately canceled my subscription and requested a refund. They simply said you should know I guess basically by sending me a article on how to set up the server to me that is way too difficult for somebody to have to go through if they don't want to considering I just had no idea that I would have to do that thought by now that would be just included if you had to pay. My question is how good is the customer support about that kind of stuff cuz I may come back someday you never know.

Please go through the document I linked. You need to set up port forwarding on your router.

I still think that, if you choose "Primary" for the image type in a CW row, you should get the primary image of the actual item (the episode) not of its parent. Thumbs are a special case exactly because episodes don't have thumbs.

Just tried canyouseeme.org again, and it pre-populated with the IP address shown on the Emby dashboard (for remote access), but shows port 80 - this worked fine and confirmed the port was not blocked. But the port number on Emby dashboard is the default 8096 - if I enter that port number in canyouseeme, it cannot see the service and times out. My router does have something called NAT enabled but I've no idea what this is.

OK, laufe immer auf Stable. @Luke It seems not to be right, that his collection covers are now generated by Emby instead of being downloaded from the Web.

Here's a way how you can do this: At first - so you better understand this step by step - install the "Folder Sync" plugin. With that plugin, you can configure a number of folders (typically network folders, but in this case, just local folders on the server). Now configure a folder, name it "FolderSyncTest" and configure an empty dir on the server as path. Leave "access to all users" checked for now. Once you have done this, go to an item (e.g. a song), use "Download to.." and you will see the FolderSyncTest folder. Use that for download. Now the file will appear in that folder on the server. With your plugin, you can watch that folder for changes and whenever a new file arrives, you inject your metadata/images. So, how to get the file to the actual recipient? You can either replace the file in the library (temporarily) or create a special library for those file (e.g. "Transfer"). In either case, you use the Emby API to make it download the changed file to the actual recipient. Understood so far? Next question is "Who IS the actual recipient?" - your plugin cannot know this. And probably you want the download feature to work exactly as normally. You can do it like this: For every download target of every user - you create a folder-sync folder of the same name but with a suffix like " (with metadata injection)" - and this time with permissions only for the respective user. So, each user will see the double amount of entries in the "Download to.." dropdown list, each entry with and without that suffiix. Based on that name - after removing the suffix - your plugin will know the name of the download target and initiate download of the enriched file to that user's location. 3rd Level The above will work, but it depends on another plugin - yes - plugin! As the functionality you need is implemented by a plugin, you can of course do that part in your own plugin as well - and hidden as that part needs no UI in your case. The bottom line is - you don't need the folder sync plugin for implementing this - it's rather that -I- needed that plugin to understandably explain the concept

Unfortunately, I don’t have a solution for this problem. I quit using Windows edge and I moved to Windows app where there was no problem. Although couple of days ago, I opened it by accident on the Windows edge and it was working fine. So it is a little bit strange but I don’t know what happened.

Some further updated ones for a couple of the new plugins.

From my search online, the following - driver: nvidia count: all capabilities: [gpu, video] is equivalent to --gpu all. --- Here is the diagnose of the problem by Gemini Issue Summary When running the official ARM64 (aarch64) Docker container (emby/embyserver) on an ARM host with an NVIDIA GPU passed via NVIDIA Container Toolkit, hardware acceleration fails to expose NVENC or CUDA capability. Checking the bundled ffmpeg binary inside the container reveals that the aarch64 build explicitly disables CUDA and omits NVENC/CUDA capabilities during compilation. Diagnostic Logs Container Architecture: aarch64 Running ffmpeg -version inside the emby/embyserver container shows: ffmpeg version 5.1-emby_2023_06_25_p6 Copyright (c) 2000-2022 the FFmpeg developers and softworkz for Emby LLC built with gcc 13.4.0 (crosstool-NG 1.28.0) configuration: --cc='sccache aarch64-emby-linux-gnu-gcc' --prefix=/home/embybuilder/Buildbot/armv8/ffmpeg-armv8/package ... --disable-cuda-llvm ... Checking for NVENC encoders yields no results: / # /bin/ffmpeg -encoders | grep -E "libnvidia|nvenc" (empty output) Root Cause Compilation Flags for ARM64 (ffmpeg-armv8 The toolchain configuration for aarch64 uses --disable-cuda-llvm and omits --enable-cuda, --enable-nvenc, and --enable-ffnvcodec. Architecture Parity: While the x86_64 / amd64 builds of emby-ffmpeg include full NVENC/CUDA support out of the box, the aarch64 target build appears to assume mobile/SBC targets (e.g., Raspberry Pi) rather than ARM64 servers equipped with NVIDIA GPUs. Proposed Solution for the Emby Team To provide feature parity for ARM64 server environments equipped with NVIDIA hardware, please consider updating the build pipeline for ffmpeg-armv8 / aarch64: Update ffmpeg-armv8 Build Flags: Enable CUDA and NVENC headers in the ARM64 build matrix by adding: --enable-cuda \ --enable-nvenc \ --enable-ffnvcodec \ --enable-cuvid (And removing --disable-cuda-llvm where appropriate). Include NVIDIA Runtime Libraries in the ARM64 Container Image: Ensure libnvidia-encode / nv-codec-headers or dynamic CUDA loader headers are bundled in the base ARM64 container image to support NVIDIA Container Toolkit runtime injection. Please ensure that ffdetect and ffprobe are also rebuilt with the same CUDA/NVENC/FFNVCODEC flags in the aarch64 pipeline. Since Emby's NvidiaCodecProvider calls /bin/ffdetect nvencdec at startup to discover GPU features, updating ffmpeg alone without updating ffdetect will prevent Emby from listing NVENC encoders in the Dashboard UI.

While I'd also like to see this feature added, Emby seems to have many more features than Jellyfin. [redacted] Is anyone seeing that Jellyfin has caught up? They do have some different features like watch together, but they're still well short of what Emby has....I think.

When it first happened, I was wondering what it said because it was very quick and had to reread some threads in the forum to find out what it was. I think people will be curious when they first see it. IF there was a way to make it not show until after X seconds that would be nice because then only the people with slow connections would see it. Otherwise, I see its purpose.

I downloaded an audiobook from my emby server to listen to on my iphone. I have my server connected to a UPS that powers it down every night at midnight and powers it backup at 8am (no need wasting power if no one is using it) however i happened to be on my way to work earlier and tried to listen to my audiobook and cant. When i open emby on my iphone it tried to connect to the server and stays like that for a long time. Eventually like well over 3 minutes or so it goes offline and i can access the downloaded content. Is there a way to change the timer to a shorter duration?

Я оплачивал года три назад, на тот момент имел банковскую карту иностранного банка (сейчас уже закончился её срок действия). Можете выпустить сами виртуальную карту, но по затратам будет примерно так (самое дешёвое, что я знаю): 10 $ выпуск, 5 $/месяц обслуживание, 0.5 $ комиссия за каждую транзакцию. То есть ради одного платежа либо нет смысла выпускать, либо платёж предполагается крупный. Или поищите тех, кто иностранные карты имеет и сможет помочь оплатить.

Это всё блокировки наши. Да, ВПН не всякий срабатывает, да и, бывает, настроишь, а через неделю снова блок. Так что бескровно пользоваться не получается.

Gotcha! I dont use any Seer/Aaar services, but thanx for clearing that up /N

Emby нормально не работает уже с зимы примерно. Я сперва грешил на раздутую базу, на проблемы в самом Emby - менял клиенты, обновлял серверную часть до беты, откатывал назад и т.д. Все проблемы выглядят как: неработающий раздел с плагинами (бесконечная загрузка), медленная загрузка метаданных или вообще её отсутствие, даже если источник открывается в браузере (thetvdb, fanart). И как итог - при сёрфинге по фильмам в базе через клиент всё зависает, просто крутится загрузка. Перегружаешь клиент - всё работает. Если сразу ткнуть в нужный фильм - всё ок. Но стоит попрыгать по базе - всё виснет. Вот такая проблема, думаю, у всех в РФ. Лечится только установкой VPN на роутер. Как это сделать - лучше гуглить. Роутеры у всех разные с разными возможностями.

Hello...I began having the same error today. It started after a restart on Aug 19, 2026. I have attached my log as well. Do you have any idea what may have caused the problem? Thanks for your help with this. embyshardware_detection-63922714998.txterver.txt

The phrase should of been this could cause theft, NOT that it's just stealing. He's referring to Seerr. As for the YouTube trailer fetcher I do agree it's not needed when there is at least one trailer fetcher for Emby that grabs them legally.

"Obviously an issue" ? What is the issue?

With this version when it starts up there's a brief message saying... Attempting to connect to server, please wait. Noticed it on my main Google TV, then in my other Google TV which had gotten this update, and 1 phone. Then checked my other Android phone that had been off, turn it on and opened Emby and got no message, then updated Emby and now I get the message, so obviously is an issue with this new release.

I've had a couple of private repos, guess it got deleted by accident when i removed those. At any rate, i will reupload it when i get around to it. For now people can download the dll given here in the forum.

Ok well thats embarrassing. i used mp3tag to embed artwork in every track at 500x500 as recommended and The library didnt increase the size. The resultant jpgs were smaller than expect avg. 50KB Doesnt sound possible but over 1tb library the total size barely changed. Possibly the sector size of the storage is such that a small image typically doesnt affect disk usage? The feature request is possibly redundant. Here is the mp3tag i used in case its of interest. 1st line finds the image in the current folder or above and imports it. 2nd one resizes to 500x500 as jpg consistently. VLC sees the images now in car play, so im a happy bunny.

After a quick test, that fixed the Brower issue on my phone and games now load and I am no longer seeing network error