All Activity

Good point! Thanks!

Weird, that it's not showing any playback, I watched for around 20 seconds. FFmpeg log attached. No, this has 5.1 audio. ffmpeg-remux-8c8528ab-4fcc-4b6c-9f58-983a3465daf1_1.txt

@ramseynedit or delete that image, we can see your remote IP.

Edited

Yes. I can ping it locally and use emby locally.

I cannot see any playback in your log. Can you please provide the ffmpeg log? Is this a TV channel with MP2 audio?

Hi there, please attach the Emby server log from when the problem occurred: How to Report a Problem Thanks!

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

Hi, yes please and thanks.

Are you sure that device ip address is still correct?

Same problem just occurred here. Trying to watch Live TV channel (OTA) and video was fine, but no audio. I'm on Beta version 2.1.49g. Log sent at 10:44AM Eastern time (my timezone is Pacific). User name is DaveA. Tried to watch local TV channel 5 (KTLA) news.

The ability to bypass the "Auto" bitrate is nice but I'm hoping for more feedback in the dashboard on what the client device has requested. This makes managing remote users or recommending quality setting changes easier.

As per the topic line, I don't hear any audio anymore when I play certain files in EAC3 5.1 audio. Specifically, it's the show Landman. The episodes are in WEBDL-720p mkv format. This is a bit of a disappointment as this show can be played via other servers on the same hardware without tweaking or doing anything special. Can anything be done about this?

Has there been any progress on this issue yet? This spinning wheel has already caused many stressful car rides, during which the kids have loudly complained about choppy and laggy videos.

Hi. Can I please see the ffmpeg logs from that exact playback?

No none of the onedrive links work anymore. Anyone else have a link willing to share please?

Can you please reproduce that and then follow the instructions to send a log from the app?

https://emby.media/community/forum/96-third-party-apps/

Hi. The only account you can have with us is not disabled because you just used it to post here.

G'day, I have a feeling this is related to the other forum topics relating to Nvidia Shield Audio Codec Issues (E-AC3) - Android TV / Fire TV - Emby Community and Emby for Android on Shield TV no longer passing through dolby digital 5.1 or DTS - Android TV / Fire TV - Emby Community, except my issue is with MP2 audio. I'm not entirely sure when this happened but I feel it was over the past two days. Neither of my two NVIDIA Shields using the Emby for Android TV app will play the audio from DVB-T live TV streams when the audio is MP2. If I playback Dolby Digital, it works fine, but not when it's MP2. It is definitely the app doing it, because the Emby server records the stream just fine with audio and you can play it back on PC just fine as well. I have submitted two logs. It's playing Frankie Drake Mysteries on ABC TV at ~7.20 am GMT-5. Emby for Android TV was auto updated to v2.1.49g on both devices. The issue does not occur on the Emby for Android app; it can play the live TV channel just fine, however, that app is not the solution here. Like the other threads, this has been working flawlessly for years until now. One device is plugged into an A/V receiver via HDMI; the other a soundbar via HDMI.

Not recording a single channel or other content provider. I use a website like pogdesign and mark the TV shows I want to watch and then go about either watching them or getting them. All the content available for free has ZERO advertisements. Live sports that I watch like Soccer, F1, Rugby have no commercials. In addition they have VOD so again no need to record. I have a total of 46TB of video content on 2 Unraid servers that I rarely touch these days. The routine for watching has changed for me and many others yet Emby still plays an important roll. For the WAF the BBC "Great British Sewing Bee" just started with season 12 and that is for Emby. Usenet is too expensive, really? You must have missed when Newshosting / Easynews ran a massive 2025 Black Friday promotion offering 15 months of unlimited Usenet for around $25 which you could add to existing subscriptions. Add to that a decent NZB indexing site and you are set. Waiting for the 2026 BF deals.

Hi, I have observed multiple cases where Emby clients entered long-running request loops against different Emby API endpoints. Although the affected endpoints and clients differ, the behavior appears similar: the client repeatedly sends the same request without an effective delay, backoff or termination condition. Environment: - Emby Server version: 4.9.5.0 - Confirmed clients in some of the cases: - Emby for Samsung - Emby for Android - The client responsible for some Live TV cases could not be identified from the available logs. Case 1: Item-detail requests Affected endpoint: GET /emby/Users/{UserId}/Items/{ItemId} Four analyzed log extracts contained approximately 198,000 requests to four individual item-detail URLs. Observed behavior: - Bursts continued for up to approximately four hours. - The same item was requested about once or twice per second. - Most responses were successful HTTP 200 responses. - Successful responses did not stop the repeated requests. - Individual clients generated tens of thousands of requests for the same item. Case 2: Live TV playlist requests Affected endpoint: GET /emby/videos/{ItemId}/live.m3u8 One incident produced: - Approximately 490,000 requests to the same playlist - A duration of approximately three and a half hours - Only HTTP 401 responses - Peaks of more than 12,000 requests within five minutes - Up to 43 requests during the same second Another incident produced: - Approximately 12,700 requests over four hours - A mixture of HTTP 200 and HTTP 401 responses - Peaks of approximately 5,000 requests within five minutes - Up to 39 requests during the same second Common behavior In all cases: - The same endpoint was requested repeatedly for an extended period. - There was no effective retry delay or exponential backoff. - Successful HTTP 200 responses did not always stop the loop. - HTTP 401 responses could trigger a particularly aggressive retry storm. - Multiple identical requests sometimes arrived during the same second. - The behavior continued until the client or session was interrupted. Expected behavior - A successful item-detail response should not be requested again every second unless something has changed. - Live playlist polling should use an appropriate refresh interval. - After HTTP 401, the client should stop playback, refresh authentication or apply exponential backoff. - Duplicate or concurrent retries should be limited. - Repeated failures should eventually terminate the operation and display an error to the user. Impact A single affected client can generate tens or hundreds of thousands of unnecessary requests, place significant load on the Emby server, and consume unnecessary resources on the client itself. Could this behavior originate from a shared retry, polling, request-scheduling, or client-side state/cache handling component used by multiple Emby clients? Please let me know which server or client debug logs would be helpful for identifying the trigger. I can provide sanitized access-log samples if required.