All Activity

You're seeing working custom/external links in the Android app?

Thank you kindly Visproduction, for the resources. I wouldn't stream video over bluetooth (not sure if you can) but I use it for audio. My preference is LDAC, the proprietary Hi-Res wireless audio codec from Sony. Everyone's needs are different, I suppose.

If that's the case, why is it okay on phone?

Of interest - Bluetooth codec compatibility. It would seem possible that some bluetooth audio codecs won't work with every hardware / software. I prefer to always use cables and avoid wireless for all audio and video. Other than a couple of links, I have no knowledge, whatsoever, regarding Bluetooth and no plans to ever use it. https://www.pcmag.com/how-to/what-are-bluetooth-codecs-a-guide-to-everything-from-aac-to-sbc https://audiophiles.co/bluetooth-codecs/

Yeah, the plugin was more proof of concept. Next version will have a proper name and thumbnail.

Glad to hear it! The 40 Mbps was a ceiling, not a floor. The script just bumps that ceiling up so Emby stops rejecting the hardware encoder for high-bitrate content. It doesn't touch the lower end at all. If you're transcoding 4K HEVC at 20-25 Mbps, the hardware encoder was already being selected before the patch (it was under the old cap), and that doesn't change. Whatever bitrate Emby picks is based on your client's quality setting, not the level cap. If you're seeing a specific minimum being enforced somewhere, post the relevant lines from your transcoding log and I can take a look.

New Emby Beta server v4.10.0.7. Release Notes

Ah ok I'll just learn to accept the category in name better than nothing. And the plugin is called meet movie? Haha I've been looking for one called embyui or emby plugin ui. Most dll have same name as plugin. Should mention the name is different lol.

I’m confident this isn’t related to that setting—I don’t have it enabled, and the behavior consistently occurs when pausing or rewinding in the Emby app. At this point, I’ve largely given up on troubleshooting this issue (and several others I’ve reported) due to the lack of response and progress from the Emby team. Many of these problems have been open for years without resolution, and in some cases, they make certain media completely unwatchable—for example, failing to transcode without errors. As a result, I’ve started moving more of my usage over to Plex to avoid these ongoing issues. I know this isn’t directly related to the original topic, but I felt it was worth expressing my overall frustration with the current state of things.

Any update on this? It has almost been another month and the subtitles are still off screen on the top left corner

I would also remove all cuatom plugins to rule out any issues with code not being accepted by latest beta l, hope this helps

For me, in this instance I would backup, reinstall and restore to rule out any update corruption issues.

first rule is always restart for trouble shooting

Get this..... I just had to restart the pc gotta love tech issues.

Ok but will I be able to install it? Cause Im running my emby server on TrueNas freebsd? Thanks

My ip's have not changed either, I don't think this is the issue. I appreciate the help either way. Anything else you could think of being the issue? I've also since deleted the port rules and reconfigured them, still no success, even tried an alternate ip.

@LukeTagging you here since creation of this header is something you could add to your custom builds of ffmpeg to add some resilience to stream startup. Bonus points if you would consider sending a bit more of a buffer to a client when they try to join a live stream. I've been annoyed by buffering at the start of LiveTV feeds. I use the force transcoding option in my playback settings for MPEGTS so that I can pause/skip backwards while watching live tv. When Emby uses ffmpeg to compose the segments and HLS manifest it doesn't contain an #EXT-X-START:TIME-OFFSET=0 header to tell the player to begin playback from the first segment in the file. Default behavior on the player side when this header is missing is to jump to the last segment in the list (verified in logs), which skips over all data in the tuner buffer and results in periodic pauses until the player falls back in time enough segments to be arriving ahead of the current playback position. For example, ffmpeg generates roughly 8 segments of startup content in my current setup, but without this header being present, the player will start playing from segment 8 instead of segment 1. Once the header is added, I can verify in the logs that the player always requests the first segment available in the m3u8 manifest. I'm using the emby-server docker container and I've hacked a workaround in place for this by overriding the emby startup script to call an ffmpeg wrapper. The wrapper redirects manifest output to a .m3u8.raw file, uses a loop to check it for updates and when a new version is found it creates the intended original target m3u8 file with the necessary header. CAVEAT: This works well for the first person that tunes into a live channel. However, due to internal logic within Emby, additional sessions that join an in-progress live stream aren't given enough buffer data for this to have a meaningful impact. These add-on streams only receive enough data from the internal tuner cache to create 1-2 segments at startup which causes the emby client/player to pause a bit at startup while it waits for additional segments to be created and published. Docker compose bind mounts: - ./ffmpeg-wrapper-override.sh:/bin/ffmpeg-wrapper-override.sh:ro - ./emby-server-run-override.sh:/etc/services.d/emby-server/run:ro ffmpeg-wrapper-override.sh: #!/bin/sh # Version 2.8.0 - HLS Segment Pinner (Universal) REAL_FFMPEG="/bin/ffmpeg" # Smart Patcher: Only updates when the manifest actually changes maintain_proxy_smart() { OFFICIAL_M3U=$1 SHADOW_M3U=$2 FFMPEG_PID=$3 LAST_MTIME=0 until [ -f "$SHADOW_M3U" ]; do kill -0 "$FFMPEG_PID" 2>/dev/null || exit sleep 0.1 done while kill -0 "$FFMPEG_PID" 2>/dev/null; do if [ -f "$SHADOW_M3U" ]; then CURRENT_MTIME=$(stat -c %Y "$SHADOW_M3U" 2>/dev/null) if [ "$CURRENT_MTIME" != "$LAST_MTIME" ]; then # Inject the 'Start at 0' tag and commit atomically sed '2i#EXT-X-START:TIME-OFFSET=0' "$SHADOW_M3U" > "${OFFICIAL_M3U}.tmp" mv "${OFFICIAL_M3U}.tmp" "$OFFICIAL_M3U" LAST_MTIME=$CURRENT_MTIME fi fi sleep 0.1 done } # TRIGGER: If Emby is generating an HLS manifest, we intercept. TRIGGER=0 for arg in "$@"; do if [ "$arg" = "-segment_list" ]; then TRIGGER=1 break fi done if [ "$TRIGGER" -eq 1 ]; then WRAPPER_PID=$$ # Rebuild arguments to redirect the official manifest to a shadow file for arg do shift if [ "$PREV_ARG" = "-segment_list" ]; then REAL_PATH="$arg" SHADOW_PATH="${arg}.raw" set -- "$@" "$SHADOW_PATH" else set -- "$@" "$arg" fi PREV_ARG="$arg" done if [ -n "$REAL_PATH" ]; then maintain_proxy_smart "$REAL_PATH" "$SHADOW_PATH" "$WRAPPER_PID" & fi exec "$REAL_FFMPEG" "$@" else # Fallback for library scans, probes, and non-HLS tasks exec "$REAL_FFMPEG" "$@" fi emby-server-run-override.sh: #!/usr/bin/with-contenv sh # Maintain original config ownership logic if [ "$(ls -nd /config | tr -s '[:space:]' | cut -d' ' -f3)" -ne "$UID" ] || [ "$(ls -nd /config | tr -s '[:space:]' | cut -d' ' -f4)" -ne "$GID" ]; then chown "$UID":"$GID" -R /config fi # Maintain GPU device discovery (Critical for Hardware Acceleration) for d in $(find /dev/dri -type c 2>/dev/null); do gid=$(stat -c %g "${d}") [ -z "${GIDLIST}" ] && GIDLIST=${gid} || GIDLIST="${GIDLIST},${gid}" done # Launch EmbyServer # We change ONLY the -ffmpeg flag to point to your new wrapper path if [ -n "$(uname -a | grep -q synology)" ] || [ "$IGNORE_VAAPI_ENABLED_FLAG" = "true" ]; then s6-applyuidgid -U /system/EmbyServer \ -programdata /config \ -ffdetect /bin/ffdetect \ -ffmpeg /bin/ffmpeg-wrapper-override.sh \ -ffprobe /bin/ffprobe \ -ignore_vaapi_enabled_flag \ -restartexitcode 3 else s6-applyuidgid -U /system/EmbyServer \ -programdata /config \ -ffdetect /bin/ffdetect \ -ffmpeg /bin/ffmpeg-wrapper-override.sh \ -ffprobe /bin/ffprobe \ -restartexitcode 3 fi UPDATES: Make sure you disable the bind mounts when doing updates so you can inspect the /etc/services.d/emby-server/run file for changes that you need to bring into your override.

OK, I guess I answered my own question, and this may be of note for other people encountering this behaviour: I play Emby wirelessly to a Bluetooth stereo amplifier. This issue only happens on Bluetooth and with this particular stereo. After much experimentation, I determined that the BT chip in the stereo is an older one, and probably not compatible with my newer T90 tablet. So if Emby has issues playing out to Bluetooth, it just skips over all the songs in a folder and stops. Emby just rocks. I'm very impressed. I bought the Emby Premiere and uninstalled all my JRiver software. No looking back!

I'll look into it, thanks for reporting!

@ozturkHow do you find out the path after /storage?

Maybe i missed something, but i couldnt find anything in the metadata editor.

Hey, check the server IP. Most home routers have dynamic IPs, meaning the address changes every time you restart the router. There's usually a "preferred IP" option that makes sure the server always has the same address.

i have all metadata lookup for recordings off. I still believe it would be great if emby got the backdrop from the guide instead of using the poster as the backdrop.

Your symptoms look more like network bandwith then a problem with the server. My 60TB library does not have this issue, and i have an old low power 2011 xeon.

does anyone have any other ideas what this could be? thanks