Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remote Control/Display Mirroring not working properly #496

Closed
ubergeek77 opened this issue Jan 7, 2019 · 35 comments
Closed

Remote Control/Display Mirroring not working properly #496

ubergeek77 opened this issue Jan 7, 2019 · 35 comments
Labels
backend Related to the server backend bug Something isn't working stale Stale and will be closed if no activity occurs

Comments

@ubergeek77
Copy link

I've been using a Jellyfin Docker image from before the Emby retaliation incident. In this image, Remote Control/Display Mirroring worked perfectly. This image does not seem to be on Docker Hub anymore, but it has a digest of:

jellyfin/jellyfin@sha256:fb11e9606dc46b2d5c8cca914eca6b9d5ec931364498ffcc5cf2572012859186

Today, I migrated my installation to the newly-released Jellyfin 10.0.0 Docker image. But after upgrading, this feature no longer works properly. It is still possible to connect to remote Jellyfin devices and play an episode. However, the play controls do not load; there is no episode information, no timestamps, and the media bar/seeking does not work. The only thing that seems to work is the pause button, which will pause/play the media on the remote device.

It is likely that the removal of code in response to the incident has caused this feature to break. I searched this repository for any prior issues to this problem, but I didn't find any mention of it. I wanted to make sure this was brought to the Jellyfin team's attention.

Since I use this feature extensively (it is the only way to control my Jellyfin web wrapper application on my Samsung TV), I have reverted to the Docker image I listed above.

Thank you very much for all of the hard work you do!

@anthonylavado anthonylavado added bug Something isn't working backend Related to the server backend labels Jan 7, 2019
@sparky8251
Copy link
Contributor

Just to be certain, this feature was working in 3.5.2-5 right? If so, its another one of those pesky regressions.

If you can confirm for us, we can begin trying to find out what we did that broke it.

@ubergeek77
Copy link
Author

ubergeek77 commented Jan 8, 2019

I don't have a specific tag for this image, but docker image inspect tells me the image was downloaded on December 21st, 2018. Whatever the latest image on Docker Hub was on that date, that's the one I have.

I don't have a -5 at the end of my version, but opening this Jellyfin container in a browser reports itself as Version 3.5.2.0.

If there is a way to get a more specific version from inside the container, I can shell into the Docker container and get it for you. But I am 100% certain that Remote Control/Screen Mirroring is working on this version as I am using it right now to control my custom Samsung TV Jellyfin app from my phone. And after I updated to Jellyfin 10.0.0, the feature stopped working as I described.

I believe there was at least one Docker image released after the one I'm currently using, but before 10.0.0, but I never did try that one. If there is a particular Docker image available somewhere that I can try, I'd be happy to test it out.

@sparky8251
Copy link
Contributor

sparky8251 commented Jan 8, 2019

Yeah. I'm not 100% on how to pull a more accurate number, but that sounds like 3.5.2-4.

I am not personally familiar with Remote Control/Screen mirroring. Can you give me a run down of how I could use it to replicate the problem if I only owned a Linux desktop and an Android phone?

If I can replicate it, I can find what PR broke it and hopefully fix it.

@ubergeek77
Copy link
Author

ubergeek77 commented Jan 8, 2019

Absolutely! Here's how you can test it.

Assuming you already have a Jellyfin server running on your Linux desktop:

  • Visit your Jellyfin server url in a web browser on both your Linux desktop and your Android phone. You should be at the main dashboard page on each.
  • On your Android phone, click on the "cast" button on the top right of the page.
  • On the "Play On" popup, you should see both of your devices listed. Identify the one that is your Linux desktop, and click on it.
  • After you have done this, go to your Android phone, and find an episode/movie to play.
  • The episode/movie should start playing on your Linux desktop.
  • If the feature is working properly, you should see a media bar appear on the bottom of the Jellyfin page on your Android phone. It will show a seeking bar, play controls, and an icon of the show to the left.

To further test this, you can also access a full-screen version of the play controls. From your Android phone:

  • After you are playing something that you casted from your Android phone to your Linux desktop, go to the main Dashboard page and press the cast button again.
  • A different popup should appear. Click the text that reads "Remote Control."
  • If the feature is working properly, after the page fully loads, you should see a poster for the content you are playing. You will also see a media bar and timestamp that moves along with the content as it is playing on your Linux desktop
  • If the feature is not working properly, the resulting page will appear as a blank media bar. You will see the bar, but there will be no poster, the media bar won't move (the ball will just stay far to the left), and the timestamps will show as "--"
  • You can still use these buttons to pause or stop the content on your Linux desktop, but seeking to a timestamp will obviously not work.

@sparky8251
Copy link
Contributor

Ah. So its that feature! I'm at the end of my day so I'll take a crack at it when I wake up in the morning.

Thanks for the detailed instructions!

@ubergeek77
Copy link
Author

You're welcome!

Thank you for your attention on this.

@halfagascan
Copy link

Desktop: Linux Deli 4.19.4-arch1-1-ARCH #1 SMP PREEMPT Fri Nov 23 09:06:58 UTC 2018 x86_64 GNU/Linux
Android Nexus 7 tablet
Docker version 18.06.0-ce, build 0ffa825
Jellyfin Version 10.0.0.0

I am able to cast to the desktop, from the nexus, remote controls appear to work,am able to start, stop seek, and volume control

@hawken93
Copy link
Contributor

hawken93 commented Jan 8, 2019

windows firefox
android firefox
devices do not see each other, haalp...

@sparky8251
Copy link
Contributor

So, not to downplay the originally reported bug but what is the real end goal here @ubergeek77 ? I found your reddit post and it sounds more like you want your TVs remote control to work with the web UI.

Is that correct?

@ubergeek77
Copy link
Author

ubergeek77 commented Jan 8, 2019 via email

@sparky8251
Copy link
Contributor

sparky8251 commented Jan 8, 2019

Not at all my intention or attempted tone. Both are definite bugs! Just wanted to make sure I was understanding your problems with Jellyfin properly.

It might be a quicker fix than you expect for remote controls. There are plain old hard coded keyboard commands in the JS. We can just add TV remote equivalents and BAM!

I haven't begun to test your issue myself, it's been a lazier day than expected for me. I still plan to try your instructions and check this out. It's literally the next thing I have planned. From what I've seen of others testing it today, both in this issue and in Matrix, it's an issue some folks have and others don't.

The ideal circumstance is that using your instructions I can also replicate the bug and thereby track it to a single commit. With that, we should be able to find a fix.

The greater problem is if I can not. If I can't, knowing that TV remote controls are an alternative fix for you means I might be able to provide a useful workaround while we wait for someone who can replicate this issue to go commit by commit and find where it breaks.

THAT'S why I asked what I did. Hope that clears it up!

EDIT: Re-reading what I wrote a few more times, I definitely did not ask the question the right way. I apologize for that.

@ubergeek77
Copy link
Author

ubergeek77 commented Jan 8, 2019

Thank you! I am very sorry for misunderstanding that. It was just the juxtaposition of my long-winded explanation of how to reproduce this issue, the words "real end goal" (red flag in my experience!), and one of the other contributors referencing this bug on my reddit post about TV buttons, when those two things are unrelated. I saw your edit while writing this, and it's alright. Your apology is accepted!

If it helps, this is the user agent that gets picked up by Jellyfin when it is loaded through my Tizen app web wrapper:

Mozilla/5.0 (SMART-TV; LINUX; Tizen 3.0) AppleWebKit/538.1 (KHTML, like Gecko) Version/3.0 TV Safari/538.1

If you drop in to Developer Tools in Chrome, click the 3 dots on the top right, More Tools, and then Network Conditions, you can force a page to load with that user agent. I can get served the TV page by doing this, though for debugging purposes, I can't guarantee it will behave exactly like a Tizen TV would.

As for the TV controls, anything you can show me to help out with that would be fantastic. It's simple to map a TV remote button press to a JavaScript function, and my original plan was to just simulate button presses like that. The problem was finding the right buttons to press. I tried pressing normal keyboard buttons (up,down,left,right) with the TV page open in my browser, but nothing happened. Only tab seems to work. Simulating those keys in JavaScript didn't do anything either, and that's where I left off. Maybe those keys are disabled?

Anyway, as for this specific issue, you said you've heard some reports about this happening for some people but not others. If you have any hunches about the conditions in which it happens, I'd be happy to test a few things with a Jellyfin 10.0.0 container to help narrow down the problem so we can get find easily-reproducible conditions.

EDIT:

I changed the user agent above to what my TV's actual user agent is. The one I posted originally was one I pulled out of Samsung's developer docs for debugging purposes, and I didn't realize my Chrome's dev tools had cached the other one.

@sparky8251
Copy link
Contributor

sparky8251 commented Jan 8, 2019

Anthony tends to do a lot. I seriously he doubt he ever meant to give you that impression either. Likely just made a mistaken assumption.

So, to the unrelated bug of broken TV remote controls... You can look at this file on these lines for an example of what I meant by "hard coded controls".

The script files from that folder control other UI elements, and I know there are more such hard coded controls. Sorry the JS isn't prettier yet. We have been planning to fix it for awhile now, but some org stuff has been preventing that. If you submit a PR, try to avoid prettifying it. Formatting fixes are separate PRs for us since they change too much.

I have no intention of closing this out until we fix the originally reported bug so thanks for the tip on user-agent changing! Might help if it doesn't occur when I look into this later today or tomorrow.

EDIT: Good point on that phrase. I"ll do my best never to utter it again!

@sparky8251
Copy link
Contributor

sparky8251 commented Jan 8, 2019

If you want to try tracking this issue to a specific PR, maybe try commit 0dfab94f1a35ed0630cfdd2e46180d50d10243e3 as the one right after it has been known to cause a few odd issues already.

If that doesn't fix it, I'd grab a graphical tool and look for and commits that have "Merge Pull Request" in the title on dev between the working and broken versions (we tag our releases). If you can split the merge tree in half a few times with that method, it should quickly result in a PR that causes the breakage.

It's time consuming but since I have no hunches as to whats causing this as of yet, it's the game plan I am going to use when it comes time to track this issue to its source.

@cvium
Copy link
Member

cvium commented Jan 8, 2019

It works for me with Emby for Android 3.0.27

@hawken93
Copy link
Contributor

hawken93 commented Jan 9, 2019

I'm going to keep looking at why I didn't even get the opportunity to test it and maybe fix that if it's the servers fault

@sparky8251
Copy link
Contributor

Just to confirm before I dig deep in, this is what pops up when I check via the instructions you posted. I can seek and pause/play, but the UI is awkward with the play bar overlapping a lot of stuff and always staying at the bottom (even if I scroll down).

At the very least I can't replicate it with FF on PC and Android. Haven't tried the user agent tweak, that's next. If the user agent you provided is the TVs, what is the browser you use on the desktop?

Maybe this is a Chrome <--> Firefox issue (assuming the TV is Firefox like its agent suggests)?

test

@hawken93
Copy link
Contributor

hawken93 commented Jan 9, 2019

I couldn't replicate it, my setup is (target pc:) firefox 64 on windows (remote control:) firefox 64 on android. By pressing on the button on the lower right corner, I got access to seeking, pause, and all of that.

What browser or app do you use to access jellyfin from the phone? Maybe I could test if there is some ui breakage for a particular app or browser. I unfortunately don't have a smart tv to test with, but the more specific you can get about your setup, the more likely I think I can come to reproducing this :)

I was able to do this by setting up a new vm with a fresh install and accessing it directly. I suspect that the reason I couldn't see my other devices on my regular install was that I am using a reverse proxy with it.. Will be digging deeper here.

@ubergeek77
Copy link
Author

ubergeek77 commented Jan 9, 2019 via email

@hawken93
Copy link
Contributor

hawken93 commented Jan 9, 2019

Ah, no I didn't. I'll give it a shot!

@ubergeek77
Copy link
Author

Thanks. I'll boot up another 10.0.0 container and do some more testing myself, but the issue wasn't limited to just my phone when I was having the issue. I couldn't get it to work from my laptop browser either.

If I can get it to happen again, I'll take screenshots and some more detailed info. Hopefully there isn't any weirdness in my /config directory from jumping back and forth between versions, so (again, hopefully) I can reproduce it with 100% consistency.

@sparky8251
Copy link
Contributor

sparky8251 commented Jan 9, 2019

I've been jumping between releases and PRs for days. Been on something like 30 of them by now going back to before 3.5.2-4.

If you are using docker like I am, I'm reasonably confident that you don't have anything fucky in your config folder. That said, don't be afraid to test it! Maybe it is an odd bug like that...

@hawken93
Copy link
Contributor

hawken93 commented Jan 10, 2019

I have been thinking that if there is an oddity in androidtvs web implementation, then faking user agents might not be enough to reproduce it. Maybe someone else with androidtv can test this?
I haven't had the time to fake my UA yet, will come back to that.

The TV must have been able to open a websocket at least, otherwise it would not work to attempt to remote control it at all.

any kind of debug logs would be helpful, be it browser console on TV, client and server logs. Make sure to use the newest version during testing (at the moment, 10.0.1) :)

@hawken93
Copy link
Contributor

hawken93 commented Jan 10, 2019

OK, I tested in chrome and firefox by setting the provided user agent, both errored out with no streams available. I don't know if it's my installation or some other problem, but I wasn't able to get far enough to test it :(

After looking at server side logs, I think jellyfin is generating a stream that would work if it was a tizen tv

@ubergeek77
Copy link
Author

ubergeek77 commented Jan 10, 2019

Hi everyone, I was able to reproduce the issue with complete consistency across any browser I tried. I will list each browser below and provide screenshots of the "Now Playing" page. I couldn't get the bottom bar to show up like in @sparky8251's screenshot, so I don't have any screenshots of that. Besides the two Android screenshots below, the "desktop" browser screenshots were captured from a Linux PC running Manjaro Linux KDE.

I should also note that you will see a pause button in each of the screenshots below. When the page loads, that pause button is not there. After a few seconds, the pause button appears. I would imagine that whichever function responsible for loading everything else is putting the pause button there, even though nothing else actually gets loaded. The pause button is functional - if I click it, the content playing on my TV will pause and resume. However, the pause button will not change into a play button if it is clicked, it just toggles whatever state the content on the TV is in.

Jellyfin Server Version: 10.0.0 (Docker Container)
"Viewing" device User Agent:
Mozilla/5.0 (SMART-TV; LINUX; Tizen 3.0) AppleWebKit/538.1 (KHTML, like Gecko) Version/3.0 TV Safari/538.1

(Click on each browser below to see the screenshot for it)

"Client" Browsers Tested (to remotely control content on the "Viewing" device):

Mozilla Firefox 64.0
Falkon 3.0.1
UnGoogled Chromium 71
Google Chrome 71
Chrome for Android 71.0
Firefox for Android 64.0.2

As you can see, this issue happens to me universally regardless of which browser I use. So this doesn't seem to be a cross-browser issue.

Simply returning to the old Docker container I have, which @sparky8251 has guessed is using Jellyfin version 3.5.2-4, makes this issue go away.

@hawken93
Copy link
Contributor

So... Then it must be the viewing device that triggers some funky code paths somehow. Maybe I can try to figure out where the pause button gets loaded and look at that. That's a good lead :) but I think that without actually owning that tv we couldn't really reproduce, so this makes it harder to debug this. So bear with us :)

@LogicalPhallacy
Copy link
Contributor

LogicalPhallacy commented Jan 10, 2019 via email

@JustAMan
Copy link
Contributor

Are any of you using some reverse proxy setup by any chance? And, if possible, pls specify your hostnames - I remember reading that Emby used to use different websocket URL basing on some stuff (HTTP vs HTTPS, presence of /emby in the start of URL, presence of emby in the start of hostname).

So more-or-less complete description of your setup would be great to rule out those issues (I suspect it's a separate bug as pause button should be driven by websocket thing, but better safe than sorry).

@ubergeek77
Copy link
Author

ubergeek77 commented Jan 12, 2019

The only thing I'm doing that might be related to that is using DNSMasq in my DDWRT router. I've configured it to map a "fake" hostname to the IP my Jellyfin server is running on.

But as far as I know, that only tells a browser what IP to go to like any other DNS request, so Jellyfin should behave exactly as it would if I had gone to that IP manually.

My Docker container was created with --net=host, so it has direct access to the server's network interface. I didn't have to do any port mapping in Docker.

I don't have any reverse proxies set up on my network.

I'm not using HTTPS either.

As far as my setup goes, I think it's as "direct" to Jellyfin as possible.

@JustAMan
Copy link
Contributor

@ubergeek77 can you try using IP instead of hostname to rule out my suspicion?

@sparky8251
Copy link
Contributor

sparky8251 commented Jan 12, 2019

Try as I might, I can't reproduce this with header and/or browser changes on either end.

Wondering if its your TV browser itself being a nonstandard browser?

@ubergeek77
Copy link
Author

ubergeek77 commented Jan 13, 2019

Ok.... This is just downright weird.

After shutting down my Jellyfin 3.5.2 instance, and starting a Jellyfin 10.0.0 instance, I tried @JustAMan's suggestion, and specified direct IPs on all devices involved. And sure enough, it worked.

But here's the weird part. I restarted the container, killed my TV app and restarted it, and set everything to use my shortcut hostname just as before. And the feature is still working now....

Something funky is going on. Why would switching back between a direct IP and a hostname suddenly make this start working?

I haven't been using Jellyfin 10.0.0 besides testing, so I'm going to keep using this version like normal just to see what happens. If the feature stops working again after a while, but starts working again if I specify an IP, hopefully that can put us closer to figuring out what weirdness is going on here.

@LogicalPhallacy, you said you were seeing the same issue as I was. Are you by chance using a custom hostname or some kind of reverse proxy? If you are, please try using a direct IP and see what that does. It would be great if someone else can also confirm that this bizarre fix lingers even when returning to using a hostname.

@hawken93
Copy link
Contributor

hawken93 commented Jan 13, 2019

@JustAMan and others curious about the websocket stuff, jellyfin-archive/jellyfin-docs#2 :) note that it wasn't related to http/https. That was just my initial thought, sorry for making this rumor

But in this case it would probably either work or the device wouldn't appear at all.

The remote control traffic does go over websocket so I can't rule out possible issues with weird websocket incompatability though. I think the most valuable thing to do next is to get tons of logs. Packet capture, server logs, web browser debugging.. Everything can help

@LogicalPhallacy
Copy link
Contributor

you said you were seeing the same issue as I was. Are you by chance using a custom hostname or some kind of reverse proxy? If you are, please try using a direct IP and see what that does. It would be great if someone else can also confirm that this bizarre fix lingers even when returning to using a hostname.

I am not using a custom hostname nor reverse proxy I'm afraid. I will try it with a direct IP, but it will be a bit of a struggle to repro as it was. I hit an unrelated issue and had to stop using the webui from my xbox (this is an insider build thing, not a jellyfin thing), interestingly when I point it at the xbox as a DLNA renderer (via the built in media player rather than edge open to jellyfin's page) the remote control works great.

@anthonylavado anthonylavado added this to Needs triage in Issue Triage for Main Repo Jul 4, 2019
@stale
Copy link

stale bot commented Jul 29, 2019

Issues go stale after 60d of inactivity. Mark the issue as fresh by adding a comment or commit. Stale issues close after an additional 7d of inactivity. If this issue is safe to close now please do so. If you have any questions you can reach us on Matrix or Social Media.

@stale stale bot added the stale Stale and will be closed if no activity occurs label Jul 29, 2019
@stale stale bot closed this as completed Aug 6, 2019
Issue Triage for Main Repo automation moved this from Needs triage to Closed/Done Aug 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend Related to the server backend bug Something isn't working stale Stale and will be closed if no activity occurs
Projects
Development

No branches or pull requests

8 participants