Leaderboard

@adrianwiThanks for some very good questions. I think the initial assessment of risk and severity was incorrect and further on, the lack of any kind of exploitation might have reinforced that classification. What probably played a role as well, is that there weren't any precedent incidents of similar impact and severity in the history of Emby. The incident has shown that security related issues need to be treated with highest priority, and some lessons were surely learned. The vulnerability was not specific to the plugin system, it was about gaining (emby-)administrative access - which would have also allowed to do other things than installing a plugin. But there are considerations about adding extra guards for changes to "high-risk" configuration settings - both in Emby Server as well as in plugins - which applies to those kinds of settings where code or script execution is controlled. A fundamental change in response to this incident is that we are dropping the conceptual distinction between "local network" and "non-local network", while the more challenging part is to provide a similar level of convenience like before but in a secure way. There are more security-related changes in the works and in planning. These will arrive in subsequent beta releases and will be explained alongside. Best regards, softworkz

Installation requires permissions to make changes to the Program Files folder - which the service account itself should not have, exactly for the purpose that it is not able to change its own executable code. The solutions for automatic updates are: A second service (e.g. EmbyUpdateService) which runs under the LocalSystem account, and its only purpose is to stop the service, install an update and restart the service afterwards A scheduled task created during installation which is set to execute in an elevated context, for the same purpose like above

If the error occurs again, I'll make a video and post it here

@GrimReaperThanks that helped, originally I had it in it's on group not the main group given how it was showing on IMDB

I have a similar issue. I’m running the latest beta (and this issue has been happening for a while with many previous beta versions). appleTVs for sure, it’s as if they forget my credentials after an extended period of time or a period of time and a power cycle. My home AppleTV has not experienced this. My cottage AppleTV has. My friend, everything she goes to her cottage, she had to log back in again. we are using direct connection to my server. Restarting the Emby app does not seem to impact anything, I’m leaning towards this being a timeout or an inactivity period that causes either the AppleTV or Emby app to forgot the credentials including the url. Maybe this is a security feature… let me know if you need anymore info.

Ive faced similar difficulty setting up my emby App , was reachable everywhere in local network besides android App or chrome. Eventough i could browse the web etc. I had previously setup a fixed-ip on the phone , and thus DNS , the problem for me was solved changing the custom DNS to 1.1.1.1. then the app found my local server immediatly. Thanks for the post and helpfull replies, It helped me very much troubleshooting !

Incredible.

Yea live streams are just a whole different animal.

That correct, mention is working and never been disable, we only remove old plugin that display "mention" under user post. @Luke @pir8radio

*Applicable to Emby Theater(s) as well* Following below discussion: https://emby.media/community/index.php?/topic/116382-fehlerhafte-anzeige-beim-scrollen-durch-serien/&do=findComment&comment=1227137 Could we get mainDrawer-mini to automatically expand/flyout on hover and retract subsequently? It would alleviate issues as encountered, and tbh there are several unnecessary (and some unintuitive) clicks required in current implementation and behaviour: - Sidebar pinned in mini-mode - Hover over sidebar mid-screen height: no reaction - (Unwanted) Move mouse top-left and click Expand - Sidebar in Expanded mode - Click Home or any Library > navigates to desired page - (Unwanted) Sidebar remains expanded - (Unintuitive/Unwanted) Point of confusion: Clicking Collapse (the only available button) doesn't collapse it but hides it altogether; clicking anywhere on screen except on Collapse actually collapses it - Sidebar back to mini-mode Flyout on hover and auto-collapse when out of focus would be much more elegant solution, reduce user input, avoid confusion and increase usability.

IMHO that's suboptimal solution, being forced to have it expanded at all times. If so, better leave it as it is, so user at least has some choice. I, for one, wouldn't be willing to give up on that screen estate. Might work, though as you, said doesn't spare on clicks but at least it's explicit. It appears there's no happy-for-all solution.

The URL should be working now.

It's planned for future updates. Thanks.

Yes it is, and that is our end goal. Stay tuned for performance improvements.