All Activity

This may the same problem I started seeing. When you first start playing a movie the video is choppy/jerky. If you FF or rewind one time it straightens out. I'm running ATV 2.1.46g on my two Shields.

Hi Luke Is there any way of disabling Direct Play server-side as a global setting to disable it for all clients? Everything else in Emby works fine but watching Live TV has never worked reliably on any devices - just hoping there's some way to make it work properly. Thanks.

Not sure why you're not seeing it, a "Split Versions Apart" button in every multi-version item's detail view, Media Info section at the bottom.

Hi, I found a workaround to change when the “Next Episode / Up Next” prompt appears in Emby Web. Tested on Emby 4.9.5.0. File: /opt/emby-server/system/dashboard-ui/videoosd/videoosd.js Original logic uses: 30 / 35 / 40 seconds before the end, depending on episode duration. I changed it to trigger at 96% of playback instead, so the prompt appears when about 4% of the episode remains. Patch idea: 1. Backup the file. 2. Replace the fallback timing logic: runtimeTicks-1e3*(fiftyMinuteTicks<=runtimeTicks?40:fortyMinuteTicks<=runtimeTicks?35:30)*1e4 with: runtimeTicks*.96 3. Optional but important: Emby may use CreditsStart markers when available, so I also forced creditsInfo to 0 in the UpNext calculation to always use the percentage-based trigger. 4. Restart Emby. 5. Clear/reload the browser cache for: /web/videoosd/videoosd.js?v=4.9.5.0 In Chromium/Chrome DevTools console: fetch('/web/videoosd/videoosd.js?v=4.9.5.0', {cache:'reload'}) Important notes: - This is not an official setting. - It will probably be overwritten by Emby updates. - Backup before modifying. - A proper UI setting would still be much better. Result: The UpNext prompt now appears around 96% of the episode instead of the hardcoded 30/35/40 seconds.

Hi, on the latest stable version it seems there is no more menu point to split versions. How to split versions of movies now? E.G if i have a 1080p and a 4K movie and i work with tags, i need to set the 4K movie tags before i match them, otherwhise emby is not able to write the tags only to the 4k movie, and it marks the 1080 and the 4k version with tags like "4K" or "dolbyvision" and only after i set the tags, i can merge them again. So how can i do this right now as there seems to be no more option to split versions. Thanks

Sorry Long answer : but solved issue And it's in French HowTo - Emby Web : bouton Épisode suivant à 96 % de lecture Version : 04/07/2026 1. Principe Objectif : afficher le bouton 'Épisode suivant' dans Emby Web quand 96 % de l'épisode est lu. Ce réglage remplace le comportement natif, qui utilise environ 30/35/40 secondes avant la fin, ou un marqueur CreditsStart quand il existe. 0.96 signifie : déclencher quand il reste 4 % de la durée totale. Chemin concerné : /opt/emby-server/system/dashboard-ui/videoosd/videoosd.js Plateforme testée : Debian 12, Emby Web 4.9.5.0. 2. Sauvegarder le fichier Créer le dossier de sauvegarde puis copier le fichier JavaScript original. sudo mkdir -p /root/backup_emby_ui sudo cp -a /opt/emby-server/system/dashboard-ui/videoosd/videoosd.js /root/backup_emby_ui/videoosd.js.BAK_$(date +%Y%m%d_%H%M%S) 3. Appliquer le patch 96 % Le patch ignore le marqueur CreditsStart, puis remplace le seuil par runtimeTicks*.96. La commande ci-dessous reste utilisable si le fichier contient encore les valeurs natives 40/35/30 ou un ancien test en 120/120/120. sudo python3 - <<'PY' from pathlib import Path import re p = Path('/opt/emby-server/system/dashboard-ui/videoosd/videoosd.js') s = p.read_text() s = s.replace( 'creditsInfo=(null==creditsInfo?void 0:creditsInfo.start)||0', 'creditsInfo=0' ) pattern = r'runtimeTicks-1e3\*\(fiftyMinuteTicks<=runtimeTicks\?\d+:fortyMinuteTicks<=runtimeTicks\?\d+:\d+\)\*1e4' s2 = re.sub(pattern, 'runtimeTicks*.96', s, count=1) if s2 == s and 'runtimeTicks*.96' not in s: raise SystemExit('Seuil UpNext non trouvé : vérifier manuellement videoosd.js') p.write_text(s2) print('OK patch UpNext 96 pct') PY 4. Redémarrer Emby Le redémarrage force Emby à resservir le fichier modifié. sudo systemctl restart emby-server 5. Vérifier côté serveur Cette commande contourne le cache navigateur avec un paramètre aléatoire. Le résultat attendu est creditsInfo=0 puis runtimeTicks*.96. curl -s 'http://debian12:8096/web/videoosd/videoosd.js?check='$(date +%s) | grep -oE 'creditsInfo=0|runtimeTicks\*\.96|runtimeTicks-1e3\*\(fiftyMinuteTicks<=runtimeTicks\?[0-9]+:fortyMinuteTicks<=runtimeTicks\?[0-9]+:[0-9]+\)\*1e4' Résultat attendu creditsInfo=0 runtimeTicks*.96 6. Forcer le cache du navigateur Piège observé : Chromium peut garder l'ancien videoosd.js pour l'URL versionnée videoosd.js?v=4.9.5.0. Dans la console du navigateur, sur l'onglet Emby, forcer le rechargement de cette URL exacte. Adapter v= si Emby utilise une autre version. fetch('/web/videoosd/videoosd.js?v=4.9.5.0', {cache:'reload'}) .then(r => r.text()) .then(t => console.log( 'PCT96=', t.includes('runtimeTicks*.96'), 'CREDITS0=', t.includes('creditsInfo=0'), 'HAS_NATIVE=', /fiftyMinuteTicks<=runtimeTicks\?\d+:fortyMinuteTicks<=runtimeTicks\?\d+:\d+/.test(t) )); Résultat attendu dans la console PCT96= true CREDITS0= true HAS_NATIVE= false 7. Recharger Emby Web Fermer et rouvrir l'onglet Emby, ou utiliser Ctrl+F5. Lancer ensuite un épisode et vérifier l'apparition du bouton vers 96 % de lecture. 8. Effet de 0.96 selon la durée Durée épisode Bouton vers 40 min 1 min 36 restantes 50 min 2 min restantes 60 min 2 min 24 restantes 9. Retour arrière Restaurer le backup choisi, redémarrer Emby, puis forcer le cache navigateur comme plus haut. sudo cp -a /root/backup_emby_ui/videoosd.js.BAK_YYYYMMDD_HHMMSS /opt/emby-server/system/dashboard-ui/videoosd/videoosd.js sudo systemctl restart emby-server 10. Notes importantes Ne pas supprimer /var/lib/emby/metadata ni /var/lib/emby/cache pour ce sujet : le problème n'était pas la base Emby, mais le JavaScript servi et le cache navigateur. Une mise à jour Emby peut remplacer videoosd.js. Dans ce cas, refaire la sauvegarde puis réappliquer le patch. creditsInfo.start correspond au début du générique détecté par Emby via CreditsStart. Le patch creditsInfo=0 force l'utilisation du seuil proportionnel, donc un comportement constant.

Hola, yo también tengo un servidor que usa un almacenamiento que tiene las imagenes y metadatos y para que lo lea en la configuración de la biblioteca le activé esto: En tu caso revisa si la tienes. Si no la tienes activa y refresca metadatos de toda la biblioteca

As advised above, that is a question for plugin Dev. One thing you could check do is untick/tick again all enabled Collection Image Fetchers for your Collections library under your Settings>Library tab, then check how does it behave for newly created collections. For existing ones, multi-select>Refresh Metadata on those missing artwork, you don't need to do it one by one.

Hola, tu estás en el programa insider en esos equipos? También puedes intentar hacer esto para descartar permisos: desde el explorador ve a la ruta de Emby C:\Program Files\WindowsApps\EmbyMedia.EmbyTheater... y busca la aplicación Emby.Client.WinUI y ejecútala desde allí pero como administrador

Here too. It’s problem of latest update. On other clients works well. Only on iOS with latest update broke trailer from internet. Local trailers still working.

I removed and will run re-scans. As you noted, core emby includes collections. That does not answer why the collections built did not include the posters. Again, as noted, the posters are there for them if I manually add or refresh the collection but I should not have to do that. Will see what I get with a refresh. Thanks

Hi there! Thanx for the tip, will give it a try So like "Collectionposter.jpg" for example? N.

Hi, I'd like to try the plugin. Do you know how I can get it? I can't seem to find it in the plugin catalog.

Correct, hence plugin Dev was tagged. You are mixing things a bit: auto-collections are part of Emby core, per-library setting (without any additional plugins), and it behaves as it always had: gets collection (movie set) data from TMDB (if enabled in library edit). You have installed 3rd-party plugin that has additional/expanded feature set. If you want previous behavior/collections only as they used to be, uninstall plugin and you'll get only that.

Thanks. I’ve been testing it, and it works well. I have one question: if a user doesn't have access to a specific library, will the movie or TV show from that library still appear when this message is shown? If so, is there a way to exclude certain libraries for specific users?

Don't worry about this, it will be fixed. Do you see any other issues in this area?

That's definitely a bug. The toggle should always be rightmost.

Hi @softworkz Button reordering on genericitemlists Heres a video showing what i think is an issue. The rows below a removed genericlistitem change their button order (same for added). Hopefully i am not embarrassing myself with a coding mistake (code attached).. but i dont think i have control over button order so hopefully i am in the clear. 2026-07-04 15-41-17.mp4 ai thinks theres an issue in createListButton in the client side ManageComingSoon.zip \UI\AddMovie

In another post I mentioned I attempted to write an XML script for Emby Live-TV in an attempt to give me finer control over the EGS feeds I am using, populate program ICONs and control new programs are recorded but reruns not recorded. I am not sure if what I discovered are true bugs, or if Emby just handles them differently. I hope it is just me not having the proper understanding of how Emby Live-TV handle EPG XML and I can be educated on where I went wrong. Live TV / XMLTV: programme-level <icon>, <category>, <new>, and <previously-shown> are ingested but appear to have no effect Summary When using a third-party XMLTV guide source (merged from an XMLTV backend, not Emby's own Guide Data service), Emby's Live TV importer appears to read <title>, <desc>, and <start>/<stop> from <programme> elements, but does not appear to act on several other standard/documented elements: <icon src="..."> on <programme> never populates artwork for the corresponding Live TV "Shows" item, even though channel-level <icon> (on <channel>) works correctly and displays channel logos as expected. <category>movie</category> — using the exact, case-sensitive value configured in Dashboard → Live TV → Setup → XmlTV → Movie categories — does not appear to trigger the movie classification/internet-lookup behavior implied by that settings page, and does not affect artwork population either. <new/> and <previously-shown start="..."> do not appear to affect DVR "record new episodes only" behavior. Reruns are still scheduled for recording even when the programme is correctly tagged <previously-shown start="..."> referencing an earlier, correct original air date, and the true first airing is correctly tagged <new/>. Tested both self-closing (<new/>) and explicit open/close (<new></new>) syntax for all of the above elements, in case a non-standard internal parser was missing self-closing tags specifically. No difference in behavior was observed between the two forms. Environment Emby Server version: 4.10.0.17 (beta) Platform: Docker on QNAP NAS Running QuTS Hero. Guide Data Source: XmlTV (Dashboard → Live TV → Setup → Guide Data Sources), pointed at a self-hosted, merged XMLTV URL (not "Emby Guide Data") TV Source: M3U, pointed at a self-hosted M3U URL Both served by a self-hosted playlist/EPG manager (Stationarr) that merges multiple upstream XMLTV sources with one custom enrichment source layered on top What's confirmed working correctly To rule out the source data as the problem, the following were independently verified before filing this report: The XML is well-formed and successfully parses in Python's xml.etree.ElementTree (a strict parser) with no errors. Emby is downloading and parsing the file successfully — confirmed via Emby's own server log during a manual "Refresh Guide Data" run: the file downloads (200 OK), and programme counts are correctly saved per channel, with no errors or warnings logged. Channel-level <icon> works perfectly — channel logos display correctly throughout the Guide, Channels, and On Now views, confirming Emby's XMLTV parser does read <icon> in at least one context. The <category> value exactly matches Emby's own configuration — copied verbatim from the "Movie categories" field on the XmlTV source's settings page (see screenshot reference in "Additional context" below). The programme-level <icon> URL is independently reachable — confirmed via curl -I directly from the Emby server's host machine, returning HTTP/1.1 200 OK with a valid image/jpeg content type. Confirmed via direct API inspection (browser DevTools → Network → the Items?... request backing the Live TV "Shows" row) that the returned JSON shows "ImageTags":{} (empty) for programme items that have a valid, correctly-formatted <icon> in the source XML — ruling out a UI-only rendering bug and confirming the image reference is not being stored server-side at all. Steps to reproduce Configure a TV Source of type M3U pointed at any valid M3U playlist. Configure a Guide Data Source of type XmlTV pointed at a URL serving XMLTV where at least one <programme> element includes: <programme start="20260701210000 +0000" stop="20260702000000 +0000" channel="EXAMPLE.us"> <title>Example Movie Title</title> <desc>A description of the movie.</desc> <new></new> <icon src="https://image.tmdb.org/t/p/w500/examplePosterPath.jpg"></icon> <category>movie</category></programme> On the XmlTV source's settings page, set Movie categories to movie (or confirm the <category> value above matches whatever is already configured there). Run Refresh Guide Data (Dashboard → Live TV → Setup, or via Scheduled Tasks). Navigate to Live TV → Programs → Shows, and locate the item corresponding to the programme above. Expected: Poster artwork appears for the item, matching the <icon> URL provided. Actual: The item displays the default blank clapperboard placeholder icon. Inspect the underlying API response (DevTools → Network → the Items?... request that returns this item's JSON) and check the ImageTags field for this item. Expected: "ImageTags":{"Primary":"<some hash>"} Actual: "ImageTags":{} Create a DVR recording rule for the series/movie above with "Record new episodes only" (or equivalent) enabled, across a guide window containing both the <new/>-tagged airing and a later <previously-shown start="...">-tagged rerun of the same content. Expected: Only the <new/>-tagged airing is scheduled to record. Actual: Both the new airing and the <previously-shown> rerun are scheduled to record. Sample real-world data The following is representative real output from the pipeline used to test this (channel names/IDs anonymized where not relevant), showing a movie with three airings — the first correctly tagged <new>, and the two reruns correctly tagged <previously-shown> referencing the original air date: <programme start="20260701083500 +0000" stop="20260701120000 +0000" channel="ExampleChannel.us"> <title>Example Movie</title> <desc>Example description.</desc> <new></new><icon src="https://image.tmdb.org/t/p/w500/exampleHash.jpg"></icon><category>movie</category> </programme> <programme start="20260703170000 +0000" stop="20260703202500 +0000" channel="ExampleChannel2.us"> <title>Example Movie</title> <desc>Example description.</desc> <previously-shown start="20260701083500 +0000"></previously-shown><icon src="https://image.tmdb.org/t/p/w500/exampleHash.jpg"></icon><category>movie</category> </programme> Additional context This was tested extensively across multiple variations before concluding it's not a data-quality issue: plain <icon> alone, <icon> + correctly-cased <category>, self-closing vs. explicit open/close tag syntax, and stable vs. unstable programme-identity tracking for the new/rerun logic. None of these variations changed the observed behavior. If this is intentional/by-design (e.g., programme artwork and new/rerun detection are only supported when using Emby's own "Emby Guide Data" service, not third-party XMLTV), it would be very helpful to have this documented explicitly on the XmlTV setup page or in the XmlTV documentation, since the "Movie categories" field in particular strongly implies category-based classification has some functional effect for XmlTV sources specifically. Happy to provide a full sample XMLTV file, HAR export of the relevant API calls, or server logs on request.

I can't disable the subtitles because the option isn't available. When I go to the TV series library, select the series, and then choose the episode, it gives me an error. But if I remove the subtitle file directly on the PC, it works. That's why I think the problem is with the .ass files. I've also tried other series with episodes that have .ass subtitles, and the same thing happens. My server is a PC with a wired internet connection for both the TV and the PC. My internet provider is DIGI, which uses CGNAT. But I've been using Emby for several years with the same provider and haven't had any problems until version 2.3.8.

Try removing the dashes from the names of the image files. Emby uses the dash in defining file names. I am guessing this could be upseting the ID of the images.

Of interest: https://play.google.com/store/search?q=auto off timer&c=apps&hl=en

Fur Web, ist es mogliche mit custom.css. Ich habe eine theme wo der 'Play' knopf ist kleiner, grun und unten links.

Oh okay my bad.... I will stick with the emby expiry plugin then... I thought it is okay to integrate emby with qbittorrent client since there are some legal apps like arr's ( radarr, sonarr ) use emby and integrate it with their apps.

Hi all, I've built a plugin called TV Show Status that adds a status badge to TV series pages, showing whether a show is: Airing (with the next air date, if known) or Returning Series if no date is confirmed yet Last Aired (with the date, for ongoing shows without a confirmed next episode) Ended (with the last aired date) Cancelled (with the last aired date) In Production This data comes from TMDB and updates automatically once a day, so a show that gets renewed after being cancelled will flip back to the correct status without any manual action. How it works: A background task fetches the status for every series in your library from the TMDB API and caches it locally. On the web client, a small badge appears next to the rating/year/network row on each series' detail page (matching the native look of that row). Optionally, the status can also be prepended to the show's real Overview/description. This genuinely updates the library metadata on the server, but it doesn't currently display in the app versions I've tested — I'm hoping this could be picked up by the native apps in the future. Setup: Just enter a free TMDB API key in the plugin's settings page (Settings → Plugins → TV Show Status) and it does the rest.