All Activity

Thanks for all of your efforts, intentionality, ideas, and hard work that have gone into this project. What you’ve created is helping many people connect and enjoy media together in a way like no other. Looking forward to all that you come up with! I really, REALLY appreciate the unRAID template and versions you have made. It’s my preferred manner of hosting Watch Party and sure beats running an entire VM for it. Thank you again!

Why is this plugin even in the catalog if it doesn’t work and nobody updates it? Someone above even mentioned they paid for it, which means the maker is still making money off it... hmmm

Hey everyone, Quick update on where to find support for Emby Watch Party going forward. The project has grown a lot over the past few months (thank you all for that!), and keeping track of bug reports, feature requests, and discussions across multiple places has gotten tricky. To keep things manageable, I'm shifting primary support over to GitHub: https://github.com/Oratorian/emby-watchparty/issues GitHub makes it much easier for me to track issues, link fixes to specific reports, and make sure nothing slips through the cracks. This thread isn't going away — I'll still check in and answer questions here, just not as frequently as before. For the fastest response, especially for bugs or feature requests, GitHub is the way to go. Thanks for all the support and feedback — it's been incredible seeing so many people use this thing. Cheers

What are the good reasons for whitelisting based on device? Is that not added complexity?

Why would we want that kind of complexity in the system? I cannot think of a truly good reason to block something based on the platform.

And what do you have the limit set to? Did rebooting the server make a difference?

Keep in mind I'm not concerned about spoofing or whatever. My friends are not hacking me. My nephew might, but good for him if he can figure it out. The server can see what each device reports itself to be. Can't we just use that info and call it a day?

Hi, there's already an open request for this or something functionally equivalent. Please join in and contribute to the existing discussion at:

I agree this would a welcome addition. Basically what apps like IMPlayer and others do. There needs to be some way to quickly filter channels on the guide, especially when there can be hundreds now w/ iptv. And it's even more important on the TV clients (Apple TV, etc) vs mobile (which have filtering options on the guide) since navigation is more limited. I keep checking every Testflight in hopes it pops up.

Hey, welcome to the Emby Community! Yeah, I want this too. Emby said it may be easy to do - but that was nearly 2 years ago now: https://emby.media/community/topic/128632-add-overview-text-section-to-the-music-genre-pages/ RateYourMusic has some very good Genre desciptions: https://rateyourmusic.com/genres/ This old Bliss blog is the best article I have ever read on how to organise Genres to suit your own collection: https://www.blisshq.com/music-library-management-blog/2015/03/17/mp3-genres-one-size-does-not-fit-all/ But neither is much use for Emby, unless there is an Overview text field to add the info. Also, on your other issue with paragraphs - Emby does work with some limited HTML in the Overview field, so you can manually create paragraphs with a space between them by using <br/> <br/>. You could also try out <b>bold</b> and <i>italic<i/> for highlighting e.g. Artists or Albums/Songs. Note: this HTML may or may not work well depending upon which client app you are using. Anyway, there's also plenty more music tips on the forum elsewhere. Cheers!

Front end solutions: With MacOS and iOS, you can have web based or app based. Web based can be limited via CSS @supports styles but app based has to do with each iOS app separately. Code is completely separate from these two choices. Once you target iOS users, you put some style that prohibits them from logging in via web. You can either hide the login page or add a mask over the top of a div that covers all the buttons. You can also create a text warning or an image... "Sorry you are banned". iOS stand alone apps would require a separate solution. iOS styles example that worked in 2022: https://stackoverflow.com/questions/30102792/css-media-query-to-target-only-ios-devices @supports (-webkit-touch-callout: none) { /* CSS specific to iOS devices */ } @supports not (-webkit-touch-callout: none) { /* CSS for other than iOS devices */ } Backend server side options: would be also different code. I am not sure what limits can easily be added that would work, all the time. Front end solution seems like a more dependable approach.

Oui mais se son des vieux Amazon car si j'ai un utilisateur connecté sur son Amazon et que je le deconnecte et essayer avec un autre utilisateur sa bloque

Je crois que les nouvelles Amazon fire bloquent beaucoup de choses sur les vidéos comme les IPTV.... Possible que ça bloque aussi EMBY

A l'extérieur sa fonctionne sur mon cellulaire sans probleme . Semble juste à avoir problème avec les Amazon fire mais qui se branche nouvellement car les anciens sa fonctionne

Et en we à l'extérieur ça fonctionne ?

You'll just have to side load them for now: https://github.com/MediaBrowser/Emby.Releases/tree/master/android

I think I know what we need. (This is probably already requested but I haven't searched.) We already have the ability to whitelist devices on the user level. I've always thought this is kind of useless and a little bit mean, because why should I ever want to restrict my friend to his living room TV? Doesn't make sense, so I've never done that. And if Joe wants to trade his roku for a better roku, there's really no good reason for me to be throwing road blocks at him. Whitelisting devices is much too granular, imo. But let's say for whatever reason I absolutely hate Apple, and I decide I don't want their crap connecting to me. This is where it would be nice to be able to whitelist apps instead of devices. Something like... Enable access for: [x] Roku [x] Android [x] AndroidTV [ ] MacOS [ ] iOS [x] Samsung [x] LG [x] Web Is that feasible? I don't know but it makes more sense to me than whitelisting devices. Does anyone here ever whitelist by device? I'd really like to know how often that feature is used and why. Edit: LG would be a far more concrete example. I am legitimately wary of LG TVs.

Ca fait longtemps qu'elle est sortie la 4.9.3 je crois, tu as fait une mise à jour ? Si non, ceuxx avec fire tv ont fait une mise à jour ? Si non, demande leur de redémarrer leur amazon fire (si c'est comme les merdes de google qui se mettent en veille et qui ont plus de mémoire au bout de X temps parce qu'elle se clean pas...) Dernière étape, regarde les logs sur le serveur, tu sauras. D'abord les logs emby, ensuite les logs de ton serveur

Salut, tu fais ça en quel langage ? Si j'ai bien compris tu utilises l'API d'emby ?

Again: why does it matter?

According to the devs over at Channels DVR, Gracenote was having an issue that they resolved this morning.

Exactly this kind of information would be nice to have right when you click and choose one specific genre.

Thanks for the suggestion, but that's all a bit more involved than just blocking any URI without "/emby" in it. That, and I do use the web interface for my own admin duties while logged in locally. I actually like the web interface for everything but playback. Everything is fine the way it is - I'm just saying a built-in magic switch to disable browser access on a user level wouldn't be a useless thing.

Right this topic is about the user interface inside the app, not about the system media controls that are shown by the device.

I have told them, but I still get random browsers showing up in my devices list, that is why I thought it would be good to have an option to disable it, since I never use it. Would you have an example of the CSS code to put in order to display a message: "Browser access is disabled"