All Activity

As I said, I don't have dupes. Emby, for some unknown reason, thought I had dupes. But I never had dupes. I do have other libraries that were unaffected by this issue. So I can only assume that somehow the database for this particular library got corrupted somehow.

Well, if you do actually have dups and that setting is set to what I showed, then they will come back...

I never touched that particular setting. Was that something introduced recently in the latest update? I checked it and it was set to what it shows in your pic. So I assume that is the default setting. Anywho, in the end the only way to fix the problem was the to delete the entire library and recreate it. No more phantom duplicates.

There's no way for Emby to know whether you intentionally emptied out your library or if the share failed to mount properly and I don't think it should be up to Emby to figure out which it is. What I did to prevent this library purge you experienced was to add conditions to the [Unit] block of the Emby service file to prevent it from starting if shares aren't mounted. So if you're running Emby through a systemd service, this should help. This little guide assumes a Debian bare-metal install, so if you're running Emby on something else, your mileage may vary, but it should be similar on other Linux platforms running systemd. If you've never modified the Emby service file before, copy the default service provided by Emby to /etc/. cp /lib/systemd/system/emby-server.service /etc/systemd/system/emby-server.service Edit "/etc/systemd/system/emby-server.service" and add the following block under "[Unit]". Modify the lines to fit your setup. I run 3 shares in my setup, but if you only have one, you only need one of each "ConditionPath" conditions. RequiresMountsFor=/mnt/Animation /mnt/Movies "/mnt/TV Series" ConditionPathIsMountPoint=/mnt/Animation ConditionPathIsMountPoint=/mnt/Movies ConditionPathIsMountPoint=/mnt/TV Series ConditionPathExists=/mnt/Movies/.Movies.md5 ConditionPathExists=/mnt/Animation/86/.86.md5 ConditionPathExists=/mnt/TV Series/24/.24.md5 And remove the following line from the file. After=network.target Then run systemctl daemon-reload and that's it. "RequiresMountsFor" replaces the "After" condition and will start the service when these shares are mounted. However, if these mount points don't exist in fstab or in systemd's view as a whole, this condition passes without triggering any errors and starts the service, which is where the second condition `ConditionPathIsMountPoint` comes in just in case. And then we have a sentinel file on each share with `ConditionPathExists` to make sure the right share is mounted on the right path. That sentinel file can be any file inside the share that is always expected to be present. With this, Emby will fail to start whenever shares aren't mounted correctly and it would be up to you to investigate why before restarting the service manually. I believe that's a better outcome than what you had to deal with. Hope that helps.

This doesn't appear to be an issue. I changed the channel numbers and the excluded tag wasn't applied to the new channels

Actually, this isn't in quite yet but will be sometime this week. Please PM me details. Thx.

Persistent queue still doesn't exist even on a single device when the app is closed or user focus is switched to a different app for a short while. What's the status of this long-discussed basic functionality?

Persistent queue still doesn't exist even on a single device when the app is closed or user focus is switched to a different app for a short while. What's the status of this long-discussed basic functionality?

Just some background on why we are considering this: The configuration is complex and somewhat hidden. This alone tells us that the majority of people never discover it or use it and the new method will actually be a benefit for them because they will now go back to where they were before automatically instead of always going to "Suggestions" at the start. Again, the configuration for this (at least in all the other apps) is overly complex and muddled and we are moving towards the ability to customize exactly which tabs are available in each library which will complicate it even more. Returning to where you were before is a pretty common method of operation in most situations.

It basically is due to why most people want to do this.

Thank u good sir. /N

Hi. What do you have selected here?

Mag555 4K Player

Hi. It is possible that during the update process your IP address changed. Can you confirm the address on the dashboard is correct?

Hi. Emby does not modify your media files.

Whadap Uncle Frank! Looks sweet, us beta people will have to wait i guess. A quick question, the attached videofile is from desktop? Thanx!

Hi. What app is that? Can you show us the OSD and also a screenshot from exactly where you started playback?

Version: 4.10.0.31 If you have a tag exclusion in Parental Controls for a user and add the excluded tag to a channel the tv guide my expectation is that channel and its programs would be hidden from Live TV screens (Programs, Guide, Channels, Recordings, Schedule, Series). Encountered this issue doing a workaround for a dynamic media home section.

Minor point but Atmos is not an audio codec. It is metadata on top of one of a couple of different formats. So, there would need to be an Atmos specific filter as well.

Probably best discussed here:

Hi, there's already an open request for this or something functionally equivalent. Please join in and contribute to the existing discussion at:

Guten Tag und schönen Sonntag wünsche ich allen. Habe seit einiger Zeit ein Problem wegen den Theme Plugins. Bei beiden Plugins, "Movie Theme Songs" und Movie Theme Videos" werden keine Treffer mehr erzielt. Hatte schon mit der EmbyServer Version 4.9.5.0 die letzte Zeit keine "theme.mp3" und keine "theme.mp4" / "theme.jpg" nun auch mit Version 4.10.0.40 keine Treffer. Kann das jemand bestätigen und das eventuell bitte gefixt werden ? Mit freundlichen Grüßen Anskar26

Are you on TVH 4.2 or 4.3? running through 4.3 should look like Video.mp4

I am unable to get this work with Roku. Emby server and Roku on same network, but it won't discover the server from the Roku, tried using 192.168.0.x:8096.. nothing, tried http//:192.168.0.x:8096... nothing....all server not found ..