All Activity

That's my point, the Pangolin login is easily bypassed by anyone actually looking to attack; so it adds no actual useful security and serves only as an additional barrier to genuine users trying to login. I'm not sure where you get the idea it's even necessary. I've quite happily had my server exposed publicly for 10 years... There's no need to put additional login pages in front of it; and doing so, particularly with this method, adds no real value/security. In my setup there is a reverse proxy handling wrapping traffic in ssl, and only responding to a very specific subdomain while dropping other traffic (direct IP connections for example); that's plenty sufficient.

Just tossing more stuff in here as I update things... would love to get some feedback. Screen recording (3).webm

@darkassassin07The Emby login still appears, only the Pangolin login is bypassed. And only admins can control the server. I understand this isn't ideal, but what other options are there if you want to expose publicly?

@Happy2PlayI checked a couple that had the fanart added, and at the bottom the the Lock this Item to Prevent Future Changes is not set and the SAVE button is available.

@Burghard welcome to the forum, how can we help.

Is the metadata locked on your content? Pick a problem item and edit metadata and scroll to the bottom.

This version works, thank you so much. Would you mind explaining what the issue was?

The individual Emby apps are able to fully command and control Emby server. You need to whitelist all the paths required for this to make these apps function at all; which means all the paths needed to command and control your server are bypassing the additional authentication. An attacker looking to directly command your server would then be bypassing this superfluous authentication, while legitimate users just trying to reach the login page are stuck with additional steps... This does nothing to add actual security, while increasing friction for users. Security theatre at best.

Might have found the reason it failed. You can try this version to see if it's better. EmbyCredits.dll

Grüße ich möchte meinen Winows Emby Server nach Ubuntu umziehen samt TinyMediaManager. Alle meine Platten sind aber logischerweise im NTFS Format. Ubuntu kann das ja lesen aber kann Emby es unter Linux verwalten? Der usecase ist lediglich filme / Serien streamen. der Rest sollte ja plug and play mäßig gleich sein zu windows, also easy Danke euch ! lg omron12

Schade, dass ein falscher Klick das Programm unbrauchbar macht. Und dann diese Anleitung zur Reparatur zum "Serverdatenordner löschen" die nur was für Experten ist. Ich bin enttäuscht, dass bei so viel guter Programmierarbeit dieser Fehler passieren kann. Alles hat super funktioniert bis ich mich verklickt habe. Nun muss ich wohl doch wieder zu Plex wechseln. Schade. LG Burghard

@sh0rtyI have only enabled these two paths and haven't noticed any restrictions so far

I provided logs every time when asked, i don't know what you're talking about there. There hasn't been a response stating that the issue can't be replicated, just that they're unsure what's causing it. Burning in the PGSSUBS on Roku is a feature that Emby offers and the whole point of this thread has been that it isn't working properly for me. I'm aware that I can buy other hardware or stop using PGSSUB but I actually wanted to see if the issue could be resolved. I'm glad that we consider bug reports to be "complaining"... If they can't figure out the problem, fine I guess. The frustrating part has been the process of request logs, I provide them, crickets for months until I bump the post, rinse and repeat.

Try "Test to replace: MaxBitrate=39000000" "Replacement Text: MaxBitrate=250000000" Last thing i can think of.

Not sure why this happens.. As a workaround you can clone your list, wait for it to populate and then enter your new link. Then you could delete the first list. I’ll see if can fix this bug

I will look into it.

You appear to be the only person who is experiencing this, which means it is limited to your hardware/software. You were also asked for ffpmeg logs back in 2024, which you did not provide. Luke also asked you for logs constantly, which you did provide. No one else has apparently reported your issues, so this "level of support" is to be expected as the dev team absolutely can not duplicate your problem. PGSSUBS are image based and Roku does not support them. From a user standpoint, if you demand to play pgssubs and your current hardware can't play them back properly, I would just replace the hardware with something that can and stop complaining, or stop using pgssubs altogether. As a server admin myself, I ended up buying Android devices for several family members to shut them up for other playback reasons. Those that refused, got booted.

This is the level of support I'd expect for free software but buying a license specifically to use hardware transcoding and getting the runaround for a year is insane. Don't even ask for logs and say you're "looking into it" if the final answer is just going to tell me not to use PGSSUB. I give up but this has been really frustrating.

I wrote a script to change this setting as it was enabled, seems to be enabled by default or it was a few server versions back. But as i changed it and refreshed my library, this solved my problem. Thanks a lot for this info

I think the community plugin would be an excellent starting point because it enables people to review where the timestamp has been set and can enable the feature on a per show basis. I’d wish it would be implemented regardless, maybe marked as „experimental“ to make clear that there could be unforeseen errors

@Lukeit happend again. Yesterday around 22:28 (a few times). I have attached the logs. My system is an unraid with the emby docker container and hw transcoding setup like this: https://forums.unraid.net/topic/101969-guide-setup-emby-with-hw-transcoding-on-unraid-remote-access-through-reverse-proxy-using-swag/ and checked by settings an low resolution on an client -> server dashboard is showing HW transcoding (green icon). I have an idea and test the following now: On my second client i have not noticed the issue (same nvidia shield pro incl. same firmware and emby app). But the android tv app setting: settings -> playback -> audio output -> is set to "Auto". On my client with the issue (see logs) it was set to something "Downmix to DTS...". The files i am playing have mostly aac audio. If i played the same file on both maschines, on one (without the issue) it says "Direct play" for video and audio. On the maschine with the issue it said direct play just for video and transcoding for audio. After changing the setting to "Auto" it also says "direct play" for video and audio. Can you please check the logs for an issue regarding transcoding? Any other hint why it begins to stutter (i have noticed mostly at the end of an ~40 min video - last few minutes). thx logs_emby_server.zip

As mentioned above, exact same problem on my G5 as well.

IMO I'm not really sure we should. An error in auto-skipping the intro is easily corrected with a back skip or two but the same cannot be said for auto skipping to the next item. If this were marked incorrectly it could be hard to even realize it and even harder to recover from.

This part is something for Emby to implement, the plugin will show you Credit skip after you have run through your library. But Emby has not implemented the auto skip part, so you need to click skip for now.

Yes, it's my own list. I probably entered the link BEFORE the list have populated. I deleted the cache (autotag_cache.json), restarted emby but still nothing for this one: "No tems found"