All Activity

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

Have you taken a look at this?

That is not all you have to do. You have to make sure to choose a location that the server process has permission to write to.

Hi, maybe the windows app is just taking over there?

Yes there’s a topic in the feature requests section for replay gain .

Hi, is the file utf8 encoded? What happens in the web app?

@Luke@softworkz, Understood. Is there an existing feature-request or issue number I can follow, and would this likely be considered for the 4.9 release series or a later major release?