All Activity

Nice idea really, but a more natural approach would be to integrate it directly into this section where you can already filter by title, year, date added, critic rating, runtime, etc. That’s the only solution that really makes sense. Current workarounds - like creating playlists or adding the country as a tag - are acceptable, but they’re still just workarounds. They don't follow the workflow. The country information is already available when tagging a film, so requiring users to add it again creates unnecessary extra work.

v3 Reworked dropdown menu Replaced button icon Refined drawing logic albums_groupby.js

Understood - thanks.

Isn't that what ProviderIdsExtender does? Or am I misunderstanding? Looks like it might only support known links with IDs configured in metadata.

Just, A bonus of using the dash - 1080P and - 720P, the first part of the media title is removed and you just see - 1080P and - 720P in the pull down options, which is less cluttered and easier to read. The abridged listing is based on what comes after the dash, so you have a choice to handle the naming of the pull down options, exactly how you prefer. - Director's extended version 1080P or - 1080P (director's extended)

So, is LG not recognizing the media as a playable video? Can Emby be tweaked to recognize these files? Are the files perhaps created from a recording and not showing all the startup metadata at the beginning of the file. If the video is remuxed to get the video data setup correctly, will those remuxed video media then begin to play? I think it's reasonable to guess that LG does some test before accepting a media file, as playable. If you remux and try the new file and that fixes it, that would point towards this possibility. I am just guessing. Media quite often has strange metadata setup and this causes failure to playback on some apps and software all the time.

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!