All Activity

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 ---------------------------------------------------------------------------------------------------- Hello everyone, and I hope you're having a nice Sunday. I’ve been having an issue with the theme plugins for some time now. Neither of the plugins—"Movie Theme Songs" or "Movie Theme Videos"—is returning any results anymore. I wasn't getting any "theme.mp3", "theme.mp4", or "theme.jpg" files with Emby Server version 4.9.5.0 recently, and now I'm still getting no results with version 4.10.0.40. Can anyone confirm this, and could it please be fixed? Best regards, Anskar26

Ja kann ich bestätigen, ist mir auch schon aufgefallen, sowohl bei neu hinzugefügten Serien, wie auch bei den Filmen. Habe gerade nochmal geschau, der Letzte Film bei dem das Intro geladen wurde war am 19.07.26, der nächste am 24.07.26, und da wurde schon keines mehr geladen. Alle neuen Filme oder neuen Serien danach sind komplett ohne Themes/Intros. Ich nutze übrigens aktuell die Beta 4.10.0.31, falls das eine Rolle spielen sollte.

Wait for what? Beta release has had all these features for the last 6 months.

When using the Windows desktop app I am not able to connect to a locally hosted server on the same subnet. The server is still accessible from the same machine in a web browser. I can't find a location for log files. The location of the application is apparently locked behind a Microsoft Store datastore. I really wish they would just release this as a normal windows application and not require the ridiculous MS store. How can I troubleshoot this connectivity issue?

This would be very useful although I might suggest an alternative approach using rate limit pools rather than global and live tv rate limits per user. This would allow finer-grained access controls based on the media source. Example: Pool ID: 1 Name: IPTV Fairness Limiter Included Libaries: Live TV, Movies Apply to Users: Joe Jimmy Stream Rate Limit: 2 Rate Limit Filter: [x] Device ID [ ] IP Address Pool ID: 2 Name: Shared Credential Limiter Included Libraries: All Apply to Users: Joe Stream Rate Limit: 1 Rate Limit Filter: [ ] Device ID [x] IP Address

Okay, you are running directly on the TV, right? Android in that context doesn't expose the different video modes so the settings aren't there.

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

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.