All Activity

It use to be that the trailer name shown is whatever comes after a dash "-". For your Emby version it is probably the dash, that is causing the name to be shortened. That may have been fixed with the latest beta. But then, I just stopped using a dash in the trailer name, when I noticed this issue. Try removing the dash.

At the moment, Ear Wax is an Alexa skill rather than a standalone Android/iOS app. It connects Alexa to your own self-hosted Emby music library, so Ear Wax does not host or store your music. I don't have a dedicated public webpage for it yet. And yes, if avoiding Alexa/Amazon services is a requirement, the current version probably isn't a fit for you. I am working on a mobile version that would bring the Ear Wax experience directly to the phone without requiring Alexa. Android is the first target, but that work is still in development, so I don't want to claim compatibility with Google-free Android devices until I've actually tested and defined those requirements. The self-hosting part is very much intentional, though, the goal is to use your own music library rather than replace it with another cloud music service.

I haven't heard of this program. Do you have a dedicated webpage to learn about it? I assume it is a mobile app (Android/iOS). Does it require proprietary frameworks? I run a Google free phone. *edit - ah, you use Alexa. I wouldn't use for that reason alone. I try to self host as much as possible.

I'm seeing this: However, once I download the middle image, it seems perfect. JPG images, 3000x4000, taken with a Samsung phone. Tried to cut this cameraupload item from the json forcing my phone to reupload. But after reupload, still it's the same. Can I somehow "force" Emby to rerender this single image?

Actually, I cannot wait - I'll take the plunge and download the 4.10 beta release later and give it a whirl

Ha — that explains it perfectly, and it's a fair assumption: same name, same courtyard. Opposite ends of the setup, though — that one drives your *arr stack, this one just plays things on the TV.

I assumed by the name it was the same. https://github.com/retransmit/Atrium

Perfect, cleared this folder and Emby is now running again - let the rebuild commence!

Understood, thank you for clarifying. I'll just have to be patient for this to be put into release - hopefully will be very soon.

I had this same issue. I just started naming files like this. Example: 2 Fast 2 Furious (2003)-Trailer.mp4

You can use natural language to playback music or control a remote session but if you would like to know all the commands then they can be found here https://translate.emby.media/browse/embyapps/alexacommands/it/

Thanks Luke! Ideally, having an option to simply drop the "- Present" suffix for ongoing shows (so they just display the start year like "2026", while ended shows still keep "2007 - 2019") would be the absolute best experience! Really looking forward to it.

Hi All, I have changed couple of weeks ago from Emby for AndroidTV to EMby for Android in my Sony Bravia in order to test the interface and the functionality of it. I was a little bit disapointed so i decided to switch back and install 2.1.55 rel but then nothing was working. I was unable to play any movie from my internal LAN to Sony Bravia. I rollback to 2.1.48g without success and then back to 2.1.23g to finally be able to play the content. embyserver-63924257771.txt embyserver-63924336000.txt embyserver-63924173908.txt

Oh, I hadn't seen the post...but still no news on its integration with Alexa ???? Thanks Hispa

Only if Emby has a limit. I have about 130GB of available storage on my phone.

hi, more options to control this are planned for future updates. thanks.

You could refresh the metadata on the movie that it belongs to.

HI, this is comparing apples to oranges. We wouldn't force the movie display into something just because tv shows is doing it, or vice versa. TV shows are ongoing. Movies are not. But an option to control is fine.

Hi, if several of them downloaded, perhaps you ran out of space?

I understand that argument, and I don't expect Emby to develop and maintain every feature that somebody asks for. But we're going in circles now. I've already explained the benefit: with Direct File Access, the player accesses the original media file directly and controls its own file I/O, seeking and buffering. Emby remains responsible for the library and playback management, but is no longer in the media transport path. That's not a theoretical concept — it's exactly how Kodi works with my media, both standalone and through EmbyCon, and it works extremely well. Is that a benefit for the average Emby user? Probably not. Most users won't care whether their original file reaches the player via HTTP or SMB as long as they press Play and it works. But that's very different from saying there is no clear benefit at all. For users who deliberately want the player to access their local media storage directly, Direct File Access is the benefit. At this point I think the real disagreement is simply this: I consider that capability valuable in a local media client; you don't consider it valuable enough for the number of users who would use it. That's a perfectly legitimate development decision. But it is a priority decision, not proof that Direct File Access provides no benefit. @Luke, that's actually why I originally used the word “rejected”. You said you wouldn't describe it that way, but Eric has now explained that maintaining Direct File Access isn't considered worthwhile because too few users need it and the benefit isn't considered sufficient. We can call that “not prioritized” rather than “rejected”, but from a user's perspective the practical result is the same: the feature existed, stopped working after Android/Shield changes, and @ebr, you have alone decided making nothing changes. It doesn’t matter what the other users think about it. We've probably spent more time discussing why Direct File Access isn't worth maintaining than it originally took to implement it.

If you're using it for IPTV, please don't as it's typically illegal content, and it's also a great way to get your IPTV account banned for using multi-room. I am personally extremely angry that the Emby devs caved to the people who use it for that. If you're going to use IPTV, buy a proper box like a Formuler and use it on those boxes in that location, or install Smarters or another IPTV client on your devices and use that to access it, NOT Emby. I personally use IPTV, but I absolutely refuse to integrate it into Emby as Emby is for streaming your personal media, not a TV provider. There is also the fact that you can not control the lag from your IPTV provider and you could have issues with buffering and you would be thinking it's your server when in fact your IPTV provider is over subscribed with too many people, or too many connections from people abusing it when they don't have mult-room accounts. If you're only doing 10-12 devices, then really any modern Intel machine that is not a celeron class can easily handle your wants. The biggest problem could be your network. Ideally you would want as many devices hardwired as possible, specially if you could potentially stream 4k content to 4 or more TV's simulateneously. There have been users who complained about buffering with wifi due to crappy signal, too much interference, bad wifi cards on TV's, etc. I personally use an i5-1235u laptop as my Emby server, and have had zero issues with over 16 concurrent connections. My network is 2.5 gigabit. But I'm not the end all be all. Maybe someone who supports using IPTV on Emby will also chime in and give you what you want, or will just stop by and tell me I'm an idiot or worse for not supporting IPTV on Emby. Hope this helps.

Hi, yes this has been reported elsewhere and we are looking into it. Thanks.

@ebr Could it be possible to make this available in the Android Tv app. Currently can set playback to 1000 Mbps Would be good to have it the same as the others: Up to 4k - 200Mpbs Up to 1080p - 60 Mbps This should then allow people to set to max 1080 and then it will play the 1080 version if both exist Thanks

Hi Luke and Emby Team, Currently, Emby displays the airing period for ongoing TV shows by forcibly concatenating the premiere year and the status as [Year] - Present (or 2022 - 现在 in localized languages). Pain points: Visual Clutter: For users who prefer a clean and minimal header layout, having "- Present" appended to the year looks bulky and cluttered. Misleading for Hiatus/Anthology Shows: For many shows that take multi-year breaks between seasons (e.g., British dramas, anthology series), showing "- Present" gives the false impression that it's actively airing new episodes right now. Inconsistency: Movies only display a clean single release year (e.g., 2022), while TV series are forced to show the date range / status. Suggestions / Proposed Solutions: Display Toggle Option: Add a display setting in User / Display Preferences, such as "Show premiere year only for TV series" (allowing users to display just 2022 instead of 2022 - Present). Or Decouple Year and Status: Separate the Status into an independent badge/tag (e.g., displaying 2022, followed by a separate badge like [Continuing] / [Ended], similar to the TV-MA content rating badge), rather than hard-binding them together. This would give users much more flexibility to customize their Emby details page and make the metadata display much cleaner. Thank you for your consideration!