As you may have seen Plex decided it was OK today to send an email showing me what my friends have been watching. To be clear, this is Plex telling other people what I’ve been watching from my server, with my files, and this is not OK.

https://imgur.com/a/DYR4wlh

We all knew it was a matter of time before Plex started collecting data on our libraries and sharing it with advertisers. What happened to their “we don’t know, and don’t want to know, what is on your server”?. This, for me, is proof that those fears were absolutely founded in reality. On what planet would I ever want this information to be shared with friends on family on an OPT OUT basis?

It’s totally unacceptable to collect this data in the first place. It’s totally unacceptable to share this information with uniquely identifiable information. And it’s totally unacceptable to do this without explicitly asking me if it’s OK.

Unfortunately there is nothing you can do about this as a server admin, because technically these are Plex users and their marketing email preferences are controlled on the user side in the Plex website preferences. Not on your server.

This is an absolutely egregious overreach.

Thank goodness there are alternatives available in the form of Jellyfin and Emby. I left my Plex server up after the Jellyfin January challenge we did on the Self-Hosted podcast but because of this I feel that I have no choice but to take it down for good.

      • R0GG3R@alien.topB
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        Chromecast in JF never worked…
        When I click the chromecast icon in JF “Play On” (top right) I get “Google Cast Unsupported”.

        How did you manage to get it working?

        • DarthNihilus@alien.topB
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          You need to be hosting jellyfin behind a reverse proxy so that it works through https. Chromecast doesn’t support unsecured sources.

          • R0GG3R@alien.topB
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 year ago

            Yup… I have a reverse proxy. Chromecast in Emby works, Chromecast in JellyFin doesn’t. Really weird.

            • DarthNihilus@alien.topB
              link
              fedilink
              English
              arrow-up
              1
              ·
              1 year ago

              Then yeah idk that makes no sense to me. The only time I had problems with Jellyfin chromecast was when I wasn’t on https.

        • norebly@alien.topB
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          Android required, no iphonies

          Jk, i eagerly await ios support but for now android only

          • R0GG3R@alien.topB
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 year ago

            Windows browsers such Firefox, Chrome, Vivaldi, Brave have the same issue. It’s not OS or device related, it’s how Chromecast has been implemented in Jellyfin.

            https://github.com/jellyfin/jellyfin/issues/6840#issuecomment-1042905147

            I’m also the developer of a local media server, and I’ve easily managed to bypass the Chromecast client-side issues by doing a server-side discovery. Now no matter how I access my media content, I can always send it to a Chromecast, because the CC and my server are on the same network, so the CC can easily be discovered over Avahi/Bonjour/mDNS. Then it can be the server itself to provide the client with a list of discovered players, not necessarily the other way around.
            The fact that there’s no server-side logic to manage the Chromecasts, and instead we rely on the client to discover them, explains why things are so broken. Why not provide a server-side CC scan logic as a backup for users who don’t use Chrome on Android but run the server on the same network as the CC, instead of relying on such a brittle client-side implementation?