All Activity

Last Minute tweaks TV Show Status Release Notes Changes 2.5.102.0 Add an option to show "Season Premiere" and "Season Finale" on posters as well as thumbnails Add an option to put the season number on the badge, as "Season 21 Premiere" 2.5.101.0 Add "Season Premiere" and "Season Finale" to the Upcoming list on every client, including Android TV, Fire TV and tvOS Fix Upcoming badges showing the show's next air date instead of each episode's own date Fix two badges appearing on posters when the overlay and web badges were both on Fix badges only appearing after visiting a show first, and disappearing again on the way back Fix badges never clearing from a card once drawn Add an optional calendar or coloured status dot in front of the status in show descriptions, which shows on every client. Off unless you choose one Add a colour setting for the Season Premiere badge Add a setting to show "Returning" instead of a date on the badge Add separate settings for library cards and the Upcoming list, so either can be badged on its own Add a setting to switch the web badges off inside the Emby app while keeping them in a browser Add a setting to turn off status badges on posters Change the "What to badge on thumbnails" description to say plainly that Season Premiere and Season Finale show on every client, not just a web browser Change the Upcoming badge to read the day heading Emby prints above each card, so it always matches Limitations Season Premiere and Season Finale on the Upcoming list appear on every card of that show while the episode is coming, not only the card it refers to. One picture serves every card and cannot tell them apart. Only the web browser gets it per-episode Turning on "Show the season number on premiere and finale badges" makes every badge slightly smaller, not only the premiere ones. Badges are sized so the longest possible label fits, and that label gets longer Season Finale can flag a week early or late. It compares the next episode against the number of episodes the season is announced to have, and that figure gets revised while a season is still airing. Season Premiere has no such risk There is no "Only Complete" option for the Upcoming list. Complete means nothing further is scheduled, and a show only appears in Upcoming because something is scheduled Air dates on Upcoming cards are web browser only. Season Premiere and Season Finale reach every client Turning "Prepend status to show description" on can produce two badges on a poster. Leave it off for now With Emby's "Hide spoiler information from unwatched episodes" on, unwatched episodes show the series artwork, so you see the show's badge rather than an episode one Episodes with no artwork of their own borrow the series picture, and the series badge comes with it Your library's thumbnail view and the Upcoming list request the same image, so a badge in one appears in the other. Poster view is the only layout that separates them The calendar and status dot in descriptions are emojis, so each device draws them in its own style and their colours cannot be changed Changing a setting may not update artwork you have already viewed. Refresh metadata on the show, or wait for Emby to re-read it "Draw badges on library cards" is web browser only, and is ignored while the poster overlay is on Ended defaults to amber on new installs only. Existing installs keep whatever they had EmbyTVShowStatus.dll TVShowStatus-Settings-Reference.pdf

Wrong. Or are you suggesting my hardware is too weak? Then take a look at my signature. What the hell is the problem with offering true direct play over SMB?

And for the 220 this is where there’s no segmentcomplete in the ffmpeg log?

For example a client based on the mpv player doesn’t need to wait for any server features. You can just enable the options in libmpv

No the entire original file is transmitted. There’s no separation of audio and video.

Look at the source code for an smh file access client. The network requests to get a file are not that different from http requests.

From the perspective of a video player, this line of reasoning is entirely correct from a functional point of view; however, it does not alter the technical definition of a bit-for-bit file copy. Relevance for the player: A video player requires neither file system permissions nor inode information nor creation dates to decode a video stream. For playback alone, this part of the metadata is in fact irrelevant. Representation in HTTP headers: Certain basic metadata, such as the file size (Content-Length) or the modification date (Last-Modified), are, of course, transmitted in HTTP headers. However, they are represented there as protocol parameters and are not part of the original file bytes on the storage medium. The difference compared to a file copy: A true bit-for-bit copy (such as that produced when copying via SMB or rsync, for example) creates a physically or logically identical duplicate of the file at the bit level, including all container structures and file sectors. An HTTP stream, on the other hand, delivers data dynamically and often in fragments (via range requests). If the original statement claims that this is a ‘bit-to-bit perfect copy’, this is technically inaccurate. It involves a bit-for-bit transfer of the payload (audio and video tracks) on demand, whilst the file as a whole remains on the server and is not transferred as a bit-for-bit copy. The term ‘DirectPlay’ is just a misnomer here. And practice proves it too. Large MKV files with HD audio, no smooth playback

Actually it works the same way. Players abstract this sort of thing the same way the server does.

@softworkz Thank you. I agree that Emby should not apply ReplayGain automatically and that clients normally should decide how to use it. My client has an additional constraint: it uses Alexa AudioPlayer, which accepts a stream URL but provides no DSP or ReplayGain controls. The client cannot modify audio samples, and the Echo cannot be assumed to honor preserved ReplayGain tags. Emby also has its own Alexa integration, so this limitation may apply beyond Ear Wax. Alexa AudioPlayer clients are not full media players with local DSP. They generally provide Alexa with a stream URL and cannot apply ReplayGain themselves. Therefore, exposing and preserving ReplayGain metadata solves discovery but not playback leveling for Alexa integrations. An explicit, opt-in server-side gain parameter would allow both Emby’s Alexa integration and third-party Alexa clients to request normalized output without changing Emby’s default behavior for ordinary clients. Would an explicit opt-in transcoding parameter be feasible—for example: ApplyReplayGain=Track or: AudioGain=-2.85 When requested, Emby would force transcoding and apply that constant gain. Without the parameter, current direct-play and transcoding behavior would remain unchanged. To prevent double application, the playback/media-source response could indicate: ReplayGainApplied=true AppliedGainDb=-2.85 Exposing the original ReplayGain fields or complete stream side-data JSON would allow my client to make one provider-neutral gain decision. The explicit stream parameter would allow Emby to perform that decision only when requested by a client that cannot process audio itself. Does the current transcoding API or plugin API have an extension point for this kind of explicit client-requested audio filter?

Actually some of that data goes in http headers. The rest doesn’t matter to a video player.

Hi, yes, although there are features in the UI to delete subtitle files.

Wrong! Because the HTTP protocol and a conventional file transfer process (such as copying via a network share) work in fundamentally different ways: Missing file system metadata: HTTP transmits only the raw data stream (the payload of the media file). Operating system file attributes – such as timestamps (creation and modification dates), access permissions, inode information or extended attributes – are simply not included in an HTTP response header and are lost in transit. HTTP Range Requests (partial requests): When copying a file (e.g. via SMB), the file is transferred sequentially from start to finish. An HTTP media stream works differently: the player uses so-called range requests (206 Partial Content) to request only specific ranges of bytes – for example, when fast-forwarding or for the current buffer. At no point is a complete, contiguous copy of the file as a whole transferred. Server abstraction: The Emby server reads the source file and sends only the requested byte sequences to the client. Even though the audio and video streams remain bit-for-bit identical, the server processes the container structure at the application level, rather than serving the physical file on a block-by-block basis (as a file system would). Technically speaking, this is an on-demand live data stream rather than a synchronous, complete copy of a file.

In other words: with regards to our own ecosystem, I think this is a client-side feature and should be handled by client players rather than by the server. Having a transcoding parameter to cause server transcoding to apply such gain adjustments nonetheless is still possible. But these are two very different things - which is why I said that we're not talking about...

I have request, take it or leave it. When we download subtitles of same language can we just have overight the old one, instead of keeping a link list of same language subtitles. As most of the subs are useless cause of ai translation, wrong mkv , etc I have movies or series with more than 10 Greek subtitles that I need to delete from directories . I mean thousands! Thank you

Thanks for sharing.

On the subject in general, this cannot be reduced to a single feature request like "Replay Gain Feature" yes/no. There are really multiple parts and the first one is obviously media information data. Stream side data in FFmpeg has substantially grown in variety in recent years, so one consideration might be to always record the full side data for all streams as Json string to catch everything, even when we don't have our own data structures for it. I'm saying this, because the value of replay gain data specifically is questionable - because it also depends on what we are doing with it: As you might know, we have different ways for playback: There's "direct play", where the client retrieves the original bytes of the media files and plays them directly - and we have transcoded playback. When we would apply the gain adjustments in case of transcoding, but still return the replay gain information as part off the media info, a client might assume that it still needs to apply that gain correction - or the other way round, it would need to know that it needs to apply gain adjustment only in case of direct play but not in case of transcoded playback. My immediate intuition on the whole topic would be to: Leave it up to the client to handle replay gain adjustment - according to what's baked into the media metadata When transcoding at the server-side, don't apply any gain correction - just make sure that any replay gain metadata information does not get lost when transcoding

It doesn't use replaygain, but yes it scans your music library and normalizes the volume.

I have been watching movies today on a lazy Saturday. So far playback has been flawless! Enjoying that. I have noticed a minor UI thing - When selected any poster or thumb image, as the poster/thumb expands slightly in size as it becomes the focus point, the text under it overlaps the image just a little bit. It sort of makes it hard to read while the image is focused. Maybe just a padding issue? Nothing else of note so far.

Nothing is lost by transferring over http. It's still bit to bit perfect copy.

@softworkz Thank you for clarifying. Is there a supported public plugin API—such as IFfmpegRunner, IMediaEncoder, or another service—that allows a plugin to create an audio transcoding job with a custom constant-volume filter and stream the result? I am trying to avoid launching and managing FFmpeg directly from the plugin. If no supported extension point exists for adding an audio filter to Emby’s transcoding pipeline, that answers the question.

Bonjour à tous, Comme beaucoup ici, j'ai mon serveur Emby au centre de mes soirées. Il ne lui manquait qu'une chose : la TV en direct de mon abonnement Zattoo, que je devais toujours aller chercher ailleurs. Alors je me suis lancé, et le résultat fonctionne assez bien pour que j'aie envie de le partager. Emby.Zattoo est un plugin Live TV qui fait apparaître les chaînes non-DRM d'un compte Zattoo directement dans Emby, comme n'importe quelle autre source TV. On ouvre le guide, on clique sur une chaîne, ça démarre. Rien de plus. Sous le capot, tout se passe côté serveur : le plugin ouvre le flux Zattoo, choisit une piste vidéo et une piste audio, puis les remuxe en MPEG-TS pour Emby avec FFmpeg en copie de flux. Pas de réencodage, donc très peu de CPU. Et vos identifiants, cookies et URL de lecture ne quittent jamais votre serveur. Ce que ça donne au quotidien : - vos chaînes arrivent avec leurs vrais numéros, vos favoris, les logos et les bouquets, en ne gardant par défaut que celles réellement lisibles - un guide jusqu'à 14 jours, dont les descriptions se complètent tranquillement en arrière-plan - les rubriques Films, Séries, Sport, Jeunesse et Actualités de la grille se remplissent enfin, et l'enregistrement de séries fonctionne - le DVR d'Emby fait son travail normalement. Le plugin s'adapte même à la capacité de votre compte : si l'abonnement le permet, vous pouvez regarder une chaîne pendant qu'une autre s'enregistre - côté configuration, deux champs à remplir : identifiant et mot de passe. Tout le reste a des valeurs par défaut qui vont très bien. Soyons clairs sur les limites, parce qu'elles comptent : le plugin ne touche absolument pas aux chaînes protégées par DRM et ne contourne rien du tout. Il lit uniquement ce que votre compte expose sans protection. Le Replay et les enregistrements hébergés chez Zattoo ne sont pas intégrés non plus. Pour l'essayer, il vous faut Emby 4.9.x sous Linux avec Emby Premiere actif (c'est Emby qui l'exige pour le Live TV et le DVR), et un compte Zattoo valide. Rien d'autre à installer : le plugin utilise le FFmpeg déjà embarqué par Emby. Tout est ici, avec le guide d'installation : https://github.com/fearless210/emby.zattoo La DLL se télécharge dans les releases, avec ses sommes SHA256 pour vérifier l'intégrité. Et maintenant, j'ai besoin de vous. Je l'utilise tous les jours et il tourne très bien chez moi — Emby Web, iOS, Samsung Tizen, enregistrements longs compris. Mais je n'ai qu'un seul compte et une seule région pour tester. Si vous l'essayez depuis un autre pays, avec un autre abonnement ou d'autres clients Emby, votre retour m'intéresse énormément, que ça marche ou non. Bugs, idées, remarques : ouvrez une issue sur GitHub ou répondez ici, je suis preneur. Et si l'envie vous prend de mettre les mains dedans, le dépôt contient une documentation technique qui explique l'architecture et le protocole observé, de quoi contribuer sans avoir à décortiquer tout le code. Petite précision pour finir : projet non officiel, sans aucun lien avec Zattoo ni avec Emby, et son utilisation reste soumise aux conditions de votre abonnement. Bons tests, et merci d'avance à ceux qui prendront le temps d'un retour !

Emby SDK Reference: IFfmpegConfiguration only tells you the location of the FFmpeg binaries.

@Luke Would a plugin using the documented IFfmpegConfiguration and media-encoding interfaces to expose ReplayGain metadata and a gain-adjusted audio stream be acceptable for the Emby plugin catalog? Are those interfaces considered stable for third-party plugins?

JF has this feature/functionality?

I am also interested in this feature