All Activity

Can you also make sure the device has the latest firmware update?

Had either of you used the previous version 0.1.3? Did it connect correctly?

I in general advice people to stay away from AV1, the support for it among devices is sketchy at best.

Windows Server Android Client Cast to Google TV Cant pause, resume goes back to start. Cant scrub, goes back to start. Plz help. Logs attached. embyserver-63927001144.txt ffmpeg-remux-63bb8307-c6c4-49cc-a21b-f4215af80326_1.txt ffmpeg-remux-5952000a-6e8c-4209-9a28-81bd590b8120_1.txt ffmpeg-remux-d03b5137-eac4-4441-b646-4a9175ee6abe_1.txt ffmpeg-remux-d6ca20cf-4a21-4d04-af28-5ad3a3510983_1.txt hardware_detection-63927001188.txt embyserver.txt

@SamESIt's 0.1.4 on the Firestick and 4.10.1.0 on the server.

REPORT DATE 2026-10-07 1. SUMMARY AND USER IMPACT I am reporting repeated channel live-TV stalls in Emby Web on desktop Chrome. The source audio is reported as English MP2 stereo, 256 kbps, 48000 Hz. The affected Emby web session reports transcoding the audio to MP3 at 192 kbps. The stream is delivered to the browser as HLS. The browser uses an audio/mpeg SourceBuffer in sequence mode. Six explicit forward timestampOffset resets are followed by real audio buffered-range gaps of approximately 111 ms. Video remains continuously buffered across these positions. At the five later natural stalls, a further approximately 5.889 seconds of playable audio/video is already buffered beyond the gap, but playback does not recover automatically during the observed wait. Five manual seeks into the next buffered range produce playing events within 6.4-8.3 ms. The practical impact is recurring interruption requiring manual intervention. In the final stall, playback remains stopped for at least 10.1945 seconds before capture export. This report does not extrapolate an infinite stall beyond the observation window. Please investigate Emby's audio output selection, the shipped HLS player and its runtime configuration, MPEG-audio timeline placement, and gap recovery. Choosing to transcode an unsupported source codec is not itself the alleged defect. The reported defect is the repeated timeline gaps and failure to recover during this MP3 playback path. This is a standalone report: the numerical evidence, selected original event records, relevant source excerpts, and candidate-mechanism explanation are included inline. Event data are selected and summarized here, rather than represented as a verbatim copy of all 543 diagnostic records. The selected records preserve their captured values. No separate evidence file is needed to follow the analysis. 2. ENVIRONMENT AND CONFIDENCE OF IDENTIFICATION - Application: Emby Web, playing channel live TV supplied through Dispatcharr. - Emby Server version and server operating system: [TO FILL]. - Emby Web App version/build and whether bundled with the server or hosted separately: [TO FILL]. - Dispatcharr version: [TO FILL]. - Actual FFmpeg versions/builds used by Emby and by Dispatcharr: [TO FILL]. - Browser UA recorded in this capture: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/154.0.0.0 Safari/537.36 - Exact Windows release: [TO FILL]. The NT 10.0 UA token is not sufficient to identify the Windows release. - The separately supplied AMD player bundle identifies itself as hls.js 1.6.0-beta.2. Its version string does not establish byte-for-byte identity with an upstream release. The trace's exposedHlsVersion field is null, so the version is identified from the supplied code, not from that trace field. - Audio SourceBuffer: audio/mpeg;codecs=, mode=sequence. - Video SourceBuffer: video/mp4;codecs=avc1.640028, mode=segments. - Actual runtime hls.config, FragmentTracker partial flags, and Emby overrides: not captured. - The user reports direct MP2 playback works on a phone. Its player, OS, and a matching normal-session capture are not documented. - The user reports a previous evening without this problem. There is no normal-session trace or output-codec record to establish what changed. 3. REPRODUCTION IN THE OBSERVED EMBY INTEGRATION 1) Supply the channel live source through Dispatcharr to Emby with MP2 audio retained. 2) Open the channel in desktop Chrome using Emby Web. 3) Confirm that this session reports MP3 192 kbps output and actually creates an audio/mpeg SourceBuffer in sequence mode. 4) Allow playback to reach a natural stall. Observe currentTime and the audio, video, and media buffered ranges. In the captured session, stalls recur around the gap positions listed in section 6. 5) For diagnosis, seek approximately 0.1 seconds into the next already-buffered playable range. Compare the playing event with subsequent media response completion and append times. 6) Continue playback to observe the next occurrence. This capture contains six natural stalls and five manual recoveries. The manual seek is a diagnostic intervention, not normal operation or evidence that automatic recovery succeeded. A shareable standalone reproduction stream is not yet available. The steps above describe the observed Emby integration, not a guaranteed reproduction on every current upstream player build. Expected behavior: Continuous audio should be placed on its correct timeline, real discontinuities should be handled explicitly, and subsequent playable audio/video should allow appropriate recovery or a useful error report instead of repeated unexplained waiting. Actual behavior: The audio buffer repeatedly contains small gaps after explicit offset writes. At natural waiting events, paused=false, seeking=false, readyState=2, networkState=2, and the recorded media error code is null. The playhead stops about 71-84 ms before the end of the current range, rather than in the center of a gap. Video is buffered beyond these positions. 4. CONFIGURATION HISTORY 4.1 Profile reported during the MP2-preserving investigation -hide_banner -loglevel info -nostdin -buffer_size 8388608 -probesize 10000000 -analyzeduration 10000000 -i {streamUrl} -ss 2 -map 0:v:0 -map 0:a? -c copy -mpegts_flags +resend_headers -muxdelay 0 -muxpreload 0 -f mpegts pipe:1 This Dispatcharr profile was supplied during the investigation; it was not independently reconstructed from the actual running process for this capture. The -c copy option preserves the input audio at this stage. Emby separately reports MP3 output for the failing web session. Emby's effective FFmpeg command, including HLS output and timestamp-related options, is still needed. 4.2 Subsequent AAC experiment -hide_banner -loglevel info -nostdin -buffer_size 2097152 -probesize 2000000 -analyzeduration 2000000 -i {streamUrl} -map 0:v:0 -map 0:a? -c:v copy -c:a aac -profile:a aac_low -b:a 192k -ar 48000 -ac 2 -mpegts_flags +resend_headers -muxdelay 0 -muxpreload 0 -f mpegts pipe:1 The user subsequently supplied this profile and reported slower startup. No post-change MSE capture establishes what codec finally reached the web player, and no adequate result establishes that the original stalls were resolved. If Emby delivers AAC downstream, this experiment could avoid the raw MPEG-audio append branch; if Emby converts the result back to MP3, it may not avoid that branch. Startup tuning is a separate performance question. 5. CAPTURE METHOD AND OVERALL MEASUREMENTS Capture start: 2026-10-07 07:50:51.204 UTC (15:50:51.204 Asia/Shanghai). Last event: approximately 2026-10-07 07:52:43.641 UTC (15:52:43.641 Asia/Shanghai). Elapsed interval from capture start to last event: 112.4367 seconds. The client-side diagnostic capture records MSE appends, SourceBuffer state, explicit timestampOffset setter calls, media events and snapshots, manual seek interventions, and completed matching Resource Timing entries. The raw TS payloads and playlist response bodies were not saved by this capture. The probe's MP3 results are frame-header/length scan metadata, not a CRC or complete audio-decode integrity test. - 543 events with contiguous sequence IDs 1-543; droppedRecords=0. - 17 audio appends and 18 video appends. Video includes one initialization append and 17 media appends. - All 35 append operations have matching updateend records; append-to-updateend duration is 0.4-8.5 ms, median 2.8 ms. - First audio append: 173 MP3 frames, 4.152 seconds, 99648 bytes, 48000 Hz. - The next 16 audio appends each contain 125 MP3 frames, 3.000 seconds, 72000 bytes, 48000 Hz. - All audio scan summaries report zero metadata bytes and zero unparsed bytes. This does not establish correctness of original PES timestamps or decoded content. - 12 explicit offset writes: six forward and six backward, each approximately 111.022 ms in magnitude. - 45 completed matching resource entries report HTTP 200: 17 TS requests and 28 playlist requests (one master-playlist request and 27 media-playlist requests). - Completed TS durations: 13.0-67.7 ms, median 17.3 ms. - The 12 media-waiting events are one startup event, six natural stalls, and five events associated with manual recovery seeks. Completed Resource Timing entries cannot exclude pending, unobserved, failed-before-recording, or upstream requests. HTTP 200 and short durations do not prove payload correctness or that every part of the network path was healthy. 6. DIRECT TIMELINE EVIDENCE All media positions are seconds. Elapsed ms means milliseconds since capture start. Sequence IDs refer to the original diagnostic event ordering. 6.1 All explicit offset writes Setter seq | Elapsed ms | Before s | After s | Delta ms | Audio append seq --- | --- | --- | --- | --- | --- 71 | 14529.5 | 4.151999 | 4.263022 | +111.023 | 72 155 | 31714.4 | 13.263022 | 13.152000 | -111.022 | 156 193 | 33446.7 | 22.152000 | 22.263022 | +111.022 | 194 205 | 33477.0 | 25.263022 | 25.152000 | -111.022 | 206 282 | 57007.5 | 28.152000 | 28.263022 | +111.022 | 283 295 | 57037.7 | 31.263022 | 31.152000 | -111.022 | 296 358 | 73887.9 | 34.152000 | 34.263022 | +111.022 | 359 370 | 73926.4 | 37.263022 | 37.152000 | -111.022 | 371 423 | 86046.3 | 40.152000 | 40.263022 | +111.022 | 424 435 | 86082.6 | 43.263022 | 43.152000 | -111.022 | 436 482 | 96507.9 | 46.152000 | 46.263022 | +111.022 | 483 495 | 96538.7 | 49.263022 | 49.152000 | -111.022 | 496 These are explicit JavaScript writes. In sequence mode the browser also advances timestampOffset automatically after appends; that automatic movement is not counted as another explicit reset. 6.2 All six audio gaps and associated natural waiting events Stall | Gap start s | Gap end s | Gap ms | Setter seq | Waiting seq | currentTime s --- | --- | --- | --- | --- | --- | --- 1 | 4.151999 | 4.263022 | 111.023 | 71 | 65 | 4.080654 2 | 22.152000 | 22.263022 | 111.022 | 193 | 252 | 22.070625 3 | 28.152000 | 28.263022 | 111.022 | 282 | 319 | 28.070603 4 | 34.152000 | 34.263022 | 111.022 | 358 | 394 | 34.068270 5 | 40.152000 | 40.263022 | 111.022 | 423 | 458 | 40.067632 6 | 46.152000 | 46.263022 | 111.022 | 482 | 519 | 46.067843 The first waiting event, seq 65 at elapsed 13990.8 ms, occurs BEFORE setter seq 71 at 14529.5 ms, a difference of 538.7 ms. Initially no following playable range is present. A near-live underrun may explain that initial onset. The later append then leaves the recorded gap and waiting persists. The first onset must not be described as already caused by a gap that had not yet been appended. At stalls 2-6, the following range is already buffered when waiting begins. Each following range contains about 5.889 seconds of playable data. These later events provide the clearer recovery-failure evidence. Stall | Waiting at ms | Remaining in current range ms | Next range present at onset | Observed wait s --- | --- | --- | --- | --- 1 | 13990.8 | 71.345 | No | 17.6515 2 | 49459.1 | 81.375 | Yes | 7.5180 3 | 62739.6 | 81.397 | Yes | 11.1260 4 | 79603.3 | 83.730 | Yes | 6.4264 5 | 91802.6 | 84.368 | Yes | 4.6759 6 | 102242.2 | 84.157 | Yes | at least 10.1945 Observed wait is from the natural waiting event to the playing event after manual recovery, or to export for stall 6. It includes the few milliseconds required for the diagnostic seek. Stall 6 is right-censored at export, not a measured complete recovery time. 6.3 Final buffered ranges at seq 543 Video SourceBuffer: [1.263022, 52.263022] Audio SourceBuffer: [0.000000, 4.151999] [4.263022, 22.152000] [22.263022, 28.152000] [28.263022, 34.152000] [34.263022, 40.152000] [40.263022, 46.152000] [46.263022, 52.152000] The media element's buffered ranges have the same six gaps, with the first range beginning at 1.263022. currentTime=46.067843, paused=false, seeking=false, readyState=2, errorCode=null; both SourceBuffers have updating=false. There are 1123 total video frames and zero reported dropped video frames at export. These observations do not rule out every possible decoder problem. 7. MANUAL RECOVERY AS A DIAGNOSTIC CONTROL After stall | Jump seq | Jump at ms | Target s | Playing seq | Playing at ms | Latency ms --- | --- | --- | --- | --- | --- | --- 1 | 133 | 31634.2 | 4.363022 | 141 | 31642.3 | 8.1 2 | 271 | 56968.8 | 22.363022 | 279 | 56977.1 | 8.3 3 | 347 | 73859.2 | 28.363022 | 355 | 73865.6 | 6.4 4 | 412 | 86021.7 | 34.363022 | 420 | 86029.7 | 8.0 5 | 471 | 96470.3 | 40.363022 | 479 | 96478.5 | 8.2 Manual recovery was performed after stalls 1-5. Stall 6 remained unresolved at export. The target is 0.1 seconds inside the next already-buffered range. All five playing events precede both the next observed TS responseEnd timestamp and the next append. For example, after stall 2: - Manual jump seq 271: elapsed 56968.8 ms, from 22.070625 to 22.363022 seconds. - Playing seq 279: elapsed 56977.1 ms, latency 8.3 ms. - Next observed TS responseEnd: elapsed 56996.2 ms. - Next append: seq 281, elapsed 57007.1 ms. This supports the relationship between the stopped playhead and the buffered-range gap: playback can resume from data already present. It does not establish that arbitrary seeks are safe, nor that every upstream operation was healthy. 8. WORKED EXAMPLE: GAP AT 22.152-22.263022 SECONDS The following sequence exposes the gap without relying only on aggregate statistics: 1) A media playlist response ends at elapsed 33422.3 ms (resource event seq 191 is emitted later at 33425.6 ms). 2) Seq 193 at 33446.7 ms explicitly changes the audio timestampOffset from 22.152 to 22.263022, a forward move of 0.111022 seconds. 3) Seq 194 appends 125 MP3 frames / 3.000 seconds at the new offset. 4) Seq 199 updateend reports audio ranges [4.263022, 22.152] and [22.263022, 25.263022], in addition to the earlier first range. The gap is now observable in SourceBuffer.buffered. 5) Seq 205 resets the offset backward from 25.263022 to 25.152. The next audio append ends at 28.152, but the earlier gap at 22.152-22.263022 remains. 6) At seq 252, currentTime=22.070625 and playback waits. Snapshot seq 253 shows video continuously buffered through 28.263022, audio available after the gap through 28.152, and neither SourceBuffer updating. 7) A manual seek into the existing next range produces playing within 8.3 ms. Selected original records for this example are embedded below as one JSON object per line. The resource label has been anonymized; the diagnostic IDs, numerical values, ordering, and field names are retained. These are selected complete event objects, not the entire capture or saved media payloads. ```json {"seq":191,"tMs":33425.6,"type":"resource","file":"media_playlist_001.m3u8","initiator":"xmlhttprequest","startMs":33416.7,"responseEndMs":33422.3,"durationMs":5.6,"transferSize":488,"encodedBodySize":188,"decodedBodySize":840,"responseStatus":200} {"seq":193,"tMs":33446.7,"type":"set-timestampOffset","value":22.263022,"before":{"id":"sb1","sourceId":"ms1","mime":"audio/mpeg;codecs=","removed":false,"appendId":15,"mode":"sequence","updating":false,"timestampOffset":22.152,"appendWindowStart":0,"appendWindowEnd":"Infinity","buffered":[[0,4.151999],[4.263022,22.152]]}} {"seq":194,"tMs":33446.8,"type":"append","id":"sb1","sourceId":"ms1","mime":"audio/mpeg;codecs=","removed":false,"appendId":17,"mode":"sequence","updating":false,"timestampOffset":22.263022,"appendWindowStart":0,"appendWindowEnd":"Infinity","buffered":[[0,4.151999],[4.263022,22.152]],"bytes":72000,"mp3":{"frames":125,"codedDurationSeconds":3,"sampleRates":[48000],"parsedBytes":72000,"metadataBytes":0,"unparsedBytes":0}} {"seq":199,"tMs":33448.7,"type":"sb-updateend","id":"sb1","sourceId":"ms1","mime":"audio/mpeg;codecs=","removed":false,"appendId":17,"mode":"sequence","updating":false,"timestampOffset":25.263022,"appendWindowStart":0,"appendWindowEnd":"Infinity","buffered":[[0,4.151999],[4.263022,22.152],[22.263022,25.263022]]} {"seq":205,"tMs":33477,"type":"set-timestampOffset","value":25.152,"before":{"id":"sb1","sourceId":"ms1","mime":"audio/mpeg;codecs=","removed":false,"appendId":17,"mode":"sequence","updating":false,"timestampOffset":25.263022,"appendWindowStart":0,"appendWindowEnd":"Infinity","buffered":[[0,4.151999],[4.263022,22.152],[22.263022,25.263022]]}} {"seq":206,"tMs":33477.1,"type":"append","id":"sb1","sourceId":"ms1","mime":"audio/mpeg;codecs=","removed":false,"appendId":19,"mode":"sequence","updating":false,"timestampOffset":25.152,"appendWindowStart":0,"appendWindowEnd":"Infinity","buffered":[[0,4.151999],[4.263022,22.152],[22.263022,25.263022]],"bytes":72000,"mp3":{"frames":125,"codedDurationSeconds":3,"sampleRates":[48000],"parsedBytes":72000,"metadataBytes":0,"unparsedBytes":0}} {"seq":211,"tMs":33478.4,"type":"sb-updateend","id":"sb1","sourceId":"ms1","mime":"audio/mpeg;codecs=","removed":false,"appendId":19,"mode":"sequence","updating":false,"timestampOffset":28.152,"appendWindowStart":0,"appendWindowEnd":"Infinity","buffered":[[0,4.151999],[4.263022,22.152],[22.263022,28.152]]} {"seq":252,"tMs":49459.1,"type":"media-waiting","id":"media1","currentTime":22.070625,"paused":false,"seeking":false,"ended":false,"playbackRate":1,"readyState":2,"networkState":2,"buffered":[[1.263022,4.151999],[4.263022,22.152],[22.263022,28.152]],"seekable":[[0,43.263022]],"errorCode":null,"quality":{"totalVideoFrames":525,"droppedVideoFrames":0}} {"seq":253,"tMs":49459.1,"type":"snapshot","reason":"media-waiting","media":[{"id":"media1","currentTime":22.070625,"paused":false,"seeking":false,"ended":false,"playbackRate":1,"readyState":2,"networkState":2,"buffered":[[1.263022,4.151999],[4.263022,22.152],[22.263022,28.152]],"seekable":[[0,43.263022]],"errorCode":null,"quality":{"totalVideoFrames":525,"droppedVideoFrames":0}}],"buffers":[{"id":"sb1","sourceId":"ms1","mime":"audio/mpeg;codecs=","removed":false,"appendId":19,"mode":"sequence","updating":false,"timestampOffset":28.152,"appendWindowStart":0,"appendWindowEnd":"Infinity","buffered":[[0,4.151999],[4.263022,22.152],[22.263022,28.152]]},{"id":"sb2","sourceId":"ms1","mime":"video/mp4;codecs=avc1.640028","removed":false,"appendId":18,"mode":"segments","updating":false,"timestampOffset":0,"appendWindowStart":0,"appendWindowEnd":"Infinity","buffered":[[1.263022,28.263022]]}]} {"seq":271,"tMs":56968.8,"type":"manual-jump","media":{"id":"media1","currentTime":22.070625,"paused":false,"seeking":false,"ended":false,"playbackRate":1,"readyState":2,"networkState":2,"buffered":[[1.263022,4.151999],[4.263022,22.152],[22.263022,28.152]],"seekable":[[0,46.263022]],"errorCode":null,"quality":{"totalVideoFrames":525,"droppedVideoFrames":0}},"target":22.363022} {"seq":279,"tMs":56977.1,"type":"media-playing","id":"media1","currentTime":22.363022,"paused":false,"seeking":false,"ended":false,"playbackRate":1,"readyState":4,"networkState":2,"buffered":[[1.263022,4.151999],[4.263022,22.152],[22.263022,28.152]],"seekable":[[0,46.263022]],"errorCode":null,"quality":{"totalVideoFrames":531,"droppedVideoFrames":0}} ``` 9. RELEVANT CODE IN THE SUPPLIED PLAYER BUNDLE The following excerpts are reproduced inline from the supplied bundle, with original line numbers. The bundle identifies itself as hls.js 1.6.0-beta.2. These are evidence about that supplied code; exact equivalence to the current upstream release or to an unmodified tagged build has not been established. 9.1 MPEG-audio offset handling The onBufferAppending code checks the audio/mpeg branch at relevant chunk/fragment boundaries and takes fragStart from (part || frag).start. The key lines are: ```javascript 11442: var blockedAudioAppend, vappending, _this12 = this, tracks = this.tracks, data = eventData.data, type = eventData.type, parent = eventData.parent, frag = eventData.frag, part = eventData.part, chunkMeta = eventData.chunkMeta, chunkStats = chunkMeta.buffering[type], sn = frag.sn, eventData = self.performance.now(), fragBuffering = (chunkStats.start = eventData, 11443: frag.stats.buffering), partBuffering = part ? part.stats.buffering : null, eventData = (0 === fragBuffering.start && (fragBuffering.start = eventData), 11444: partBuffering && 0 === partBuffering.start && (partBuffering.start = eventData), 11445: tracks.audio), checkTimestampOffset = !1, tracks = ("audio" === type && "audio/mpeg" === (null == eventData ? void 0 : eventData.container) && (checkTimestampOffset = !this.lastMpegAudioChunk || 1 === chunkMeta.id || this.lastMpegAudioChunk.sn !== chunkMeta.sn, 11446: this.lastMpegAudioChunk = chunkMeta), 11447: this.tracks.video), eventData = null == tracks ? void 0 : tracks.buffer, fragStart = (eventData && "initSegment" !== sn && (tracks = part || frag, 11448: blockedAudioAppend = this.blockedAudioAppend, 11449: "audio" !== type || "main" === parent || this.blockedAudioAppend ? "video" === type && (parent = tracks.end, ... 11455: (part || frag).start); 11456: this.append({ 11457: label: "append-" + type, 11458: execute: function() { 11459: var track, delta; 11460: chunkStats.executeStart = self.performance.now(), 11461: checkTimestampOffset && (track = _this12.tracks[type]) && (track = track.buffer) && (delta = fragStart - track.timestampOffset, 11462: .1 <= Math.abs(delta)) && (_this12.log("Updating audio SourceBuffer timestampOffset to " + fragStart + " (delta: " + delta + ") sn: " + sn + ")"), 11463: track.timestampOffset = fragStart), 11464: _this12.appendExecutor(data, type) ``` These are excerpts from a surrounding function, not a standalone executable block. The branch can explicitly set the audio SourceBuffer offset whenever the difference from the fragment start reaches 0.1 seconds. The observed approximately 0.111022-second changes cross that threshold. 9.2 Candidate interaction with playlist timing updates The supplied code updates fragment timing from available elementary-stream timing and propagates it to neighboring fragments. Within the same continuity counter, updateFromToPTS can set the next unparsed fragment's start using the previous fragment's minEndPTS. During mergeDetails, previously parsed fields are copied: ```javascript 5112: isFiniteNumber(oldFrag.startPTS) && isFiniteNumber(oldFrag.endPTS) && (newFrag.setStart(newFrag.startPTS = oldFrag.startPTS), 5113: newFrag.startDTS = oldFrag.startDTS, 5114: newFrag.maxStartPTS = oldFrag.maxStartPTS, 5115: newFrag.endPTS = oldFrag.endPTS, 5116: newFrag.endDTS = oldFrag.endDTS, 5117: newFrag.minEndPTS = oldFrag.minEndPTS, 5118: newFrag.setDuration(oldFrag.endPTS - oldFrag.startPTS), 5119: newFrag.duration && (PTSFrag = newFrag), 5120: newDetails.PTSKnown = newDetails.alignedSliding = !0), ``` The merge later calls: ```javascript 5184: PTSFrag ? updateFragPTSDTS(newDetails, PTSFrag, PTSFrag.startPTS, PTSFrag.endPTS, PTSFrag.startDTS, PTSFrag.endDTS) : adjustSliding(oldDetails, newDetails), ``` Relevant calculations inside updateFragPTSDTS are: ```javascript 5064: var i, maxStartPTS = startPTS, minEndPTS = endPTS, fragStartPts = frag.startPTS, fragEndPts = frag.endPTS, deltaPTS = (isFiniteNumber(fragStartPts) && (deltaPTS = Math.abs(fragStartPts - startPTS), 5065: isFiniteNumber(frag.deltaPTS) ? frag.deltaPTS = Math.max(deltaPTS, frag.deltaPTS) : frag.deltaPTS = deltaPTS, 5066: maxStartPTS = Math.max(startPTS, fragStartPts), 5067: startPTS = Math.min(startPTS, fragStartPts), 5068: startDTS = Math.min(startDTS, frag.startDTS), 5069: minEndPTS = Math.min(endPTS, fragEndPts), 5070: endPTS = Math.max(endPTS, fragEndPts), 5071: endDTS = Math.max(endDTS, frag.endDTS)), 5072: startPTS - frag.start), fragStartPts = (0 !== frag.start && frag.setStart(startPTS), 5073: frag.setDuration(endPTS - frag.start), ... 5077: frag.endPTS = endPTS, 5078: frag.minEndPTS = minEndPTS, 5079: frag.endDTS = endDTS, 5080: frag.sn); ``` In a constructed source-level model, using the actual timing functions from this supplied bundle and simplified fragment/playlist objects: - Previous fragment audio timing: start 19.152000 s, end 22.152000 s. - Previous fragment video timing: start 19.263022 s, end 22.263022 s. - After per-track timing updates: minEndPTS=22.152000 and next.start=22.152000. - After executing mergeDetails: minEndPTS=22.263022 and next.start=22.263022. - Next fragment audio timing: start 22.152000 s, end 25.152000 s; video timing: start 22.263022 s, end 25.263022 s. - After that next fragment receives its per-track timing: following.start=25.152000. This can create the numerical pattern seen at the MSE boundary: a forward placement of +0.111022 s, then a backward placement of -0.111022 s relative to the assumed three-second append end. The code explanation is that mergeDetails invokes the timing helper using already-aggregated startPTS/endPTS. The helper recomputes minEndPTS from the supplied endPTS and the existing aggregate frag.endPTS, which can replace a previously lower per-track minimum with the aggregate end before propagation to a neighbor. This is a candidate mechanism, not a claim that the actual PES timestamps or every internal field in the live session were measured. The model uses deliberately constructed track times, DTS equal to PTS, a single continuity counter, and no seek, parts, delta update, or level switch. A real-media reproduction is needed before assigning a unique root cause or deciding on a patch. 9.3 Recovery conditions that may miss this position Bundled defaults: ```javascript 18866: maxBufferHole: .1, 18867: highBufferWatchdogPeriod: 2, 18868: nudgeOffset: .1, 18869: nudgeMaxRetry: 3, 18870: maxFragLookUpTolerance: .25, ``` FragmentTracker initializes bufferPadding to 0.2 seconds. getBufferedTimes expands the range boundaries by that padding when deciding whether a fragment is sufficiently buffered. getPartialFragment only selects fragments classified as partial. The actual classification in the failing session was not captured. Relevant recovery branch: ```javascript 20008: _proto._tryFixBufferStall = function(bufferInfo, stalledDurationMs) { 20009: var config = this.config 20010: , fragmentTracker = this.fragmentTracker 20011: , media = this.media; 20012: if (null !== media) { 20013: media = media.currentTime, 20014: fragmentTracker = fragmentTracker.getPartialFragment(media); 20015: if (fragmentTracker) 20016: if (this._trySkipBufferHole(fragmentTracker) || !this.media) 20017: return; 20018: (bufferInfo.len > config.maxBufferHole || bufferInfo.nextStart && bufferInfo.nextStart - media < config.maxBufferHole) && stalledDurationMs > 1e3 * config.highBufferWatchdogPeriod && (this.warn("Trying to nudge playhead over buffer-hole"), 20019: this.stalled = null, 20020: this._tryNudgeBuffer()) ``` For stall 2, the measured remaining continuous buffer is: 22.152000 - 22.070625 = 0.081375 s. The distance from the playhead to the next buffered range is: 22.263022 - 22.070625 = 0.192397 s. If the runtime uses maxBufferHole=0.1 and getPartialFragment returns null, neither bufferInfo.len > maxBufferHole nor nextStart-currentTime < maxBufferHole is true at that position. This is a conditional explanation for the observed lack of recovery. Actual hls.config and partial flags are needed to confirm whether this branch was responsible at runtime. A gap merely being larger than 100 ms is not sufficient by itself to predict a stall. 10. INTERMITTENT BEHAVIOR AND SOURCE OF THE OFFSET The same failing capture also contains continuous append phases without new gaps. All six forward resets occur after captured media-playlist refreshes; the backward resets occur during consecutive append batches. This temporal relationship is compatible with playlist timing updates changing the placement reference, but correlation does not prove the exact runtime cause. The reported normal phone playback and previous evening of normal playback are useful comparisons, but there is no matching record of the output codec, player configuration, media timestamps, or buffer behavior in those sessions. I cannot attribute the difference to caching, a restart, improved network conditions, or a confirmed fix. The original relative timing difference cannot be assigned to the broadcaster, an upstream relay, Dispatcharr, Emby's encoder/muxer, or hls.js solely from this client-side record. Even if the original media has a stable audio/video offset, the repeated changes between placement references and the recovery behavior require investigation in the web playback path. 11. REQUESTED EMBY INVESTIGATION 1) Identify the exact Web App player build, local changes from upstream hls.js, and actual configuration for the affected session. 2) Provide or inspect the effective FFmpeg command and input/output stream descriptions. Verify how MP3 is selected for this browser and whether AAC can be supplied through a supported configuration as a diagnostic comparison. 3) Inspect playlist and segment timestamps across the failing boundary, including source audio/video PTS, decoded/remuxed track timing, and any discontinuity or timestamp normalization applied by the server. 4) Instrument the same frag.sn/cc before and after playlist merge and after per-track parsing: start, minEndPTS, endPTS, maxStartPTS, audio/video startPTS and endPTS, and the resulting offset write. 5) Capture actual hls.config and fragment partial/full status, then determine why the known future playable range does not lead to automatic recovery. 6) If an upstream player issue is confirmed, identify the upstream issue/commit and the Emby version that integrates the fix. If the integration is responsible, identify the Emby correction and a targeted validation using the same media sample. 12. REMAINING INFORMATION AND LIMITS The following have not been supplied or established in this report: - Exact Emby Server/Web App/Dispatcharr/FFmpeg versions and server OS. - Emby's actual FFmpeg invocation and full server/transcoding logs for this window. - Original M3U8 bodies, TS media samples, PES PTS/DTS, source PCR, or per-track remux metadata. - Full runtime hls.config, partial flags, complete console output, or Chrome media-internals output. - Playback results with the same stream in current stable and development hls.js demos. - A post-AAC-change trace proving the final browser codec or confirming resolution. The technical evidence already present is included in the sections above. These missing items are acknowledged rather than replaced with assumed values. No standalone upstream browser reproduction, proven universal fix, or particular corrected release is claimed. 13. RELATED PRIMARY SOURCES Emby Web App reporting forum: https://emby.media/community/forum/146-web-app/ Emby problem-reporting guidance: https://emby.media/community/topic/739-how-to-report-a-problem/ Emby log-export instructions: https://support.emby.media/support/articles/Log-Files.html hls.js contribution and bug-reporting guidance: https://github.com/video-dev/hls.js/blob/master/CONTRIBUTING.md Related historical MPEG-audio timestampOffset/buffer-hole report: https://github.com/video-dev/hls.js/issues/3928 At review time it is Closed with Stale and answered labels. Similar symptoms are relevant background; this report does not claim a confirmed duplicate or that the closure establishes a fix. Related discussion of minEndPTS semantics: https://github.com/video-dev/hls.js/issues/5550 It is labeled Works as expected. A minEndPTS value alone is not proof of a bug. Current upstream buffer-controller source for comparison: https://github.com/video-dev/hls.js/blob/master/src/controller/buffer-controller.ts The current branch is a comparison reference, not the exact identity of the supplied bundle or a completed current-version reproduction. 14. SOURCE IDENTIFICATION Original diagnostic capture SHA-256: 022d3a03b10a2aa6d6f167d4ff250da73b4d969b358311098cec30353ee7aaca Supplied player bundle SHA-256: 3340d061237b671f3d389eff7c66cd96ced4f5aaac06466491feea526cce952a The hashes identify the input materials used for the analysis; they are not substitutes for the inline evidence and do not identify a tested upstream release. No live-stream URL, access token, private server address, or original resource/session identifier is included in this report.

Hi there! I have a Shield that i have run Emby Client for years, and as @yockerpointed out the lossless passthrough is a great feature if you have somekind of AV-setup with 7.1 etc..(wich i have) but there is one disanvantage when it comes to the Shield in my opinion and that is AV1 and the fact that the Shield CPU cant handle them when it comes to playing files. My WIN11 server had a CPU with integrated graphics so i had to get a Intel Arc 310 in order to transcode these for the Shield to be able to play it, or you could encode them in Win or what not if you have the time and patience. I do agree with @wmichael3and the assesment of the Google Streamer and as he also pointed out is that customization via ADB-debug to replace the launcher with something other than the awful Google TV, aswell as debloat it. Myself i use Primal launcher on my Shield and did the same when i tried the Google Streamer and its my go to launcher. /N

Thank you for reporting this. I have referred it to Gracenote Are you still on lineup USA-OTA51041 ?

Hi, We have a few hdhomeruns which stream into emby. On channels like ITV3 when playing through emby after 20-30 minutes the video on the stream will pause but audio continues. This happens on all devices. In my testing having VLC open to a direct link to the HDHomeRun and the stream doesn't crash. Its normally Direct play so not encoding. I have tried force encoding but this doesn't make much of a difference if at all. Just wondering if anyone else has run into these issues.

I'm having this exact same problem. Silk browser is able to reach my local Emby server, but the app can't connect. Brand new FireTV 4K Select Emby Version: 193 Last updated: Oct 6, 2026

When will this be released to Google Play?

Hello, the option to delete media immediately AFTER having watched it works fine, but if you ignore it and later try to delete it manually through the context menu (and say 'yes' to all), the media links/references in Kodi get deleted but the files on the PC still exist. Doesn't seem to work properly. Might want to look into this

Hier noch mal nen neuer Log, unten nur mit Emby. ! debug Console.txt

i'm not worried about a drive spinning up (they never stop in my server) I would like to balance performance (what lives on smaller fast expensive SSDs locally) and space (what is on the slower larger NAS HDDs) testing now the detail screen is maybe? slightly faster to load for the libraries where images and thumbs sit locally but its nearly impossible to tell. the nature of click/load new screen hides it well. while for the artwork/posters scrolling down through a library it is very obvious which library has them locally and which does not. So maybe the option i'm really looking for is "cache posters for library browsing locally with no expiration" ?

3.5.68 Fix startup crash on certain devices running Android 7 Fix sporadic cases of 4K video playing in 1080p Core UI Changes from 26.0.33 to 26.0.34 Spotlight fixes for older devices

Emby for Android 3.5.68 Released Download Emby for Android Changes 3.5.68 Fix startup crash on certain devices running Android 7 Fix sporadic cases of 4K video playing in 1080p Spotlight fixes for older devices

Hi, can you please try Emby for Android 3.5.68+ and let us know if this issue is resolved for you? Thanks !

Hi, can you please try Emby for Android 3.5.68+ and let us know if this issue is resolved for you? Thanks !

26.0.34 Spotlight fixes for older devices

Emby Web App Update: Version 26.0.34 The Emby Web app has been updated to version 26.0.34 Go and try out: https://app.emby.media/ Changes 26.0.34 Spotlight fixes for older devices

Right, the most likely answer is they were turned on temporarily by this new feature.

FYI:

I believe it has happened even after manually turning them on. I will try to replicate it again with logs. I don't know what a skip back feature is.

It is a good device but one thing to note in case it matters, it doesn't support lossless passthrough. At the fear of derailing this thread. All TVs are spying like the LG, look up Samba for Sony as an example. LG are just the ones that got reported on it for now.

It's not creating one when the video attempts to play when set to transcade. Video won't even start if I have it set to transcode. It wasn't an issue before this version. It's an Intel 10 gen chip. I am not home right now I will try when I get home and see if it will create one.