Nvidia Shield - Emby cannot mark played or save favourites

[thunderstorm456 1]

I did a factory reset on my 2019 Nvidia Shield as I'd been having various buggy issues with non Emby stuff since the Android update.

Since reinstalling Emby fresh, I signed in OK and watched an episode. I noticed it didn't mark as played. If I try and mark manually on the episode (or anything else, tried numerous examples across TV and Movies) it does nothing. It also doesn't work to save an item to favourites (previously worked).

I managed to get logs (attached, see last few lines), I notice there is a 404 being returned when pressing 'played' or 'favourite' from the Android TV app. 

But you can see if I do it from my phone (just before the TV in attached log), it works. 

Any ideas or things to try? This is super annoying! Thanks!

Edit:

Emby server version 4.7.0.30

Android TV app version 2.0.70g registered.

embyserver (2).txt

Edited March 14, 2022 by thunderstorm456
Logs

[thunderstorm456 1]

It also won't update watched progress (e.g. watch 10 mins, back out, progress not being saved). Again, only on the Shield, other devices are fine.

Edited March 14, 2022 by thunderstorm456

[ebr 14913]

Hi.  If you remove Trackt does it make a difference?

[thunderstorm456 1]

5 minutes ago, ebr said:

Hi.  If you remove Trackt does it make a difference?

Hi, good shout, I uninstalled it and restarted Emby server, but sadly no difference.

embyserver (4).txt

[Luke 37066]

Hi, are you able to mark played in the web app?

[thunderstorm456 1]

1 minute ago, Luke said:

Hi, are you able to mark played in the web app?

Hi Luke. Yes web app is working. It's seemingly only the Android TV app/Shield that it isn't working on (typical as primary device :))

[ebr 14913]

3 hours ago, thunderstorm456 said:

Yes web app is working

With the exact same user and connection mode (remote vs local)?

I don't really understand how we could get a 404 on one of those calls.... unless maybe there is a reverse-proxy or other network filter involved that may be stripping information from the calls.  Is that the case?

[thunderstorm456 1]

58 minutes ago, ebr said:

With the exact same user and connection mode (remote vs local)?

I don't really understand how we could get a 404 on one of those calls.... unless maybe there is a reverse-proxy or other network filter involved that may be stripping information from the calls.  Is that the case?

Yes, the server is remote (Hetzner dedicated server) so I am always connecting remotely, same user, logging in via Connect.

I don't understand the 404 either. But after writing this I suddenly had a thought that before factory reset I was logged in manually via server details and not using Connect. I just tried that and now it is working again... There must be something funky about my server and Connect not seeing it right. There is some proxy stuff set up with nginx. God knows why Connect login works on Android mobile though (double checked I am logged in with Connect on phone, definitely am and it definitely works).

For now it's okay as I have a workaround for TV - must be some reverse proxy thing.

 

[ebr 14913]

55 minutes ago, thunderstorm456 said:

There is some proxy stuff set up with nginx

My guess is that is the culprit and that it is filtering out some headers or post data

55 minutes ago, thunderstorm456 said:

God knows why Connect login works on Android mobile though

Probably because that app is putting more information in the actual url instead of in post data.

[thunderstorm456 1]

19 minutes ago, ebr said:

My guess is that is the culprit and that it is filtering out some headers or post data

Probably because that app is putting more information in the actual url instead of in post data.

Cool, thanks for replying. One day if I get time I'll poke about and see if there's anything I can tweak to use Connect but it really isn't a problem on there to log in manually :). Thanks again for quick replies.

[Goggleboxer 2]

I was so glad to find this post! I was having the exact same problem, and your workaround, @thunderstorm456 ,fixed it for me as well. I'm also using an nginx reverse proxy. I logged out of Connect, then manually entered my server address, user, and pass. Now shows are again marked watched after playing, and manual mark watched/un-watched is working again, plus favourites and watched progress working as normal now. It was driving me nuts! 

Emby server version 4.7.0.32 (beta)

Fire TV app version 2.0.70a registered

@ebr @Luke

[thunderstorm456 1]

1 hour ago, Goggleboxer said:

I was so glad to find this post! I was having the exact same problem, and your workaround, @thunderstorm456 ,fixed it for me as well. I'm also using an nginx reverse proxy. I logged out of Connect, then manually entered my server address, user, and pass. Now shows are again marked watched after playing, and manual mark watched/un-watched is working again, plus favourites and watched progress working as normal now. It was driving me nuts! 

Emby server version 4.7.0.32 (beta)

Fire TV app version 2.0.70a registered

@ebr @Luke

Glad it helped you and that I'm not the only one haha. It's definitely something with the Android TV app only combined with the nginx reverse proxy setup in the background. I haven't bothered to look into it further though, it was driving me nuts too and I've just been glad it works again manually connecting!

[ebr 14913]

5 hours ago, thunderstorm456 said:

It's definitely something with the Android TV app only combined with the nginx reverse proxy setup in the background

The proxy is probably stripping information out of the app's POST requests.

[Goggleboxer 2]

7 hours ago, ebr said:

The proxy is probably stripping information out of the app's POST requests.

Thanks @ebr. I think it might have something to do with SSL certificates when using Connect to sign in. Does Connect use port 8096 by default, or 8920 when the Emby server is set to force SSL connections? Nginx will force http traffic to https with my setup. A little trial and error found that when allowing the Emby client for Fire TV to play files without a trusted SSL certificate (found in "playback" settings -- If I remember correctly), files will play just fine. But, if setting is deselected, files can be marked watched/un-watched, etc., but will not actually play....throwing an error message "too many errors, stopped trying...". What I don't understand is why, if the server is setup with SSL, the TV client doesn't recognize/import the certificate? The other issue is why a Connect login will allow playback of the files (with the untrusted SSL setting turned on in client), but not be able to mark watched/un-watched, etc. 

[Luke 37066]

2 hours ago, Goggleboxer said:

Thanks @ebr. I think it might have something to do with SSL certificates when using Connect to sign in. Does Connect use port 8096 by default, or 8920 when the Emby server is set to force SSL connections? Nginx will force http traffic to https with my setup. A little trial and error found that when allowing the Emby client for Fire TV to play files without a trusted SSL certificate (found in "playback" settings -- If I remember correctly), files will play just fine. But, if setting is deselected, files can be marked watched/un-watched, etc., but will not actually play....throwing an error message "too many errors, stopped trying...". What I don't understand is why, if the server is setup with SSL, the TV client doesn't recognize/import the certificate? The other issue is why a Connect login will allow playback of the files (with the untrusted SSL setting turned on in client), but not be able to mark watched/un-watched, etc. 

@Goggleboxer the apps do support SSL, but when we rely on system networking layers to handle communications for us, then we also have to play by it's rules, and that's why workaround are required if you are not using an SSL certificate that your client devices trust.

What's probably happening is there are more likely more areas in the app that still need workarounds applied in order to force the system networking layer to accept your certificate. You might want to consider sideloading our standard android app on the same device: https://emby.media/emby-for-android.html

This has a more complete implementation of this at this stage.

 

[ebr 14913]

I don't believe it is related to SSL in the app.  I still suspect the proxy is not forwarding the post data properly.  The other app will also make a difference here I think because it doesn't use post data as much.

[Luke 37066]

@Goggleboxer have you looked at your nginx when you try to do this to see how far the requests are getting?

[Goggleboxer 2]

2 hours ago, Luke said:

@Goggleboxer have you looked at your nginx when you try to do this to see how far the requests are getting?

@Luke No, I hadn't looked at nginx error logs to see how far the requests are getting. Good idea! I've just had a look now, and I do see lots of failed SSL handshakes from various client IPs (SSL routines:tls_parse_ctos_key_share:bad key share).

Did a quick search and found this forum post at Stack Overflow: https://stackoverflow.com/questions/65854933/nginx-ssl-error141cf06cssl-routinestls-parse-ctos-key-sharebad-key-share

One reply suggests it could be a bug in client's TLS implementation, while other replies talk about scanning and security...

[Goggleboxer 2]

21 hours ago, Luke said:

@Goggleboxer the apps do support SSL, but when we rely on system networking layers to handle communications for us, then we also have to play by it's rules, and that's why workaround are required if you are not using an SSL certificate that your client devices trust.

What's probably happening is there are more likely more areas in the app that still need workarounds applied in order to force the system networking layer to accept your certificate. You might want to consider sideloading our standard android app on the same device: https://emby.media/emby-for-android.html

This has a more complete implementation of this at this stage.

 

Since the workaround to manually add server [https] IP with manual login seems to have solved these issues, I am happy to stick with that set up. Ideally, I'd rather use the Appstore app (Fire TV) so that updates are automatic, than to sideload a different build. 

[edgeness 0]

I had this error in 2024. Running server on hetzner. Solved my issue!!

[edgeness 0]

12 hours ago, edgeness said:

I had this error in 2024. Running server on hetzner. Solved my issue!!

edit: it seems i did not in fact login with connect. but i reinstalled the app, and that seems to be what fixed the issue. i switched from jellyfin to emby in hopes of having less issues,  but seems i just get different ones x)

[Luke 37066]

7 hours ago, edgeness said:

edit: it seems i did not in fact login with connect. but i reinstalled the app, and that seems to be what fixed the issue. i switched from jellyfin to emby in hopes of having less issues,  but seems i just get different ones x)

OK please let us know if you run into anything else. Thanks.