All Activity

Hi, yes that is something we are considering. Thanks.

HI, what metadata sources would you like us to incorporate?

HI, are you still seeing this with Emby for Android 3.5.49+ ?

Hi, has this helped?

I've moved this to feature requests. Thanks.

Yes — and in the same directory throughout. Everything in that session, the run that works and the runs that fail, writes to /var/lib/emby/transcoding-temp/04C768/. 04C768_220.ts is written there twice. First by the run that serves it: 14:51:48.772 ProcessRun 'StreamTranscode b8bdc3' Execute: ... -ss 00:20:54.000 ... -segment_start_number 209 14:51:48.901 Process exited with code 0 14:51:50.021 GET .../hls1/main/220.ts 14:51:50.064 Response 200. Time: 43ms. Content-Length: 2,169,708 That run wrote 209 through 220 in 129 ms and exited. Seventy seconds later, same index, same directory: 14:53:00.614 ProcessRun 'StreamTranscode c2b692' Execute: ... -ss 00:22:00.000 ... -segment_start_number 220 14:53:00.628 SegmentComplete=video:0 Index=220 ... filename=04C768_220.ts 14:53:00.628 video:2332kB audio:148kB 14:53:00.634 Process exited with code 0 14:53:00.666 Response 500 So by the server's own account it is there, and it was written again on the way to the 500. What the log cannot tell me is whether the file survived on disk between 14:51:50 and 14:53:00, and I think that is the half your question actually turns on. I can't answer that from a log, but I can answer it with an ls: this reproduces on demand and the failing window is a comfortable 45 seconds of retries. Tell me what you want listed and I'll run it and paste the output raw. Two corrections while I'm here, both mine. The "File Deleted" line is a red herring and I should have checked it before it went near this thread. It is AppendExtraLogData removing its own graph file (ffmpeg-directstream-...graph.txt), and it appears identically on the run that served 200s. Nothing to do with segments. And I overstated something in my last post. I said segments 209-220 have no "Starting transcoding" line. The first request for 209 does: 14:51:48.762 GET .../209.ts 14:51:48.762 Starting transcoding because currentTranscodingIndex=null 14:51:48.772 ProcessRun 'StreamTranscode b8bdc3' Execute: ... 14:51:48.831 Response completed after client disconnected. Time: 69ms. 14:51:48.901 Process exited with code 0 14:51:48.930 GET .../209.ts (the player asks again) 14:51:48.997 Response 200. Time: 67ms. The excerpt I attached starts just after that, at 14:51:48.930. That was careless rather than deliberate, the full log has it, and I would rather point at it myself. It also makes the pattern cleaner than I had it, so it costs me nothing to fix. It is not that the working segments never start an ffmpeg. It is that no request which starts its own ffmpeg has ever come back with the segment: the first 209, then 221 nine times, then 220 nine times. 209 only succeeded because the player asked again and the file was already on disk by then. At the tail, asking again does not help — every retry starts another process, every process writes the file and exits 0, and every one of them still answers 500. I have re-attached the excerpt with those lines put back in. embyserver-excerpt-149368.txt

HI, how does the latest update to the app compare for you?

Hi, we'll take a look at this. Thanks.

hi, are you still having an issue with this?

ok if you open a command prompt and enter powercfg /requests then you can see what apps have a power lock open on the system.

@softworkz

Not sure what to call each system, but html + JS is what I am calling when you define and return a list of PluginPageInfo in a GetPages method in your plugin. The "ControllerBase" system is when you return a list of IPluginUIPageController from UIPageControllers. Is there a table or listing to show the advantages and disadvantages of each? My primary question, is if I modify the c# code that builds the page in the "ControllerBase" system, will I still have to use chrome in debug mode and clear the cache and reload like I have to with the html+js system?

Works peachy for me, though I'd still like to see: albeit it's by no means a "must-have".

How’s the TV show status holding up? Are there any further tweaks needed?

Just the main HomeScreen After a movie finishes it goes back to the HomeScreen. I wake up in the morning and it is sat on that screen all night, both monitor displaying and pc on

is the 220 segment in the transcode temp directory?

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

Attached: an annotated excerpt of embyserver.txt from that session. I trimmed it to the one failing playback plus one contrasting session, and collapsed the repeated 500s; the header says exactly what was cut. The full untouched log and the ffmpeg logs are yours whenever you want them. Two things in it are worth your time. 1) THE 500 IS NOT ABOUT THE MISSING SEGMENT 221 is the phantom the arithmetic promises. When the player doesn't get 221, it steps back to 220. That one is not predicted: it is real, it is inside the media, and it had already been served 200 earlier in the same session — 14:51:50, Content-Length 2,169,708, in 43 ms. It gets 500 nine times as well. Eighteen 500s in total, and then the server times the session out itself. 2) THE SERVER REPORTS "ERROR STARTING FFMPEG" FOR AN FFMPEG THAT RAN AND EXITED 0 The whole of that request for 220, in 93 milliseconds: 14:53:00.573 GET .../hls1/main/220.ts 14:53:00.614 ProcessRun 'StreamTranscode c2b692' Execute: ... -ss 00:22:00.000 ... 14:53:00.628 SegmentComplete=video:0 Index=220 ... Frames=136 filename=04C768_220.ts 14:53:00.628 video:2332kB audio:148kB subtitle:0kB other streams:0kB 14:53:00.628 EXIT 14:53:00.634 ProcessRun 'StreamTranscode c2b692' Process exited with code 0 14:53:00.666 Error processing request FfRunException: Error starting ffmpeg at BaseStreamingService.StartFfMpeg(...) at DynamicHlsService.GetDynamicSegment(...) 14:53:00.666 Response 500 The process started, wrote 136 frames / 6.72 s / 2,332 kB, and exited cleanly twenty milliseconds after it was launched — and StartFfMpeg threw "Error starting ffmpeg" over it. The ffmpeg output quoted inside your own error report is the evidence against the error report. One observation, offered as an observation and not a diagnosis. In this log the segments that work and the segments that 500 differ in exactly one respect. Segments 209 through 220 were all served out of a single ffmpeg that was already running — none of them has a "Starting transcoding" line. Every request that 500s is one where "Starting transcoding because currentTranscodingIndex=null" launched a fresh process, and that process, with only the tail of the file left to write, finished in 18–20 ms. All of those exit 0, and all of those answer 500. If whatever StartFfMpeg waits on assumes the process is still alive by the time it looks, a run that short would fail that check no matter how well it went. Easy to falsify from your side, and I haven't tried to guess further than the log goes. Why this matters beyond the arithmetic: if the playlist were clamped to the real end of the media tomorrow, this second failure would still be here — and it is the one that leaves a client with nowhere to go, because it cannot recover by falling back to a segment that does exist. One correction to my own post while I'm here. I said segment 221 is never written. On this run it is: ffmpeg is launched with -ss 00:22:06.000 -noaccurate_seek, which lands back on the keyframe at 22:00, so it writes a 221.ts holding the same 136 frames that 220 already holds. It still answers 500. The playlist entry still has no media of its own behind it — but I was wrong about the file. The end of the excerpt has the same episode played by Emby Web with 3-second segments, where the list runs to 442 — ceil(1326.336 / 3) = 443. The last index isn't served there either; that one dies with ffmpeg exit code 139, five times in a row. A small note on the cheap half of this, since the objection to fixing the list was the cost of scanning. Both of these are arithmetic on the runtime you already have, and neither needs to know where a keyframe falls: whole = declared_duration / segment_length (integer division) remainder = declared_duration % segment_length For this file, 221 whole segments and a remainder of 0.336 s. * Give the last #EXTINF that remainder instead of a flat 6.0000. The playlist would promise 1326.336 s instead of 1332.000 — the overshoot drops from 6.635 s to 0.971 s — and #EXT-X-TARGETDURATION:7 would stop contradicting 222 lines that all say 6. * If the remainder is below some minimum, don't emit that entry at all. Here 0.336 s is well under any sane floor, so the list would end at 220 and the player would never ask for 221, never step back to 220, and never meet either failure. The first on its own only makes the manifest honest — 221 would still be promised and would still 500. It is the second that removes the symptom. Happy to run anything you want run. embyserver-excerpt-149368.txt

I didn't have this issue until I updated. No settings changed on my end, just updated. I wonder if tests are being done across multiple devices before an updated release. I'll probably just roll back to the version that was working for me.

Hi, there's multiple options available but in order to suggest one we need to first understand what the exact issue is. Thanks.

HI there, can you please provide a specific example? How to Report a Problem Thanks !

Hi, what's on the screen in the emby app when this happens?

Glad to hear its working as expected!

@PatrickStarwhat exactly do you see in Emby? What exactly would you like fixed? Thanks.

awesome!! If you need or want logs and stuff from the media server pc, let me know and i will provide them