Leaderboard

Hi, it has been a long while. I understand the frustration. I will send the same message here that I have been trying to send to users of this plugin. Due to unforeseen life circumstances, I haven't be able to be part of this amazing community for many years now. Boy, do I miss writing code for Emby, what a great time it was, and I look back on it fondly as a high point in my life. Meeting great people, and writing code that people actually liked. I'll make this plugin repo public on my GitHub, for anyone who would like to take it on, or any of the emby plugins posted there. Thank you again to all for an absolutely amazing decade of writing code, and allowing me to take part. It really was a great ride! Thank you. chefbennyj.

Hello, Is it possible that in a version of emby a "ping pong" is performed in websocket to maintain a connection via a reverse proxy? Let me explain. Apart from reverse proxies such as caddy or traefik (for those I know) there is no real timeout for websockets. For reverse proxies like haproxy or nginx, the timeout is defined either by default or by the user. In the case of haproxy or nginx, if someone pauses a video that lasts more than an hour (a movie, for example), the websocket timeout will occur before the end of the movie. Or if, when playing an episode of a series lasting 40 minutes, the viewer pauses the video for 20 minutes, the connection will be closed before the end of the episode. Having the client send a message and the server reply every X seconds/minutes would eliminate the problem and prevent the connection from staying open for 1 hour for no reason, as in the nginx configuration. Also, I saw a message saying that if a connection was closed unexpectedly, for resource reasons, there was no attempt to reconnect. Why not set up a number of reconnection attempts? For example, the client tries to reconnect 3 times, and if none of the attempts work, the connection is aborted. This would, I think, allow better websockets management and avoid connections being open for hours. Or even when changing networks (LTE->wifi or wifi->LTE), this would make it easier to re-establish the connection than quitting the application and reopening it. To avoid sending just a "ping" and a "pong", useful information can be sent through websockets when the client supports them, such as the position of the video playback (which is currently sent via http), because a request via websocket is faster than an http request and sends, with the same information in the body, less data than an http request.

Emby recommends using the Android (vs ATV) app on your tv. Search in this app on your tv is a terrible experience and unusable. ATV app/any other app - you get the system search box, onscreen keyboard, voice search Emby Android app - this is a phone app. it acts like you are on a phone. I have to enter search by navigating and selecting lettters. There's no search button. But it gets worse. There's no feedback, no spinner while it searches.

Thx a lot for the hint. Tested the "Emby for Android" App on my Shield and Skip Credits (and also Intros) are working. Will consider switching to the main app (also when the devs are discussing to phase out the app). Yes, it seems it's not supported in the ATV app. Try the main app. It's working there.

Thank you Luke. Mama is fine today. Alzheimer's. You just never know when the lightning is going to strike. I appreciate your kind words! You have always been so kind and patient and it is much appreciated.

Nope, I got i5 10500T instead

Im using android Emby. at notch/status bar area, emby seems avoiding it in widescreen mode. please create a setting to allow us, to utilize it

Thank you

I owe you all an update: my problem had nothing to do with Emby or my network. You can read all about my adventure over here: https://forums.servethehome.com/index.php?threads/lsi-9400-16i-power-on-or-device-reset-occurred.55002/ but in summary, the backplane in my server chassis (Gooxi RMC4136-670-HSE chassis) had an old firmware that had issues with some health checking commands while drives were loaded (reading or writing). If I was streaming something from it and a TrueNAS health check occurred (which turns out is every 90 minutes in 25.10) then it would cause the drives to start timing out leading to ZFS halting the pool while it recovers the drives and while that is happening all further reading is blocked which from Emby's perspective looked like a network timeout. It would take about 5 minutes for all the drives to recover and then it would be fine until the next health check. Gooxi was able to provide a newer firmware and it has completely resolved the issue.

v1.7 Logic refined Color accents refined emby_album_tag_importer.py

That is fine I just checked it and it appears the problem came back. I will refer it to gracenote

As a new user Members Group applies.

I finally got it working. I didn't have any VAAPI options for preferred hardware encoders, just the quick sync, once I disabled those, I guess it fell back to the GPU (preferred hardware decodes are set to VAAPI DG2 Arc A380.

This need can be solved by attaching the font files into .ass files itself. You can do it using Subtitle Edit. If you need a batch processing, you can try assfont tool. Assfont with GUI: https://github.com/wyzdwdz/assfonts/ So ,we do not need to change the fonts on server side or client side. Note: Do not forget to use Emby App, not Android TV version. Tested on theese platform/devices: Android TV Google TV tvOS iOS Android Mobile Web Client Emby Client for Windows All these devices/os are problem-free with font attached ass subtitles. I've bought Emby Premiere for Lifetime just for this implementation. Btw, @Lukewe're willing to see this feature on Emby for Android TV version.

Hi, yes this is supported.

Not yet and I found at least one bug in the offline/download content. The remove is not correctly working, I'll fix it in next version.

Thank you. "Unique" indeed.

V1.5 Thanks for changing the purple to blue!.The new black background and white text looks very slick. Another nice refinement that looks really promising. I'll be seriously trying it out as soon as I get chance. In the meantime - here's a couple of screenshots:

Yes, there is a workaround, but you need to have the diagnostic plugin installed, and you have to reapply the workaround every time you restart. That said, if you need someone to test and/or provide logs to help you, I'm here for that...

Yep, a couple more succeeded! Thanks so much, Emby team! @Luke you have a good one in @sa2000

Hi @Luke I did this : My video_TS are under the directory : 20.000 lieus sous les mers (1954)/20.000 lieus sous les mers (1954)/VIDEO_TS/xxxx.vob For this film, my DVD format is not working with Emby and I do not know why (some of my movie don't work with Emby, reason why I want to replace them with mkv) buuut it works, I can see both DVD and mkv versions : I will be able to compare my mkv and dvd files before deleting the DVD structures on my server (except for some files... VLC will help). Thx for your help

Just wrapping up some work on the next update. I'll call it: "Your colors, your way." When i changed various things to gold, the logic was there, I just needed to point it to something else. It was a lot easier to do than I originally thought. Thanks! Thanks! Those are treated as submit/save buttons, the red one is treated as a danger/cancel button. Those colors can be controlled through these variables. /* --- DANGER / CANCEL BUTTONS --- */ --danger-red-rgb: 204, 0, 0; /* Base RGB for destructive actions */ --danger-red: rgba(var(--danger-red-rgb), 1); /* Solid red for delete/cancel buttons */ --danger-red-light: rgb(255, 51, 51); /* Brighter red for hovering over delete/cancel buttons */ --danger-red-glow: 0 0 20px rgba(var(--danger-red-rgb), 0.6), 0 0 10px rgba(255, 51, 51, 0.4); /* Glow effect on hover */ /* --- SUBMIT / SAVE BUTTONS --- */ --btn-bg: var(--my-gold); /* Resting background of primary actions (Save/Done) */ --btn-bg-hover: var(--my-gold-light); /* Background of primary actions when hovered */ --btn-text: var(--retro-navy); /* Text color inside resting primary buttons */ --btn-text-hover: var(--retro-navy); /* Text color inside hovered primary buttons */ --btn-border: var(--my-gold); /* Border of resting primary buttons */ --btn-border-hover: var(--my-gold-light); /* Border of hovered primary buttons */ --btn-shadow: 0 4px 10px var(--black-alpha-50); /* Shadow depth of resting primary buttons */ --btn-shadow-hover: 0 6px 15px var(--black-alpha-80), 0 0 15px var(--gold-alpha-40); /* Golden aura on hovered primary buttons */

As far as I know, this treatment of sub streams is unique to the Roku player.

Ok, thanks.

Thanks for following up.

If this were to be implemented I would like an option to display the original release year instead of the year field. This would require Emby to display ORIGINALYEAR which MusicBrainz can already automatically supply to mp3tag and Picard. From what I understand this information is already stored in Emby but not displayed anywhere. https://emby.media/community/topic/94691-music-tag-original-release-date-tagorigyear-andor-tagoriginalyear/

Thank you for pointing out the Anidb issue. There are some modules I don't use so I don't keep track of anything's broken. I think I've updated my fork last week after your feedback, including the Anidb update. My integration changes some basic methods, so I can't blindly apply all the fixes. I habe some Anime and will test the Anidb module over the weekend.

@CBersI can confirm that doing a backup on the old Windows server, using the Legacy Backup & Restore plugin from here, then restore it on the new server installation on Linux works. I have created the same username on Linux. Thank you very much to all of you for your help!

Thanks! I'll get back to this this weekend. Since my post, I switched BACK to the Android app on my TV. Originally, I switched from it to the older Android TV app because that played AV1 files without transcoding or sometimes freezing. It seems now Android TV as of one of the last beta updates is transcoding AV1 and now the standard Android app works perfectly.

FFS The posts are all describing the same thing: the WebSocket drops during playback, even when the user is still watching. Controls disappear after ~60 seconds because the socket hit a hard network timeout, not because the user is inactive. Your repeated claim of "lowering a little" isn't helping anyone resolve the bigger issue. Playback itself doesn’t generate WebSocket activity, so the connection dies no matter what. That’s why people are asking for keepalives or auto-reconnect. The reports they’re showing a real 60-second forced timeout that Emby currently enforces is the problem. Wanna fix it? Set keepalive to 30-45 seconds.

I can’t lie, that’s probably the most ridiculous (and funniest) thing I’ve ever read from Luke in all my years here. Anyway, back on topic. This is exactly why a proper keepalive is needed. It may not matter in many cases, but it definitely affects browsers more than other devices like TV apps. Even then, it’s still not a true keepalive. I’ve seen legitimate TV devices connect, then drop remote access after a hardcoded 60 seconds — literally 61 seconds and it’s dead. Even when SupportsRemoteControl is set to true for the client, if the websocket closes, notification messages won’t display on the device. This behavior has been demonstrated in numerous threads over the years. Something in the Emby core is chasing its own tail. There’s duplicate logic somewhere that’s causing absolute chaos.

I'm unsure how to make the OP anymore clear. But if it needs to be summarized again due to age of the request. The OP is imploring much needed improvements to WebSocket connections in Emby by implementing keepalives to maintain the connection during pauses in video playback, such as when watching movies or TV shows. This would prevent timeouts that cause the connection to close prematurely and prevent playback controls from being displayed or used in event the admin wants kill user session(s) for various reasons. Several examples have been provided in previous discussions to illustrate this need.

There actually is one already, but it's just a little high (10 minutes). We can lower it a little.